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

Maintaining software - what is your team working on? - Coderskitchen

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

Isolate verify merge_Coderskitchen
Niroshan Rajadurai

Isolate, Verify and Merge

The cost of fixing software is well understood. Much research has been done to demonstrate that fixing defects at the time of introducing them is

Requirements Process development
Niroshan Rajadurai

Requirements in Agile development processes

The Standish Report tells that in 1994 ninety-one per cent (91%) of software projects failed, with thirty per cent (30%) ultimately cancelled. In 2020, 26

Illuminating system integration
Niroshan Rajadurai

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.

Nature of software development - coderskitchen
John Paliotta

The nature of software development

I’ve been writing a lot of code over the last 4-5 months, prototyping some new product ideas. Here are some thoughts that I try to

How to make your developers happy - coderskitchen
John Paliotta

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,