Maintenance has been a popular topic over the last few years, some of which has focused on software maintenance (Eghbal, 2020). I think part of the appeal of maintenance as a term is its relation to practices of repair and ethics of care more broadly (Graham & Thrift, 2007 ; Jackson, 2014).

But this depth and conceptual richness can present some problems when discussing maintenance in the context of software project management, where maintenance is often boiled down to time spent paying down technical debt, which takes time away from creating new features or applications.

Take for example this definition of technical debt from Eghbal’s study of open source software communities:

Code is “cleanest” when it’s first released, because that’s the time at which developers are thinking about the project holistically and writing it from scratch. As more code is added incrementally, software starts to become unwieldy, like a building from the 1850s that’s had new rooms, plumbing, and electric wiring added piecemeal over the years.

While it certainly is the case that technical debt accrues over time for the reasons that Eghbal goes on to describe, this definition implies that maintenance, and the paying down of technical debt, is something that comes after the software is conceived or released, and not there from the beginning and part of an ongoing practice.

I recently ran across this short article from David Pereira about why technical debt is a necessary part of healthy software development. I like how he argues (like Martin Fowler before him) that there are good and bad (or prudent and reckless) types of technical debt.

For Pereira technical debt is a necessary part of learning how to solve a problem, and building something of value. His insight is that this technical debt needs to be identified, documented and paid off as the software gains traction or moves into production, and that project management needs to account for this. However I don’t think it’s always obvious when this transition happens–and once software is actively being used it continues to require attention as bugs are identified or limitations are discovered.

Even if your work practice involves dedicated maintenance time to pay down technical debt, I think project stakeholders and other managers can perceive it as putting on the brakes, or time not making progress on things that matter, unless (and here is Pereira’s other main point) the maintenance work has a story.

If project stakeholders only hear that there is going to be work-cycle of maintenance to pay down debt, without hearing why it matters to the organizational goals and values, then they won’t respond well, and there will be lack of understanding between both the developers (who see management as not understanding software development), and project managers/stakeholders (who see the software developers as not having an understanding of the larger picture).

A good story for why particular maintenance work matters, is helpful for building an understanding of software development within the organization, and how it aligns with organizational goals. The story helps managers understand the stakes of the work, and to communicate it effectively to others. The story is also helpful for software developers to motivate the work, and to prioritize it against other types of maintenance that may be needed. Having a bucket of time set aside for maintenance, be it a day or a month, can be helpful, but it won’t be as effective as it could be if had a compelling and concrete story for why it matters.

References