Maintaining software: man repairing coffee machine

Maintaining software: What’s your team working on today?

A few years ago I read: “The Phoenix Project” which is a novel about the IT group at a fictional company that’s struggling with maintaining and enhancing their software, and getting new features released into production (DevOps).  It’s a pretty entertaining read for anyone in the tech space, and I recently gave it a quick re-read.

The story centers around an IT manager who is tossed into a dysfunctional department that’s so interrupt-driven that they can’t get their planned work done.  He has a mentor who is teaching him the parallels between software manufacturing and product manufacturing.  In the end, IT saves the company by transforming their work flow for efficiency.  I think that anyone who’s worked in software development for any amount of time will relate to the characters and story line.  Here are some of my favorite quotes from the various characters in the Phoenix Project:

  • “You cannot achieve the strategic until you’ve mastered the tactical”
  • “The key to improvement is to identify bottlenecks.  Improvements made anywhere besides bottleneck are useless”
  • “You must shorten and amplify feedback loops so that quality issues can be fixed at their source”
  • “We are getting killed by unplanned work, we need to identify the cause of the unplanned work”
  • “Left unchecked, technical debt will ensure that the only work that gets done is unplanned work”

The last bullet is a killer in software development. Whatever percentage of your development team resources are being used for bug fixes and wrestling with fragile code, is time lost that could be used to develop new customer-facing features. 

To understand the technical debt on your project try this simple exercise. Track what everyone on your team is doing for a 60 or 90 day period that includes at least one release, and then aggregate the data into the following groups:

  1. Maintaining software: bug fixes, 2nd and 3rd level customer support
  2. Re-factoring: intentional rework of “old” code
  3. New development: everything else

If you track this data, you might be surprised by how much time is being spent on maintenance, how little is being spent on new development, and that maybe no time is being spent on re-factoring. We all have parts of our applications that we hate to work on because they’re fragile and under-tested. Make it a goal this year to replace at least one of these ugly parts … a year from now you’ll be glad you did.

Further reading

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. By Kevin Behr, Gene Kim, George Spafford

Share:

Share on linkedin
Share on twitter
Share on whatsapp

Leave a Comment

Related Posts

Continuous Intetgration on Coderskitchen: Building the ultimate CI machine

Building the ultimate CI machine

Software is traditionally designed, coded, then tested. However, poor quality coding and a testing phase at the end of the process can add a significant

Visual Testing Coderskitchen

Visual testing of a Unity-based 3D world

We provide a 3D animation environment for the development and testing of advanced driver assistance systems (ADAS) and autonomous vehicles. Developing and maintaining this environment

Hey there!

Subscribe and get an email every time we’ve got a new quality piece on here.