Uncle Bob writes today about the tortoise and the hare. It's an excellent post, nice and concise, though I think he could've made his point about speed a little clearer. The entire post promotes quality over speed, but then he slips this paragraph in the middle:
Over the years I've published a lot about design principles, design patterns, and development practices that can help teams keep their code clean and flexible. However, these principles, patterns, and practices are only of use to the folks who take the time to use them. Interestingly enough, these are the same folks who will get done faster, and better, than those who don't take the time.
Ultimately you can have your cake complete with table, chair, fork and napkin: quality and speed. The point is we're running a marathon, so pace yourself, and prepare yourself for management of a huge codebase.
As a tangential bonus, he threw in a paragraph that would tie in nicely to my MakingBadProgrammersCare stuffs:
I was with a team the other day, and the manager of the team said to them: “I want this code to be ... high quality. ... Nobody remembers the speed, they only remember the mess. So do it right”. The programmers looked at him skeptically. Their boss just told them to go well, instead of going fast, and they didn't believe him. What does it take?
I think one reason it's hard for people to believe that going well will be ultimately faster is because it's a long term notion. It's an investment. I'm not penalized in the early stages of my project for not building extreme quality infrastructure, so doesn't it slow me down for no reason?
In addition to internal myopia, don't we have a highly competitive marketplace where everyone else is going stupidly fast? So what if I'm better, the foolish fast guys will beat me to the punch, right? What about Macs losing to IBM clones, even though they were supposed to be better? What about Beta losing to VHS? What about all the other “betters” that lost to the “fasters”?
As with all things, it's a balance. I think it's important to differentiate between the process and the output. The aim in agile development seems to be high quality process in order to turn out “good enough” functionality quickly. The good news is we have cheap, powerful tools in the world of programming that give us options to build in high quality automated processes. The problem Uncle Bob is railing against is how often we foolishly screw ourselves by not taking advantage of them.
Agile methodologies are about marrying “good enough” functionality with extreme automated infrastructure to keep the quality of the “good enough” feature set high.
See also CompletenessAndMaturity.
tags: ComputersAndTechnology AgileDevelopment
