Speed Kills
programmer.97things.oreilly.com
programmer.97things.oreilly.com
In the end, bad code is simply trading your time three weeks, months, or years from now for time right now. It's exactly the same as taking out a loan. Sure, it's cheaper to save and not pay the interest on the loan, but unless you have the luxury of time (You hardly ever do) the loan makes better sense both in the long and short term.
Every time you rewrite code, just think of paying interest. It's a lot easier to deal with if you see it as trade of for the nice warm house you're living in or laptop you're coding on.
The longer you go without paying the principal, the more interest you're paying.
Artists can afford to be perfectionists. A software artisan may wish for perfection, but this sort of tripe is exactly what I was referring to in this post: http://dailytechnology.net/posts/3
If you want to perfect software as an art form, then great, take this advice. But if you do it for business, then you realize that there is a trade-off when you aim for perfection. You may write the most stable, secure software in the world, but if nobody uses it, then who cares? You painted the Mona Lisa, and it's in a basement somewhere. Congrats.
Researchers have studied variation in speed of development between programmers. A common scenario are coding tests where different programmers are asked to do the same task. These studies have consistently found differences in speed of a factor of 10 or more. Follow-up research has found that programmers at the fastest end of that scale spend the smallest fraction of their time actually programming. Instead they spend time in other activities such as design and testing. So time invested in design and testing pays back during development. And not just in a large project, but in a sample coding exercise of less than a day.
Here is another data point of interest. Another study assigned multiple professional teams the same project, but asked each team to optimize a different thing. A few of the dimensions were performance, development speed, maintainability of code, and memory usage. Most of the teams managed to win on the characteristic they were optimizing for. The team that was aiming for maintainable code came in second on most of the other dimensions.
When you consider that as an industry we spend about 70% of our software development dollars in maintenance, aiming for maintainable code has lopsided benefits relative to the other options. Your code is done almost as fast as possible, performs reasonably well, uses a reasonable amount of memory, and costs a lot less to maintain. Situations exist where that isn't the optimal trade-off, but it is optimal often enough that it should be treated as the default.
Which is exactly what this article was arguing.
Design, however, is a whole 'nother ball game. As you pointed out, research has shown that most of the problems, and indeed the most expensive problems, are caused by requirements. (IIRC)
I suspect that sometimes it only seems like speed caused a bad decision when in reality, the decision came because the programmer didn't understand some part of the domain, especially didn't understand how to design the code to be extensible beyond a certain area. Indeed, speed is an excellent excuse for just failing to extend beyond a certain area.
The reality might be that whatever speed you went, you would first create a failed design and only after seeing the failure be able to create the successful design.
So... no magic bullet for you!
When you read the 5. of joels article (and some others points) you realize exactly in what this article must be right.
But without the facts this has no sense. Sometimes you need to go faster, but it's a tradeoff you will have to fix later.
What I want to know is how in the heck do you get to call yourself "Uncle Bob"? What? Is there like an agile family, with uncles and nephews and stuff? If so, I want to be Cousin Dan
-- Voltaire
Bla, blub