Peeling Away at the Software Maintenance Process

When you go to the shops and purchase a potato peeler, you receive the exact potato peeler that you picked up off the shelf. Five years down the line – if you have taken good care of your potato peeler – it will still work as well as it did on the day you purchased it. More importantly, however: it will still take the same form and have the same functionality as it did when you bought it (ignoring a few minor scratches, of course).

If one day when peeling potatoes you wished that your peeler could also be used to slice cheese into thin slices, you couldn’t simply take your peeler back to the shop in which you purchased it and ask the shopkeeper to exchange your old peeler for a newer model with all of the latest features. You could, however, buy the fancy new peeler outright if you so desired. It would be infeasible for the shopkeeper to keep on exchanging old items for new items in order to meet consumer demand, both in terms of practicality and – primarily – from a costing point of view.

The same line of thought can also be applied to large-scale software development projects. A survey conducted in 2010 – with contributions from over 2000 IT businesses both big and small – showed that the average software development company dedicated 55% of their annual budgets to performing maintenance tasks on pre-existing software solutions [1]. A second research survey suggested that the figure was more likely to be nearer two-thirds of a company’s budget – this is a massive figure [2]. While it appears that nobody knows for sure just how much the industry is spending on software maintenance, it is clear that the figure is steadily increasing as the years go by. It is my opinion that the budgets set-aside for the maintenance of existing software is too high, and could be significantly reduced if software development companies were less willing to bend to meet consumer demand.

It is well understood that there are forms of software maintenance which are unavoidable and – indeed – necessary: for example, bug fixes and the alteration of software to adhere to new or changing industry standards (e.g. a new memory management model being used as standard on new systems) [3]. However, there are concepts of the current understanding of ‘maintenance’ which I feel could be excluded from the process. The addition of new features to software is a common maintenance task. Whether it be a request and/or pressure from consumers to add to the existing software solution, or the development team actively choosing to augment the current solution, I feel that this sort of activity should not fall under the heading of ‘maintenance’ – but under another heading altogether. There has to come a point in the maintenance phase of the software’s lifecycle where the developer decides “enough is enough: the project has evolved into something too far-removed from the original concept.” When this point comes, the current time and effort being invested by developers can no longer be considered ‘maintenance work’, but another project entirely.

Returning to the example of the potato peeler outlined above: if you wanted to extend the functionality of your peeler, you wouldn’t be able to do it yourself (the average person couldn’t, anyway). The logical – and indeed, only – choice you would have would be to buy a new peeler which meets your new functionality requirements. The same concept should be applied to software. A development team will provide a company with the finished software solution to their outlined requirements and standards, and should from then on only perform routine maintenance to prune-out bugs and glitches. The addition of new features to the solution not outlined in the original requirements specification should be considered as ‘extensions’, and should constitute both a separate project and separate product. An example of this today would be downloadable content for video games: content which is not intended to be released as part of the initial solution, but can be purchased for an additional fee at a later date to extend the functionality of the original game. Using a solution such as paid software extensions could allow developers to shrink the size of their maintenance budgets, freeing up time and money to be reinvested in other projects the team is working on. Meanwhile, when creating additional content for software, costs of such an extension could be recouped in the charging of a fee to the client for the purchase of said content. Therefore, the maintenance budget has been reduced, and more revenue can be generated in the development of an ‘extension project’ for the client.

I can completely understand that, over time, the needs of a user can change. However, I feel that software developers should not be shackled to projects completed in the distant past. The solution delivered initially by the development team met the user’s needs at that given time: this should be the full extent of offering and implementing functionality to the project from the developer’s point of view. If the user needs the original solution to be moulded into another form, then they should have to fund this process – after all, you don’t see merchants of potato peelers handing out new models with sharper blades to existing customers when a new variety of tough-skinned potato is brought to market. If manufacturers of physical products don’t have to provide long-term maintenance, why should the developers of an intangible software solution have to?

The process of maintaining a large-scale software solution can be a very costly process. Over time, an initial solution can mutate into a completely unrecognisable form – nothing like its previous self. In my eyes, this should not be considered ‘maintenance’, but the development of a separate project. Maintenance budgets could be significantly reduced, and more revenue could be generated in the creation of functionality upgrades. The needs of a client can change over time, but it should not necessarily be the case that the development team should need to invest both their time and money in fulfilling such changes.

After all, if you aren’t happy with your potato peeler, buy a new one.

References:

1:
Technology budgets 2010: Maintenance gobbles up software spending; SMBs shun cloud | ZDNet. 2014. Technology budgets 2010: Maintenance gobbles up software spending; SMBs shun cloud | ZDNet. [ONLINE] Available at: http://www.zdnet.com/blog/btl/technology-budgets-2010-maintenance-gobbles-up-software-spending-smbs-shun-cloud/30873. [Accessed 14 March 2014].

2:
IT budgets to rise in 2013 despite downturn. 2014. IT budgets to rise in 2013 despite downturn. [ONLINE] Available at: http://www.computerweekly.com/news/2240174469/IT-budgets-to-rise-in-2013-despite-downturn. [Accessed 14 March 2014].

3:
Allan Clark. Software Architecture, Process, and Management (Slide 678). 2014. Software Architecture, Process, and Management. [ONLINE] Available at: http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/678. [Accessed 14 March 2014].