In case you missed it, here is the Liskov Substitution Principle summarised in a handy motivational poster.
Tuesday, October 27, 2009
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 estimate. Let's throw in 50% more unexpected work into iteration 7:
Again, much the same. Personally I prefer the burn-down since to me it is more obvious that work has been injected, but again, others mileage varies.
So does it make any difference which you use? Is one "better" than the other? In my opinion, no. Having used both, as far as I can tell it makes no difference whether you burn-up or burn-down. Decide which suits you/your team and don't get bogged down in unnecessary debate about which is best. The important thing you are doing is tracking real progress, and adapting to what it is telling you.
That said, I have no doubt that debating the pros and cons of burn chart direction makes for a fascinating late night bar conversation at the conference of your choice....
Monday, October 26, 2009
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.
- 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 anyone who says "We have always done it this way".
- Take away the keyboard of anyone who says "We need a bug database".
- Remove the Version Control account of anyone who claims to write bug free code without tests. Better still, take away the account, and their PC, and desk, and chair just to be sure.
- Listen to classical music and jazz. If you are unable to appreciate it at least as much as contemporary music, you lack the sensitivity to develop into an craftsman of any real depth.
- Keep your word.
- Do not work with anyone who you do not trust.
- Never explain yourself. Better yet, never do anything that will, later, require you to explain yourself or to say you're sorry.
- Always use spell check.
- Stop aspiring and start doing.
I can't guarantee anything, but this is how you might, just might, become a software craftsman...