Jeff Atwood is up to his old tricks. He’s succinctly reminds me of why I read his blog so religiously (though like religion, I tend to be a cynic and not agree with everything he says). I read the McConnell books a billion years ago and have forgotten about this excellent analogy of painting the dog house.
Essentially it is saying that building a small project may require you to make a lot of shortcuts if time is of the essence. It is ok to make these shortcuts knowing that we will need to re-paint the dog house one day. Fido can live with rusty nails and flaky paint. On the other hand if you are painting a 747, you better get it right.
This is a basic issue with RAD development versus large project development. Development of any kind has to weigh the cost of any part of the project (including planning, isolation, containment, requirement gathering, bug testing, etc.) against the benefits. Unlike the analogy, the reality is that there is a wide ranging curve between the dog house and the 747. Most projects need some level of software engineering and process to get it right, but at the same time most projects require shortcuts to fit into schedule, skill set and feature set. That is the reality of software development…always has been.
Building reusable libraries, services and widgets takes time to get right and sometimes one-offing a feature is a better idea. But unlike painting, sometimes refactoring can help in big ways. Once you get the thick paint on the dog house, you usually will have to peel, primer and repaint to get it right. Software development is not always that way. Sometimes thoughtful shortcuts that can be refactored are the correct middle-ground. That’s been my experience…especially the last few years as lines of code have become easier to write (e.g. fewer memory leaking searches, less ref counting fiascos, etc.).
Steve and Jeff are both right that you can easily turn a good project into a bad with inadvertent management decisions, but it is not quite that black and white.
What do you think?