Mar
21
2008
False Economy
Posted by Dan Creswell in Software, tags: development, Engineering, SoftwareA couple of false economies software development indulges in:
- It’s quicker for me to write the code than explain the design to someone else.
- Automated deployment will have to wait until we have more time.
Number one costs a software development team in a number of ways:
- The career development of other members of the team is slowed – if one never discusses design how does one expect to obtain good designers or architects?
- The team’s development capacity is reduced – essentially projects bottleneck around the uncommunicative heroic individual.
- The team’s effectiveness is reduced – project load cannot be divided efficiently because individuals have skills in narrow areas limiting the breadth of work they can perform.
- Team morale is damaged with other developers feeling left out, unfulfilled and unable to influence project decisions
Number two yields costs including:
- We save on some development time but the cost is re-surfacing in staff-hours required to perform the deployment.
- An increasing number of mistakes that extend deployment time or breaks releases.
- We save development time once and pay the price for that saved time with each and every deployment.
- The cost of each successive deployment increases because the system’s size is growing.
- As each deployment takes ever longer, the gap between releases is likely to increase.
Entries (RSS)
And of course there is number 3
3) Automated Testing is too expensive at the moment, we’ll add it in later if there are any problems
Uh hmmm, good point. I was going to suggest that perhaps we’d got that one under control but of course I see with my own eyes that it isn’t on a regular basis. No doubt many would leap forward and pronounce TDD the solution, which it isn’t (http://beust.com/weblog/archives/000477.html). Maybe (4) should be:
(4) It’s all about code – we don’t need a stinkin’ architecture.
I guess I don’t get the TDD arguments. For me, it’s a simple way to force myself to think more about class design with the side effect of having that class unit tested at the end. Paired with my current tooling, I also get productivity benefits from being able to autogenerate parts of the production code off it’s inferred usage in the unit test. If you don’t want to do it, fine, but don’t become an anti-tdd zealot (which is just as bad as being a tdd zealot)
As for the TDD YAGNI implications on architecture, that works but only if you know you are building something architecturally simple (such as a simple layered application). If I had to guess, that’s probably the type of application many of the extremeist YAGNI folks are building (and I’m sure it works great for them).
Those who have dealt with more complex systems know that to not think about architecture is really just gambling with the success of the project.
Of course, for the simple layered system, doing a lot of “architectural” work up front is just as bad as not doing architectural work on the more complex system (think: both scenarios may double the cost of the app).
In short, it’s all about context. If anything is true in software these days, it’s that there is no universal right or wrong way to do software development. Context is king.
“I guess I don’t get the TDD arguments. For me, it’s a simple way to force myself to think more about class design with the side effect of having that class unit tested at the end. Paired with my current tooling, I also get productivity benefits from being able to autogenerate parts of the production code off it’s inferred usage in the unit test. If you don’t want to do it, fine, but don’t become an anti-tdd zealot (which is just as bad as being a tdd zealot)”
Yep, it should be a pragmatic exercise. You should test, and automation would be nice but TDD cannot be allowed to drive your architecture to significant degree. Testing is an important facet but there are many other forces that influence architecture and determine it’s success in the longer term.