One challenging decision we often see with software companies is whether to invest in fixing a legacy code base or to invest in adding new features. Usually a company’s business or product management team is eager to keep adding features (because they add value), but frequently engineering teams claim to need time to “make repairs” on existing software. What to do?
One client who approached Essilen Research was a technical lead of a software group. He described his problem to us: over the past 5 years the company had been moving at breakneck speed adding new features. His complaint was that the software had accrued technical debt, but his executive leadership team was unsympathetic and kept insisting on more new work. Leadership pitched it as “necessary for the business to survive”. The business team also complained that the software team’s efficiency was slowing down and lacked the agility it seemed to have in past years. They felt the software team was losing its sense of urgency, but our client knew better. He saw the issue as an aging software architecture that was causing more and more problems. He had tried to convince his management of the need to re-architect much of the software, but his presentations came off as defensive and ineffective.
The first thing we did with this client is look at the presentations he made to his leadership team. We immediately saw a common problem. They were full of software architecture diagrams, bug counts, diagrams showing number of features and lines of code, but nothing on economic efficiency, namely time and money spent on servicing the legacy software. To a technical audience his slides made sense, but to a CEO or CFO they didn’t.
The second thing we did was to spend time with the client setting up a meaningful operational dashboard. For example, the team had a bug database, but the bugs didn’t have attributable root causes. They couldn’t say, for example, whether a bug was attributable to new development or whether it was attributable to debt. Once we fixed this, real usable data started coming in. The client also was an Agile practitioner, so we were able to collect data from their backlog to get an indication of how much time was being spent maintaining the legacy code base. All of this accrued to a financial statement of how many dollars were being spent on new features versus debt maintenance. This data, in plain dollars and cents, was the key to unlocking the next phase.
Armed with actual dollar numbers, the technical team was finally able to effectively argue its case. The decision reduced to a straightforward financial discussion. There was a series of productive meetings where the leadership team discussed an acceptable level of debt spend versus feature spend. They eventually arrived at a rough guidance that they should spend 15-20% of their R&D budget on paying down the debt. This guidance then allowed the tech team to prioritize.
Perhaps the best part of this story, however, is that the business and technical teams at this company now speak the same language. The technical staff learned to speak of their work in economic terms, and the finance and business teams understood that software is an asset that must be maintained.