by Krishna on September 6, 2008

Software development on new applications is only a fraction of maintenance work on existing applications. But almost all the conversation and writing on software tends to revolve around building new software — architecture, design, standards, code samples, etc. The consequence of this mismatch is that planning for software maintenance is often done as an after-thought and in very short-sighted terms.

After the release of a new software project and the immediate support needs, the project team is slowly starved (or sometimes, suddenly deprived) of resources that are pulled away into other immediate concerns. Less qualified developers are allocated to work on periodic bug requests. Inside the organization, working in the project is viewed as a career dead-end and developers try their best to avoid getting assigned to the project.

There is no surprise about what comes next. The product slowly falls in disfavor with the users. They start finding faults with it, calling it non-user-friendly, confusing and complex. Training does not seem to help, even (or especially) with manuals weighing several pounds. Finally, management calls it a day and starts on a quest to build a replacement from scratch, or buy or rent a new tool. This repeats cycle after cycle.

Throwing away outdated equipment and building/buying a replacement is not essentially a bad thing. That is what we do with automobiles, furniture, kitchenware and so on. But software is more malleable. And often, the money spent in replacement is much greater than the effort it would have taken for proper maintenance, not to say anything about avoiding the frustration of end users working with the increasingly obsolete software.

Like tangible products, software products also decay. They do so because the environment around them keeps changing. The rules of the business change. People’s expectations about user interfaces change. The increased quantity of data and number of users requires performance tuning as well as better physical resources. The quality of data also brings new challenges of organization and reporting. Superior technology makes the existing architecture and design outdated. New security threats appear.

The more successful and established an application, the faster it will decay. Having more users means greater expectations as well as a multitude of differing views about what the software should do and how it should behave. Therefore, maintenance requires the same or greater level of resources that went into building the application in the first place.

If the success of the software is directly translated into revenue, allocating necessary resources is a no-brainer. However, when a company falls well behind the market leader, continued investment is not enough to catch up to the market leader, because there is not enough revenue. It is better to target a niche market at that time. Another mistake is by the market leader who decides to reduce investment and “milk” the market, thus allowing competitors back into the game.

When it comes to internal corporate software though, there is no revenue to feed the maintenance needs. Since only the costs of maintenance are visible, the trend is towards starvation, not more resource allocation. One suggestion I have is to spin the product team off as a separate organization with a profit motive and with the intent to supply software to the parent organization. If there is better software elsewhere at a similar cost, the child organization would cease to exist. Hence it has the motivation to continue to maintain and improve the application.

Although the idea of having a separate company for the sole purpose of writing software for one organization may seem ludicrous, there are many companies doing exactly that, serving a single entity, such as the federal or state government, the military, schools or Fortune 500 companies.

Dealing with an external entity forces the organization to build or choose the right software. The external organization is in charge of managing its costs and revenues. Its developers are more motivated since they can see the financial results of their efforts. There is no question of moving them to some other priority inside the main organization. Overall, a win-win.

Comments on this entry are closed.

Previous post:

Next post: