Dirk-Jan Swagerman is chief on demand at Triceps. You can contact him at swagerman@triceps.nl to engage in a conversation on your software legacy challenges.

25 January 2021

Many CEOs, CFOs and business owners will have experienced the impact of not delivering planned innovations on time. Oftentimes, the software team is (perceived to be) the main bottleneck. While investments in skills and processes can help, a significant contributor is frequently overlooked: the software inventory.

Inventory control is a well-established and understood practice in businesses to help track, label and reduce physical stock costs. CEOs, CFOs and business owners are aware of the advantages and disadvantages and are keen to optimize stock levels. Inventory is also one of the eight wastes in the Lean methodology. Companies embracing Lean have trained employees to spot waste and find ways to improve processes to reduce it continuously.

While the inventory of physical goods is well recognized, it’s much more difficult for companies to identify their ‘software inventory’ as a possible root cause behind the lack of innovation speed. And while many companies recognize their software as an asset, it’s also a liability: owning too much software slows a business down.

Software obsolescence

So, what’s software inventory? Instead of occupying physical space in a warehouse, imagine software inventory to occupy ‘conceptual’ space. Every product, product option, hardware option and supported operating system sold and maintained increase the size of the required development, test and release effort. Software inventory, therefore, is a function of the number of products/product lines in active maintenance, the number of lines of code (and software configuration branches) in maintenance, the number of product options and configuration complexity, the number of customer-specific features, the number of different technologies used, the number of hardware platforms supported and the number of OS platforms supported.

Hopefully, a significant part of the software inventory is in good shape and yielding profitable business results. Other software inventory may be ‘past its shell life.’ Another useful analogy we can borrow from the hardware world is ‘obsolescence.’ Hardware obsolescence occurs when you can no longer purchase a specific processor or PCB board. Consumers notice the impact of obsolescence when they upgrade a software package on their computer and it stops working. Software is obsolete when it’s no longer possible to get (security) bug fixes for it from an approved supplier.


Device lifecycle management for fleets of IoT devices

Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .

Operating systems, libraries, platform components and compilers are all subject to software obsolescence. Obsolescence seldomly comes alone. Hardware obsolescence drives OS obsolescence. If an OS goes obsolete, it almost always triggers library, compiler or platform component obsolescence. Understanding and managing software obsolescence is an essential element in controlling the software inventory.

Not all debt is “technical”

The term “technical debt,” coined by Ward Cunningham, has created both clarity and confusion in the engineering community. On the one hand, it has provided clarity as “debt” clearly points to the ‘liability’ of software. On the other hand, by coining it “technical debt,” addressing it predominantly became a technical engineering discussion. But not all “debt” is technical. The term also suggests that the costs are avoidable. And while it’s possible with good architecture choices to limit software obsolescence costs, they’ll never become zero.

Many software teams are stuck trying to ‘pitch’ the need to solve technical debt and struggle explaining their problems to their management. Well-intentioned, using the analogy of technical debt, they suggest to non-technical listeners that the team made the wrong choices, avoidable and without discussing them first. Increasingly, leaders get agitated by the discussion, some already burned themselves investing in expensive rewrites that never brought the promised return on investments.

It’s time to level up the dialog: controlling software inventory is a business opportunity, not an internal engineering discussion. While part of the software inventory issues is purely technical and can be resolved within the technical community, another essential contribution is a direct consequence of (past) business decisions. It could be the unforeseen maintenance cost of a ‘one-off’ special to a customer, the failed integration of an acquired software company or the costs of ramping up and down software teams. The software hasn’t become the asset your business needed, but a perpetual liability.

Often, management teams don’t know the decomposition of their software inventory in terms of size, complexity, technologies, quality and maintainability. But as your legacy will slow you down – it might even be the single factor holding you back – it’s time to address it. Business leaders should start to assess, label, track and reduce their software inventory to accelerate innovation.

Significant potential for gain

While there’s plenty to do at the software team level, there are ways business leaders can help their team address complexity. The following I’ve applied in practice: retire unprofitable products or hardly used features, limit the amount of product configuration options, define and guard the architecture through well interfaces (for instance, using Comma), keep the roadmap as stable as possible, keep teams as stable as possible, have a clear end-of-life policy. Perhaps most importantly: ask your software team how they keep the code healthy. Unlike production machines that visibly erode, software erodes invisibly. Still, it requires maintenance investments to extend its lifetime. A piece of personal advice: allow your teams to keep the production ‘engine’ running and ask what they require to do so.

The potential for gain is significant. In 2018, the company Stripe published a report estimating a $300 billion global GDP loss from developer inefficiency annually, based on a 31.6 percent efficiency loss per developer. The ability to migrate existing systems incrementally, and actively get control over the software inventory, is an important capability that will help you capture that 31.6 percent efficiency improvement. Businesses that control their software inventory in 2021 are in the best position to increase room for innovation, increase development speed by lowering the cost of change and lower the cost of non-quality by decreasing the number of defects.

Illustration credit: Sanne Bakermans/Brenna-Ivy Art

Edited by Nieke Roos