Under the bonnet
by Rob Macdonald
Taking a professional approach to software maintenance is good for staff and good for business, as Rob Macdonald explains.
HardCopy Issue: 61 | Published: November 1, 2013
It sometimes seems as if the developer community is in denial about the impact and importance of software maintenance. However the truth is that, over the last 20 years, more programmer time has been spent on maintaining legacy applications than on developing new ones. And these days, maintaining legacy applications is not just about dusty files full of COBOL and FORTRAN code but also vast quantities of Java, C++, Visual Basic and even .NET.
Any trawl of the available literature, programming tools or training courses will reveal that much less emphasis is given to maintenance programming than to development. However I would argue that maintenance programming is far more challenging, interesting and rewarding than green-field development. But first, let’s find out why software maintenance and software development should be treated as separate disciplines, each with distinct approaches to training, tooling and management.
The root of the difference between the two comes down to the operational demands each discipline faces. Put simply, developers are delivering a product while maintainers are providing a service.
I’ve never tried driving to my nearest car factory and asking the site manager to interrupt production because my oil needs changing or I want to upgrade my exhaust system – somehow, I know what would happen. Equally, I’ve never tried asking my local car service depot to rustle up a more efficient engine or design a quieter transmission. These comparisons may sound absurd, but that’s exactly what happens to programmer teams who are frequently expected to wear both the production and the service hat at the same time.
As a result, maintenance work tends to get structured around development plans. Maintenance requests are regarded as ‘interruptions’ to these plans and the inevitable failure to square the circle results in tensions at multiple levels: between programmers and managers, between user groups, and inside the heads of programmers who tend to resolve the issue by regarding maintenance as an occupational hazard.
The best way to manage the differing operational demands of software development and software maintenance is to create distinct teams for each function. Research amongst large firms has shown that organisations who take this approach have lower overall software costs and higher overall quality. The primary reason given is cultural: the maintenance function is allowed to develop its own processes and operate according to its own set of professional standards. This culture is service oriented and strongly focused around the user. Users appreciate the dedicated attention of the maintenance team and the status of maintenance is enhanced as a result.
As one maintenance programmer said to me, “Users drop by for a chat – that never used to happen when I was in the dev team. They can see how much better we’ve got at maintenance since spinning off a dedicated team. Doing it full time has allowed us to build up real expertise.”
Programmers still get together and argue as to whether Agile is a better development methodology than Waterfall. In my view, they are trying to answer the wrong question, as development is not the main event. Given that more programmer time is spent on maintenance than development (the latest surveys suggest a ratio of 3:1), it makes far more sense to focus on maintenance productivity than on development productivity.
A mature and effective maintenance function cannot be established overnight – it takes time to establish a process and a culture that suit an organisation’s needs. However, getting started is neither difficult nor expensive.
Aside from conviction, there are two essential ingredients that every maintenance team needs. The first is a framework for creating a maintenance process that provides scope for continuous improvement. Several such frameworks are available: I have found S3M (Software Maintenance Maturity Model), as developed at the University of Quebec, very useful in that it is easily adapted to both large and small organisations and is helpfully documented in a book written by its creators, April and Abran. Their framework lays out a progressive model for creating a software maintenance process and documents appropriate metrics to capture each stage of maturity.
The second essential resource is an effective issue tracking system for workload management and measurement. Finding mature systems specifically geared to maintenance is close to impossible, but fortunately more general purpose issue tracking software can often be customised for maintenance needs.
In addition to the basic functions of tracking and prioritising issues, recording time and supporting cross-team communication, an issue tracking system must be configurable to capture maintenance specific metrics. It is essential that the system can distinguish between maintenance requests, which can be scheduled, and problem requests, which require immediate attention. Each request should also be categorised according to the type of work involved.
ISO standards suggest categorising them according to the grid shown above. Corrective maintenance covers bug fixing while adaptive maintenance keeps a system up to date as its environment changes, such as an operating system upgrade or new external interfaces. Both of these categories are considered reactive. Proactive tasks include preventive tasks, such as anticipating failure resulting from latent bugs (Y2K is a famous example), and perfective tasks which are non-functional improvements to performance or resilience.
These are good categories, but as soon as you start using them you will run into trouble. Between 55 and 80 per cent of maintenance requests are for new functionality rather than ‘fixes’ to existing code, and should be recorded as such. Maintenance is often regarded as an expensive additional cost of a supposedly ‘working’ application. Once the business understands that the majority of what passes as maintenance work is actually adding new value to an existing asset, then both maintenance and development can be viewed more favourably. Categorising tasks correctly is the first step in this mind set change.
Brushing off the dust
Time was when nearly all commercial programs were written in COBOL. Now over 50 years old and generally regarded as clunky, no-one knows quite how much COBOL code is still in production. Some estimate 200 billion lines, and there’s no doubt that COBOL still underpins a vast number of the transactions that keep the world turning, and will continue doing so for many years to come. Much of that code is rock solid, having being hardened through decades of action in production.
Instead of re-writing trillions of dollars’ worth of code, many organisations are actively moving it to more relevant and supported environments, linking it into their on-line platforms and exposing it to modern development environments. There has long been a healthy market in both tools and staff for migrating and maintaining this vital legacy code base.
Several mature platforms exist for migrating COBOL code into the .NET and Azure environments which go well beyond compiling COBOL to MSIL and supporting Visual Studio integration. For example, GT (formerly Fujitsu) Software’s NETCobol for .NET can be augmented with tools that allow COBOL indexed file data to be moved into SQL Server without requiring any changes to existing COBOL file access code, allowing the same data to be manipulated by modern SQL-based tools and programs.
Washington State’s Department of Licencing has used GT’s platform to migrate 1.5 million lines of COBOL to .NET. According to Technology Manager John Hadden, “The beautiful part of the solution was the ability to take our current COBOL code… and port that without changing the business logic to Windows using NetCOBOL for .NET. By moving to this new platform… we can interface with other platforms much, much easier.”
April and Abran advocate going further and recording user support and one-off data extracts as separate activities typically performed by maintenance teams but not always recognised for the value they add. Once all this is taken into account, the true cost of ‘fixing’ a working application turns out to be much lower than first thought.
Combining these categories with appropriate time recording provides the basic metrics that can be used for measuring productivity and improving the accuracy of estimates. Metrics can be further refined using static code analysis tools such as the maintainability index and complexity measures generated by Microsoft’s Visual Studio. Ultimately, maintenance teams seek to define their ‘assignment scope’, which is the number of lines of code one maintenance programmer can keep operational. Assignment scope varies significantly between organisations. For C# code, it typically falls into anything from 20,000 to 300,000 lines of code.
Not only is more time spent on software maintenance than on development, but the scope for productivity improvement is usually higher. It is precisely because ‘getting better’ at maintenance can have so much more impact than ‘getting better’ at development that maintenance provides an opportunity for talented and ambitious programmers and managers to make a real difference.
It’s ironic that maintenance work is often dumped on junior staff because maintenance is generally far more demanding and rewarding than development. It takes real experience to make rapid sense of unfamiliar code and real judgment to assess whether a fix, re-write or re-factor is in the ultimate best interest of the business. It takes real professionalism to write code in a style you don’t like, knowing that consistency will benefit a future maintainer; and real humility to recognise that someone else’s style is just as valid as yours.
In return, the feedback and reward cycles in software maintenance are measured in hours or days, as compared to weeks for Agile and months for Waterfall development. Maintainers are closer to their users and closer to their business. They also never work on projects that get scrapped before going into production.
The enduring trend in software maintenance is the ever increasing amount of production code that requires maintaining. Understanding that software maintenance is a distinct discipline from development which thrives in its own culture is the key to turning an unloved chore into a cherished business function. It is also the simplest route to lower software costs and happier users.