The Code Base is an Asset

Having recently completed a maintenance engagement, yes architects do get involved with maintenance, hence I am going to use this posting to rave on and on about code as an asset.

The concept of custom developed software as an Asset totally escapes most organisations and as result of poor asset management, they end upstanding under the shower ripping up hundred dollar bills to keep their software applications running.

In my example, you have an organisation that has developed an online application to facilitate the exchange of information between thousands of commercial users. The nature of the exchange means that there are financial impacts for the users and the application host, so there is a degree of motivation and funding to keep the application operating.
Here is the amazing part; they invested large amounts of money in building the application but did not give one thought to how they would keep the application running and evolve it to meet changing requirements.

The strongest evidence of this was present in the code, you could see how things began, there where unit test for all the early functionality, the naming convention was clear and the design of the application appear to be thought out, and the underlying theme was MVC. Then you could see the first round of changes to the application, which was a walk on the wild side, the second around trying to keep with the original approach and the final around, was a perfect demonstration of over engineering. The whole concept of less is more had escaped some of the folk that worked on this application.

So why does this matter, if the application is doing its job and working why are you banging on about all this internal stuff. Simple it effects productively and productivity equals dollars, in other words you end up paying over the mark not by a little but by a ton, are you interested yet?

Now it is easy for me to sit here and say folks should be more professional, but that is unrealistic, often the developers who work on this stuff have ten or least years experience in the industry they are not aware of how terms of engagement can affect their output let alone know how best manage these situations.

The root cause for the above problems which results in wasted dollars on maintenance is ignorance, ignorance of the promise of OO and how to harvest the benefits, ignorance that code is an asset and it can be and should be managed like any other asset. Let us get practical with an example, Application A has taken 3,500 man-hours to build at a cost of about $612K dollars, there is annual hosting & operating cost of $25K (excluding software maintenance and changes cost). This plus the depreciated cost of the development results in $230,000 expense on the P/L annually, this is the start of the hard questions.

Is the system meeting its financial and operational objectives and at what level will it start not to meet those objectives, if maintenance cost rise (putting aside changes for the moment as they normally come with their own set of productive gains or new revenue opportunities).

This is starting point for a software maintenance programme; we need to be able to say if we send more than X this year on maintenance of y over the next z years (z being the effective remaining life of the application) then the viability of the application is under question.

From here, a maintenance strategy can be constructed, which is based upon a code audit, which identify areas of risk, these can then be proactively refactored to mitigate the risk arising from them.

This is a good time to share you with you the number one question I am often asked about maintenance as separate issue away from change. If the application is working well now, why would it break and if there is no reason for it to break then why carry out maintenance?
It is actually a very good question, if the application is running well now and has been for a while, then the risk of it stoping or breaking tomorrow morning is low. That is not the type of risk maintenance looks to mitigate. Maintenance focuses on parts of the application that can break easily when change occurs, for example, let say that backend database needs to be upgraded or a new functionality needs to added, the application should be in such a state that those changes should not break the application.

Another practical example let us say a new feature needs to be added to the application and the original estimates where 20 hours work for the implementation of this new feature. In implementing this feature using best engineering practices, the security mechanism of the application is broken and to change the mechanism so it can work with the new feature will require 80 hours. All of sudden a 20 hour improvement has turn into a 100 hour job which could render the new feature uneconomical to deliver, after all 100 hours is about 3% increase in the total hours invested in the application.

In a refactoring situation, parts of the security mechanism can be changed at a leisurely pace without needing run resources in parallel to meet the deadlines. It still might result in 80 hours work but it cost dramatically less due to resourcing.

I hope this posting can help you see how quickly maintenance can get out of control and why you need, a plan and ideally locked in contracts with vendors prevent these situations from arising. If you know the risk, you can transfer it to a vendor.