Friday, September 9, 2011

A note on craftsmanship

Considering that the lion's share of software development costs is spent in maintenance, doesn't it make sense that the up-front investment should be spent in making sure that maintenance is as low cost as possible?

Often times we are driven by project timelines and drop-dead dates only to be saddled with a big lump of unmaintainable code.  I've been doing some reading on software craftsmanship and admittedly, some things make you wonder if the tedium of 'extract til you drop' and 'test first' are worth the effort...after all, it seems that some things could potentially double the initial development time.

If 75% of software lifecycle is in maintenance, and 25% is in initial development.  Suppose I double my initial development; if my maintenance is costs are cut in half, then I've saved about 12.5% of my overall cost of development.

25 * 2 + 75 *.5 = 87.5%

If I can reduce my initial development by half, but it doubles my maintenance costs, then it will eventually cost the organization an additional 62.5% more than it had to and as much as 75% more than it would have if I had just spend some more up front time making code maintainable.

25 * .5 + 75 * 2 = 162.5% + 100 - 87.5 = 175%

Easy math for the brass.


Sandy said...

Interesting concept.

How do you prove to the brass that the delayed release has actually resulted in less maintenance?

If the motivation of less maintenance is more new features and less patch releases between the next release. How do you show them your up-front efforts have paid off?

Extending a deadline they understand.

Perhaps the metric is: number of reported bugs post-release related to the new features of that release (pro-rated by the extra time spent)?

Unknown said...

Good point...I'm not sure you can show anything up front, but I've found feature development to be a fair bit quicker when the code is meaningful. I can usually show a faster delivery of new features a few sprints in if the code is clean.

In my opinion is you can't manage what you don't measure. Time to resolution on issues is likely a good measure.