Originally published 12 July 2012
Not so long ago, people built applications. There was a group of people that were developers, and they were gainfully employed doing what developers do – gathering requirements, building flow charts and functional decompositions, writing code, testing and having a generally merry time.
Then over time their lives changed. They shifted modes. Instead of developing new applications and systems, they were cast into what we call the maintenance mode. In the maintenance mode, people no longer developed systems. Instead they sat around and made changes to those systems that had already been built. Interestingly, the more they maintained systems, the more the code that they operated on became worn and frazzled. Soon what was once a well designed and clean running program turned into a Mary Shelley nightmare.
The first year of maintenance of existing code was a year where 20% of resources were dedicated to building and operating the maintenance function. The next year, 40% of resources were dedicated to maintenance. The year after, 60% of resources were dedicated to maintenance. Soon 100% of available resources were doing maintenance.
When 100% of programming resources were dedicated to doing maintenance, the organization reached a dilemma. There were no more resources for building anything new. It was like being buried in the sand and then the tide came in. End of story.
However, there was a continuing need for new systems. But how do you build new systems when 100% of your resources are dedicated to doing maintenance? This was the dilemma that shop after shop found themselves in not so long ago.
That was a long time ago, but how was the crisis resolved? In hindsight we realize that the vast majority of what was passed off as maintenance really wasn’t maintenance at all. When the applications were first built, the applications served an operational community whose job it was to get something done. But the requirements for building the application didn’t include the accountant who needed to keep track of what was going on. Or the engineer. Or the marketing person. And so on.
In a way you can look at the explosion of maintenance as a natural extension of the requirements that had been missed (or misunderstood) as the application was being built. Another way to look at it was that the operational requirements were the basis of the application that was built. But that the decision support – the analytical needs of the organization – were never considered as the application was being built. Once the application was built, the needs for serving the analytical community became apparent. It was inevitable that there would be an explosion of maintenance because there was a need to capture and analyze what was going on inside the application.
How did organizations get out of the dilemma? This is a complex question, but part of the answer was that they built data warehouses. Once the data warehouse was built, the organization simply let the end users do whatever analysis they wanted to do, and thus data warehouses alleviated many of the problems that were presented by the advent of applications. But life was not as simple as that.
Coincident with the building of data warehousing, the world discovered that third parties could build applications faster and better than they could. So there was ERP, and a whole host of applications that were built by outside agencies.
Soon the organization was not doing any maintenance at all. The analytical part was being done directly by the end users, and the applications part was being done by outside agencies.
The poor maintenance programmer went from being badgered for time and resources one day to not having a job the next day.
Today there are people in the IT staff of organizations who have never written a line of code. They do a good job, but the job that they do has radically changed from what people in their job did a decade ago.
And as if by magic, one day the maintenance backlog simply vanished.
Recent articles by Bill Inmon