mentis vulgaris
simple thoughts | jason smith
If You’re Not Designing For Change, You’re Wrong.
Posted by Jason Smith - 31/07/09 at 06:07:39 pmThose who cannot remember the past are condemned to repeat it.
– George Santayana
For years, I defined “good software design” as something that produces robust software while satisfying or exceeding requirements. I discovered holding on to that mantra meant I would eventually starve.
The problem with that definition is it doesn’t go nearly far enough. If writing code puts food on your table, the definition of “good software design” must ultimately distill down to:
Good software design produces software that maximizes what it earns and minimize what it costs to produce.
Certainly, the software we write must be good enough for people to pay for it (and tell their friends about). But we also must remember that when software costs more to produce than it earns, we still go hungry.
So the formula for good software is something like:
Good Design = “So good, people want to buy it” + “Reduces costs of producing it”.
A lot has been said about the first term. I want to talk about the second.
Some interesting information:
-
Historically, between 60-95% of the lifetime cost of software production is spent in maintenance. [1,2,3]
-
By far the largest cost incurred post launch (around 80%) is for enhancing a product (not bug fixes). [1,2,3]
-
Studies suggest that in recent years, the maintenance side of the ratio has grown. [1,3] Our software lifetime isn’t growing, the cost to maintain it is.
So, change is the most expensive part of producing software.
Software we write today will change.
Its environment will change. It will be used in situations we didn’t think of; applied to new technology. Features will be added. Bugs will be addressed. Code will be stretched, stressed, warped and shredded.
Yet the data suggests developers spend little to no effort making code easy to enhance. Anyone who has maintained much code knows that as time goes on, changes become harder and harder to make. It’s said our software begins to rot.
A common reaction to software rot sounds something like: “OK, it’s clunky (rotten, brittle, spaghetti, whatever). Let’s rewrite it”.
Unless you have a lot of cash to burn, that’s probably the worst response.
A rewrite was Netscape’s plan with Mozilla, Borland’s plan with dBase and Lotus’ plan with 123. All of those products were at the top of their categories when their rewrites began. While they were busy rewriting their “brittle software”, their competitor added features to their own products. And when the rewriters finally delivered their product, they were bloated, inefficient and had fewer customer-desired features than their competitor. These former category “number one’s” never regained their dominance, experienced financial meltdowns, and are now presented in articles like this as bad examples.
Those outcomes really aren’t surprising, either. Recent surveys state only 1/3 of all IT projects can be called “successes”, with most being over budget [4]. No matter how you slice it, ground up rewrites are risky, more likely to fail than succeed, and not a cost-effective solution.
Especially when there is an alternative.
Yes, there’s an alternative. Coming blogs will talk about that.
References:
-
http://elearning.tvm.tcs.co.in/SMaintenance/SMaintenance/6.htm
-
http://www.softwaremag.com/L.cfm?doc=newsletter/2004-01-15/Standish
2 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds.
Valid XHTML and CSS.
[...] again, all software changes, so it’s a moot [...]
Pingback by mentis vulgaris » Is Your Code SOLID? OCP and Fighting the Cost Of Change — February 26, 2010 #
[...] In reality, verifying your code works is just one benefit of unit tests. There are other, further reaching benefits, when you realize the where the bulk of software development cost really lies: [...]
Pingback by mentis vulgaris » Why Unit Test? — March 2, 2010 #