veryard projects - innovation for demanding change

maintenance

the new software paradigm

on this page

> what is maintenance?
> why is maintenance a problem?
> what's wrong with COBOL?
> from development projects to a maintenance process
> concurrent engineering

on other pages

> software lifecycle
> software and system evolution
> organic planning
> legacy

home page contact us

maintenance versus development

	Maintenance takes over from development as the dominant software paradigm.
	Development and maintenance methods converge, as the same (or similar) techniques and notations become available in both domains.
	"Pure" development becomes increasingly rare. Growth of iterative and evolutionary development - in other words, maintenance by any other name.
	We often avoid calling maintenance by its true name, because "maintenance" is unpopular with staff and management alike.
	Old languages and old platform are usually less glamorous than the new ones. Maintenance often means working with old-fashioned data structures, COBOL rather than Java, IBM mainframes rather than Linux servers.
	The maintenance paradigm addresses many important software concerns, including business/IT alignment, legacy renewal and reuse.

What is maintenance?

If you think of development as building some artefact, then it may be natural to think of maintenance as building a new version of an artefact. This means that maintenance is like development, but with some additional complications - such as reverse engineering, reengineering and transition. Then a maintenance method is merely a somewhat complicated version of a standard development method. That's exactly how many formal software processes and methods regard maintenance.

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.

Why is maintenance a problem?

Here's what I wrote in 1985, depicting maintenance as a complicated form of development..

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.

What's wrong with COBOL?

From a software engineering perspective, "maintenance" appears to be less glamorous than "development", even when they involve the same programming language and platform. Put this together with the fact that COBOL is less glamorous than Java, and IBM mainframes less glamorous than Linux servers, and it's not surprising that COBOL seems to have an image problem.

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.

From Development Projects to a Maintenance Process

Most development methods start from the notion of a development project. A project involves a project team, carrying out a defined collection of tasks, under the control of a project manager. A project delivers a product, which is first built, then tested, then installed. Within this notion of project, iteration merely means having several attempts at a given task, and parallelism merely means breaking the solution into subsystems or components, and doing the same development task on several components at the same time.

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.

Concurrent Engineering

Modern manufacturing increasingly uses the notion of concurrent engineering, where instead of first designing a manufacturable product and then designing the manufacturing process, you do both at the same time. Successive versions of the product are "developed" in parallel - thus the designers have already started work on version n+2 before version n+1 has been put into production. (For one hardware manufacturer I worked with, a couple of years ago now, the entire lifespan of a laptop computer was 10 months - 3 months for design, 6 months for production and 1 month for disposing of the now obsolete stock. This was for major design versions, not just minor specification upgrades.)

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.

Previous Work

In the past, I took the methods perspective on maintenance, seeing the virtues in bringing the prevailing practices of software maintenance up to the best practices of software development.. In a paper I published in 1985, I outlined the piecemeal use of structured methods for the purposes of software maintenance.

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.)

top

home page

	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)..

	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).