|
Re: Architecture the Accelerator
|
Posted: Feb 24, 2005 6:12 PM
|
|
> > The way I map the stairs metaphor to software is via > cost. > > ... > > I appreciate the story, but I don't follow the > relationship to quality you're asserting. It seems that > you're simply pointing out the "plush" steps cost more. > And that's OK because they're worth more. Maybe I just > need to read closer... > Plush steps cost more to build than cement steps, and it is worth spending the extra money up front on the lobby stairs because you judge that extra investment will help you make more money down the road. Well-designed, well-factored, well-tested software is more expensive to build than a quick hack, and it is worth spending that extra money up front only to the extent it will create business value down the road. (The way quality code does that, primarily, is by making that code easier, and therefore faster and cheaper, for programmers to understand and change in the future.)
Similarly, paying someone to vacuum the lobby steps twice a day costs more than paying someone to hose down the emergency steps twice a year, and you pay that extra money if you judge you'll get a good return. Paying developers to spend time refactoring and cleaning up existing code when making an enhancement costs more than paying developers to just hack the enhancement into place, and that is worth the extra cost only to the extent you judge it will give you some payback in the future. (Once again, the payback generally manifests itself by making future changes cheaper and faster.)
> <reading...> > > I still don't see the relationship to quality. It feels > more like an argument to make sound investments. Like > financial investments, knowing your goals is half the > battle.
Yes. I'm talking about the programmer as an investor, someone who assesses risk and ponders return on investment when deciding how to approach each programming task. I believe Uncle Bob is talking about the programmer as a craftsperson, a "codesmith" who takes pride in his or her work. These are not at all mutually exclusive views of programming, but it is important that one not dominate the other completely.
|
|