the new software paradigm
maintenance versus development
From a software engineering perspective, "maintenance" refers to a piece of work that takes an existing software artefact and produces a new version, either to better satisfy the old requirements, or to satisfy some new requirements. This is not the same thing as producing new artefacts to satisfy new requirements, and demands rather different techniques - although perhaps the same notations.
From a business point of view, the purpose of a software project is to alter the characteristics of some business process. Practically all business processes these days already contain a considerable degree of software automation and electronically mediated communication. So from a business point of view, practically all software projects are carrying out a maintenance activity on a business system, regardless how many new software artefacts they may generate. To describe such a project as a development project, or to use a method that is primarily designed for development, implies a restricted view of the project, foregrounding the new software elements and pushing the existing stuff (with which it must interoperate) to the background.
So is maintenance the same as development, or not?
We don't see maintenance as a continuation or extension of development. On the contrary, we see development as merely a restricted view of maintenance.
The same activity is described one way (as maintenance) from a business perspective, and another way (as development) from a narrow software perspective.
Maintenance is commonly regarded as the Cinderella of data processing.
It is unpopular with staff because:
|They are not confident of doing the job well.|
|They expect it to be boring.|
|They fear being blamed for other people's bad work (i.e. if a given task takes too long, or is not done well enough, it will be the 'fault' of the person doing the maintenance rather than on the system or program being maintained).|
|They suspect that new systems development would be better for their careers (i.e. if it is generally assumed that only second-raters get stuck with maintenance, nobody will volunteer).|
|Maintenance is badly managed and inadequately resourced (for the reasons below)..|
It is unpopular with management because:
|Managerial objectives are often formulated in negative terms (e.g. avoid degradation to systems or interruption to services).|
|It consumes resources without obvious results.|
|It is difficult to motivate staff (for the reasons above).|
Thus the best staff and the best managers tend to get the 'plum' jobs in systems development, leaving the less glamorous, yet arguably more difficult, jobs to the others.
Many DP installations support their systems development team with tools and techniques, methodologies and standards. Yet the maintenance team often do not receive equivalent support, which confirms the low regard in which they are held. Maintenance may be assigned to those members of staff believed to be incapable of learning anything new.; Or perhaps as punishment for building a bad system in the past, a programmer/analyst is condemned like Sisyphus to maintain it.
Because the structured methodologies are fairly new, they carry glamour. Then because they concentrate on systems development and ignore maintenance, this itself widens the glamour gap', which may however be narrowed by enhancing those methodologies to cope with the extra complications of maintenance, and finding ways of applying the existing tools on existing systems.
COBOL developers are not second-class citizens just because they're
not doing it in Java or Visual Basic. COBOL remains a
perfectly respectable way of developing software - including distributed components. It is the process that is important, not whether you're using a fashionable programming language.
The concerns of COBOL developers typically include legacy systems, legacy data stores, and (given that many of you have used structured methods) legacy models. Thanks to long attention to these concerns, COBOL developers can make a very useful contribution to the maintenance paradigm.
The new software process needs to be maintenance-focused rather than development-focused. This means that I try to avoid talking about a development lifecycle, and prefer to talk about software and system evolution and alignment. Alignment as an ongoing process, not as a state of rest.
The world of maintenance (which of course many COBOL programmers inhabit)
is often quite different to the world of development. Maintenance is a
permanence evolutionary process, not a simple development process.
The goal of
maintenance is to realign things that are constantly getting out of alignment, thanks to changes in the business requirements, changes in user expectations, changes in the technological base, or the emergence of defects. The maintenance programmer is trying to do the best he can, despite the fact that many of the factors are out of his control. Maintenance activity is often squeezed into artificial projects, but this rarely aids management control.
Different metrics apply to "maintenance" as opposed to "development". Even if we've agreed how to measure productivity of development, measuring the productivity of maintenance is a different kettle of function points.
This notion of concurrent engineering is increasingly relevant to software engineering. An insurance company nowadays must design a new kind of insurance policy in parallel with building the IT systems to support this policy, and the new components must plug into legacy systems that are constantly being altered, using interfaces that are frequently being redefined.
This means that you must do the strategic planning and the requirements analysis and the software design and the prototyping and the testing all at the same time. Or rather, you must have all these activities going on in parallel, with regular alignment between them.
If we divide the software process into separate interoperating activities, this has the additional benefit of allowing information and techniques specific to that activity to be encapsulated within the activity, rather than shared across the project. This reduces the otherwise exponential growth of project information, and helps manage the complexity of the software process.
In my 1994 book, I stated that many of the perceived distinctions between development and maintenance were in fact illusory, suggested that the traditional division between development and maintenance was going to disappear, and urged for common planning and methods across development and maintenance. (This was based in part on Christopher Alexander's 1987 book, which to my knowledge has not yet been taken up seriously by other software engineers. But then it did take about 15 years for each of his previous books to make the journey from architecture into software engineering, so there's still time.)
Copyright © 1999 Veryard Projects Ltd