It is not 80/20. It is 60/60.

Money comes in many colors, globally. For some reason, most people love green. Greenbacks.

A software is in “production” in the same sense that a power turbine or a manufacturing assembly line is in production, i.e. because it has real output and that output is being sold and/or used to run the business. A software in “production” helps generate money for the business. The revenue.

One of the fallacies we come across is that software development is the most important part of the software lifecycle. Many people do not realize that development is just not where the money is.

Malleability is the core property of any software.

“Another flaw in the human character

is that everybody wants to build

and nobody wants to do maintenance.”

- Kurt Vonnegut, Jr.

Software maintenance is critically important to the economics of modern engineered systems. In what has come to stay as the “60/60 Rule of Software”, acclaimed software engineer and writer Robert L. Glass, highlights that maintenance typically consumes about 40 to 80 percent (60 percent average) of software costs. Enhancements is responsible for roughly 60 percent of software maintenance costs. Defect fixes is roughly 17 percent. So, software maintenance is largely about adding new capability to old software, not about fixing it. (IEEE Software).

A common, incorrect perception of Maintenance is that it merely involves fixing defects.

Maintenance involves understanding an existing system, and modifying it without breaking things in the production environment. “Keep the lights on” or “keep the system running”, as they say. It is Operations. Therefore, it is probably the most important life cycle phase. 

In his book, “Software Conflict 2.0: The Art and Science of Software Engineering”, Robert L. Glass extols the virtues of software maintenance as follows. 

• Intellectually complex - it requires innovation while placing severe constraints on the innovator
• Technically difficult - the maintainer must be able to work with a concept and a design and its code all at the same time
• Unfair - the maintainer never gets all the things the maintainer needs, such as documentation
• No-win - the maintainer only sees people who have problems
• Dirty work - the maintainer must work at the grubby level of detailed coding
• Living in the past - the code was probably written by someone else before they got good at it
• Conservative - the going motto for maintenance is “if it ain't broke, don't fix it”

Most IT services organizations strive to win / retain multiple, multi-year, Maintenance contracts; because that is what assures them of a consistent, predictable and profitable revenue stream. That is what predominantly helps fetch people's paychecks and bonuses. Sadly, people who develop software are generally given much more credence than those who keep critical systems working, although the latter is complex and challenging.

One of the reasons many Developers think maintaining code is not attractive, is because the human mind feels it’s harder to read someone else’s code than to write it. This is also perhaps why code reuse is so evasive.

The status quo about Software Maintenance is all wrong. It is time we changed that.

Maintenance is a multi-faceted discipline. If we want to maximize our effectiveness at doing it, we should also significantly change the way in which we assign people to it. We should probably have our best architects, designers, developers and testers do software maintenance, as a matter of routine.

“Old hardware becomes obsolete; old software goes into production every night.”

- Robert L. Glass