As we near the end of 2020, many CEO’s, CFO’s and business owners again will have experienced the impact of not delivering the planned innovations on time. In many companies, the software team is (perceived to be) the main bottleneck. Sometimes, leadership identifies “the team” as the problem. Maybe they don’t have the right skills or are not engaged enough. Another time, the problem is diagnosed as “the process”. A whole new industry category arose around helping businesses gain agility through SAFe. To manage costs, some companies consider offshoring. More often than not, the implemented measures do not bring the required innovation benefits and speed, nor true cost reduction. What could be the reason? While investments in skills and processes can help, perhaps a significant contributor is overlooked.

Inventory

Inventory control is a well-established and understood practice in businesses to help track, label, and reduce physical stock costs. CEOs, CFO’s 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 “Lean” It is the “I” in TIMWOODS. 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 is 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 is also a liability:

Owning too much software slows a business down.

So, what is ‘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 increases the size of the required development, test, and release effort. Software inventory, therefore, is a function of:

• # product(line)s in active maintenance

• # lines of code (& software configuration branches) in maintenance

• # product options & configuration complexity

• # customer specific features

• # different technologies used

• # hardware platforms supported

• # 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 is no longer possible to get (security) bug fixes on that version by an approved supplier. 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”

Many software people reading this article know that Ward Cunningham coined the name “technical debt,” which created both clarity and confusion in the engineering community. It provided clarity as “debt” clearly points to the ‘liability’ software. But also confusion. By coining it “technical debt,” it dominantly became a technical engineering discussion to address it. But not all “debt” is technical. The term “debt” also suggests that these costs are avoidable. And while it is possible with good architecture choices to limit software obsolescence costs, they will 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 a non-technical listener 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 is 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 are 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 has not become the asset your business needed, but a perpetual liability.

Often, management teams do not 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 be the single factor to hold you back; It’s time to address it!

Business leaders should start to assess, label, track and reduce their software inventory to accelerate innovation.!

While there is plenty to do at the software team level, there are some of the ways business leaders can help their team address complexity I have 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 need to do it!

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 31.6% 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% 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

• Lower the cost of non-quality by decreasing the # defects

Which methods have you successfully used to limit the cost of software maintenance? Please reach out to swagerman@triceps.nl to engage in a conversation on your software legacy challenges!