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

Software quality a winning team

Software quality: Winning as a team

We have exposed a nice framework in previous posts: raw data produce metrics and indicators, and a rating model evaluates quality for each project component.

Software quality rating

Software quality rating model

In our previous post, we discussed objectives, metrics and indicators, as powerful concepts to finely assess multiple aspects of software quality (SQ).Using new concepts to

Illuminating system integration

Illuminating system integration

System integration no matter the approach; modular, big bang, regressive, controlled or adhoc can often be one of the most critical phases of a project.

Hey there!

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