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 on linkedin
Share on twitter
Share on whatsapp

Leave a Comment

Related Posts

How to make your developers happy

How to make your developers happy

There’s no shortage of articles on how to improve software quality via process improvement. Today I want to look at things from the other side, from the software developer’s point

Improving code quality

Software quality: To the rescue!

In this post we’ll show what a healthy relationship with code quality looks like. After our introductory post, software quality (‘SQ’ for friends) might seem intimidating, maybe even daunting. But

How SpaceX develops software

How SpaceX develops software

SpaceX, a pioneer in commercial space transportation, most recently successfully took Astronauts to the space station with their Crew Dragon launch vehicle. SpaceX have essentially gone from a blank sheet of paper and text books to


Software quality: Origin story

Software quality is a vast field, which has been the subject of many studies, standards and tools for a long time (if we think in “Software time”). To make it

Hey there!

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