Two Wrongs

Quality in Software Development, Part 7: Worse Is Better

Quality in Software Development, Part 7: Worse Is Better

I have recently started getting a true feeling for what “worse is better” means. It’s probably not what you think, and it will also probably not be clear why it is good before you have some experience with it – and more importantly, with its alternatives: good-enough software and the right thing.

Be prepared to say “no”. Figure out the least important 80% of what the product owner asks for, and cut it out of the first implementation.

Go for something incredibly limited, but rock solid.

This goes even more for internal tools. You want to be able to trust your systems. You shouldn’t have to think about whether they work today. They should just be there, as an extension of your brain/hands. This is how you multiply the value your work, rather than create additional work for yourself.