Most large organisations struggle to keep control of their software maintenance costs. Many try to do this by trying to restrict which tools and techniques are used. This seems a reasonable strategy – the more homogeneous environment you can achieve the easier it ought to be to maintain. To a certain extent this may be true, but taken too far the result is almost inevitably the opposite – an ever increasing burden of maintenance costs.
Whatever you're buying, a good rule of thumb if you're concerned about maintenance, is to go for quality. Software is no exception. In fact with some estimating that maintenance costs account for over 90 % of software costs, it's a textbook example of this. There's nothing that dents your IT budget more than buggy applications.
What happens when you try to achieve a monoculture of techniques and tools? The people building the product are forced to use tools and techniques which aren't quite up to the job. And since any standardization effort inevitably lags advancements in technology the product will be dated before it's released. Is there anybody who thinks this is a good strategy for improving quality?
I have a theory. This theory is that the three most important factors for reducing the cost of software maintenance are:
The quality of the product – fewer bugs mean less maintenance.
Building the right product – often up to 80 % of software “requirements” aren't really required but add to the maintenance burden
Employing the right people – the wrong people will build the wrong product whether or not they use the mandated tools.
So what do you think? What's the most effective way of employing your brightest staff?
a) Set them to work mandating which tools and techniques are to be used and enforcing these policies.
b) Getting them to act as a motor for innovation by helping development teams to take advantage of modern advancements in software development.
I know which one I'd choose. And I know which organisation I'd choose to work for.
