Imagine you just started your own gardening company. Your first customer, Mary, was very happy with your dedication, personal attention and praised the quality of your work. “Never have been happier with a gardener she said, great results for a reasonable price”.
Soon the word gets out. A second happy customer. And a third. The gardening business is booming and you are a successful player. New customers pop up like mushrooms. You nourish each new customer. Personal attention and a customized approach is your trademark. And after your first year you laid out 25 gardens!
In your second year, Mary calls: “Could you please come over and prune the apple trees for me?”. “Oh, and it would be great to have the lawn mowed each week”. Of course you do not want to disappoint your first happy customer. You agree to the work. Meanwhile the word is out there on how well you treat your customers for an affordable fee. The phone keeps ringing with new customers requesting new gardens to be designed. But also last year’s customers want their gardens maintained. In your second year, it may not be possible to accept the same amount of new customers and serve your existing customers with garden maintenance at the same time. As you cannot let your existing customers down, you decide to accept less new customers. So in the second year you only accept 20 new customers and to sell “no” a few times. Now in the third year, you have 45 customers requesting maintenance. You start to realize you cannot serve both new and existing customers at the same time. If this trend continues you will be doing maintenance only in a few years. What should you do?
This simple story reflects a choice any business leader has to make. Once you have acquired customers, you have an obligation to serve them well. This takes capacity and removes some of your initial speed and agility. Companies that do not plan to scale proactively, may become victims of their own success quickly. If you sell your customers explicitly or implicitly ‘free’ support over the life cycle of the product, your price at the point of sale need to cover life time support costs.
In software development, we face a similar challenge. Each year a team creates new code but also is required to maintain code created the previous year(s). And similar to gardening, each line of code released to production needs year-on-year maintenance. If we assume that the maintenance required, is a fixed percentage of the amount of code created, the teams productivity will decline year on year. A quantity is subject to exponential decay if it decreases at a rate proportional to its current value (see https://en.wikipedia.org/wiki/Exponential_decay). This seems to be the case for software productivity as it decreases as a function of the amount of code already created. The formula for exponential decay is
Here’s a plot of different values of alpha:
All quantities subject to exponential decay move towards zero. The same holds for software productivity. That’s right, if you create and maintain software long enough with a constant team size: your productivity will go zero. The speed alpha in which this happens, depends on the maintenance required:
- Code quality (fixing bugs)
- Software obsolescence (windows OS obsolescence, 3rd party libraries, database versions)
- Hardware obsolescence (video card drivers, pc card drivers)
So what will business leaders do to fight the decline in productivity? They can hire more software engineers of course. To save on cost, they may decide to choose develop in lower wages countries or use developers just from university. While there are exceptions, inexperienced developers create more code than necessary and often at lower quality. The law of exponential decay kicks in and will bring team productivity down even quicker.
Unlike our successful gardener, who enjoys customers that are willing to pay for maintenance and could grow his staff to meet the needs, willingness to pay for software maintenance is not high. Unlike gardens, that visibly require maintenance, software maintenance needs are invisible to everyone but the developers themselves. Software customers and stakeholders wonder: “Why should I pay to get functionality I already paid for?” This is even strengthened by consumer companies like Apple and Microsoft providing updates for free. Software companies serving B2B increasingly move towards subscription based models instead (http://www.gartner.com/smarterwithgartner/moving-to-a-software-subscription-model/)
Dear software consumers / business leaders / decision makers: you are asking to maintain your garden for free. No: your software team does not suck if they make slow progress on a legacy code base. Moving software to a lower wage country will not solve the real problem but temporally hide it and will leave your successor to tackle it. Adding a lot of people to make speed only will make the problem worse as the team will start to increase the amount low low-quality code. The rewrite from scratch your technical leader asks for, is also not going to make the problem disappear: you may well end up paying to maintain two software stacks.
You pay to maintain your garden. You pay to maintain your house. You pay to maintain your car. You will have to pay to maintain software as well. The more software you own, the more you will pay. Owning software is both an asset and a liability. It is an asset as the existing software delivers value for customers. It works and generates revenue. It is a liability as the costs to maintenance and enhance the software are ever growing and seldom quantified.
At the same time, the software engineering function needs to mature to reduce the cost of software maintenance. While focus on team capabilities, pair programming, devops continuous integration and tools can be helpful in raising initial code quality, the variation of code quality is still way to high. Contemporary software architecture techniques fail to model complex systems robustly against technology changes and fall short of industry needs Method, tools and vendors change too often. Individual talent still is a too dominant factory in the quality of a software stack too often.
What can we do to radically improve software quality and lower the cost of software maintenance? I personally believe the answer lies in the maturing of model driven engineering. Any model captured in a domain specific language (DSL) has a higher expressive power per ‘unit productivity’ than a general-purpose language, so a higher initial productivity. Maintainability of a domain specific language is higher by design. With knowledge explicitly modelled in a DSL, code can be generated towards operating systems, hardware, languages, tools and 3rd party libraries that do not exist yet today. Some of the maintenance cost will move towards the code generators but compared to legacy software, the code for generators will be small.
Modelling languages should be concise and expressive but understandable by domain experts (not only software engineers). To enable the definition of model transformations, all model languages should have explicit meta-models. To be maintainable over long periods of time (>20 years), model languages need to be technology independent. Models formats should allow for easy merging and be vendor agnostic. At Philips healthcare IGT systems we successfully apply model driven engineering techniques to keep our software stack in good shape.
What solutions have you successfully used to radically lower the cost of software maintenance? How is your company dealing with the liabilities of owning a legacy code stack your customers depend on? Are you always able to ‘sell’ the cost of software maintenance to your customers, stakeholders or decision makers?
Look forward to your thoughts and experience!