Thoughts from a Thirsty Bear

In case you missed it, here is the Liskov Substitution Principle summarised in a handy motivational poster. (from a set of originals by Derick Bailey , released under Creative Commons)

It seems that some people have some quite strong views on the "right" way to track progress. Here's my view. In the red corner, we have the traditional burn- down graph. You start with a certain amount of estimated work, and as you finish it you cross it off the list. You finish when you hit zero. In the blue corner, we have the burn- up graph. Here you still have a certain amount of estimated work represented as a line across the graph. Work is added cumulatively and you finish when you reach the target amount of work. OK, so what's the difference? In my opinion, not much. Some suggest that a burn-up graph is psychologically more motivating because it is going up. Others I have spoken to prefer to see completion as zero, and like to see work left heading downwards. Personally I'm with the burn-downers. Another factor in choosing which way the burn goes might be ease of changing the goalposts - in other words, how easy is it to add or remove from the backlog est...

Dear aspiring Software Craftsman, Here is my advice. Take whatever courses you think are interesting. Study closely the work of the Old Masters. Stop writing software that was only designed in your own mind. Stick with one technique until you perfect it. Buy a book on software structure. It's the only book you need. Until you can write a program without bugs you don't know how to program. Stay away from Javascript. You'll never master it. Very few ever have. Forget about commercial frameworks. Use Open Source. It's where the action is. Visit an old age home. Talk to the people who remember 8 inch floppy disks and punch cards. Learn to play chess. Take a business course. Do not use an MP3 player. Learn a foreign language. Scala should do it. Learn to cook. Please. Before you get scurvy or rickets. There are more food groups than pizza, coffee and chocolate bars. Learn to play a musical instrument. Learn to swim. Do not litter. Avoid politically correct people. Avoid anyo...

My buddies at Energized Work , Gus Power and Simon Baker, have won the Gordon Pask Award for Contributions to Agile Practice . Their " No Compromise No Excuses " approach has proven incredibly successful, and is helping many in the industry raise their game, myself included. Congratulations guys!

Just found a great metaphor to contrast waterfall development with agile. Agile is more like a pond. And you get a picnic at the end! The Opposite of Waterfall is Pond Thanks Alan Atlas for a very clear, beginner-friendly metaphor.

It seems that right now "agile" is flavour of the month everywhere.It has hit the mainstream. Everyone has it on their CV, too, so we have a situation where the industry want the skills, and everyone has the skills. Everything is fine and dandy in the software industry. Right? Dead wrong. There is a disturbing trend appearing in the industry. It is becoming increasingly difficult to identify anyone who has genuine agile experience. Many developers, BAs, QAs and product owners declaring agile experience on their CVs, when put into a true agile/lean environment struggle to cope (to say the least). To give typical examples, consider the developer who claims "agile" experience, but does not understand (let alone able to write) unit tests or the power of automated build systems. Or the "experienced agile" guy who had a Gantt chart showing the story contents of every iteration. Or the teams who believe it is acceptable to leave the build broken for weeks on end ...

Mike Hill has written an excellent article titled " How TDD and Pairing Increase Production " An excerpt: "If you want more production, look first to raising your internal quality. ... All day long, every time you make a move, you will be depending on the code that’s already there. Every line of it you have to study will slow you down. Every extra open dependency will slow you down. Every bad variable name will slow you down. Every flawed design decision, be it big or small, will slow you down. If you want to work as fast as you can, you want to work with clean code. Period." There are many more thought provoking truths in there. Read it! It might just change the way you write code.