The Paths and Pitfalls of Software Maintenance

So, you’ve bought a house. (In this market? Congrats.) Keys in hand, you have a few options for managing that new bit of responsibility:

1. Do the bare minimum to keep it standing. Broken windows are solved with plywood and roof leaks call for those bright blue tarps.
2. Maintain the current finishes, but stop there. Windows are fixed with actual windows, but the mint-colored bathroom tiles from the 70s are totally staying.
3. Knock out some home improvement projects. The popcorn ceilings can go, there’s a wall that doesn’t need to be there, and the landscaping could use some love.
4. Go nuts. Start building the east wing, a second story, and a detached workshop.

Like any good house and software analogy — which we lean on often (1, 2, 3) — software follows suit. Maintaining a web application has a similar range of options, spanning from just keep the thing running to let’s add a bunch of features. More and more, the product leaders we chat with flip to the back of the book: What happens after launch? What does maintenance look like? 

It’s an ending worth spoiling. Let’s take a tour of the possibilities, which types of apps they map to, their respective impacts, and cover the rough patches of long-term platform upkeep.

Approaching Software Maintenance

Maintenance is a muddy concept. If you ask a group of people for a definition, it’d be a surprise to hear the same thing twice. Context is key: Application size, complexity, team size, budgets, and roadmaps all affect our idea of what maintenance is and what it should do.

So, to start, we’ll cover the spectrum of potential definitions.

Keep the Application Running

First up is the absolute minimum effort (besides abandonment, of course). Your application works, and you’d like to squeeze as much value out as possible. It’s the software equivalent to that old car that hasn’t quit on you yet — even if the heat doesn’t work and there’s a hefty amount of duct tape holding everything together. Whether or not this is really “maintenance” is up for debate.

Apps That Often Go This Route

• Strictly internal tools
• Applications with a replacement in active development
• Products inherited through a purchase or acquisition
• Services that are dropping from a company’s roadmap

What’s Usually Involved

• Keeping an eye on uptime and notices from hosting providers
• Adding quick fixes if browsers meaningfully change and break functionality
• Turning off non-essential features that stop working
• Attempting dependency updates when all else fails

Cost Considerations

Minimum effort, minimum cost. Here, you’ll only be on the hook for hosting most of the time. When something does go wrong, the fix it quick or abandon it direction should keep billable time measurable in hours rather than days or weeks.

The Good

• Short of shutting things down, this is as cheap as it gets.
• A modern web application can last years with minimal intervention.

The Bad

• Updates include security updates, and there’s a high likelihood that your application will develop holes over time.
• Some updates could be quite easy and valuable in the long run, but a lack of dedicated investigative time means that you’ll miss out.
• The day where it’s finally dead may come without warning.

Keep the Application Updated

If the first list of cons sounded a bit scary, you’re not alone. Software’s an investment, and product owners tend to roll up their sleeves for some upkeep and house cleaning. This tier aims to keep everything looking the same — take out the trash, touch up the paint — without any significant changes.

In our experience, this section is usually what a developer considers “maintenance.”

Apps That Often Go This Route

• Internal tools critical for the day-to-day
• Recently completed products looking for funding
• Applications with a replacement on the roadmap (but not actively being developed)
• Feature-complete platforms with no future needs

What’s Usually Involved

• Regular dependency updates
• Occasional server migrations
• Investigations and fixes when features stop working
• Some manual updates to non-automated parts of the app — content updates and the like
• A process for tracking bug reports

Cost Considerations

Like the first section, this approach can be inexpensive for long stretches. Most updates will be quick and most bugs will be small, but there’s always a looming danger of an upgrade that breaks stuff. Over the course of a year, this tier adds up to days or weeks of effort.

The Good

• Many updates can be automated these days.
• Your team will be around the platform enough to have some foresight into issues on the horizon.
• If there are new features on the horizon, this’ll leave the application in a better place for active development to resume.
• Time will be built in to investigate issues and determine the value of fixes and changes.

The Bad

• Dependencies can be finicky and require effort to update — or, in extreme cases, need to be switched out completely.
• Developers need familiarity with the application to do the work, but won’t be in the codebase often enough to keep it top of mind.
• New features or significant changes to the way things work may be identified, but making those changes will still be out of scope and cost more.

Keep Tweaking Your Application’s Features

If the last section was a developer’s idea of “maintenance,” this one is closer to what the average product owner has in mind.

Here, we’re keeping things neat and tidy, but wholesale changes are on the table too. Maybe a page is missing a visualization, maybe the team has realized it’s taking a few too many clicks to sign up — altering what’s under the hood has slid into the scope.

Apps That Often Go This Route

• Products making their first contact with customers
• MVPs that punted a fair number of features into the future
• Applications with funding that are still scaling up their long-term team

What’s Usually Involved

• A process for tracking tasks and priorities
• All of the maintenance and updates of the previous section
• Leadership that’s roadmapping into the future
• Re-architecting portions of the platform as it outgrows its foundations

Cost Considerations

As the scope expands, cost follows. Over the course of a year, you’re looking at something between months of effort all the way up to needing a few full-timers. Active development is much pricier than update-driven maintenance, and this is the tier where you start flirting with the former.

The Good

• There’s room to iterate on the offering as it hits the market.
• Goals around automation, scale, and performance are on the table.
• It’s possible to incorporate customer and team feedback into features.
• Nice-to-haves can be prioritized.

The Bad

• Compared to the previous two approaches, this is where cost tends to balloon.
• Relative to the pre-launch work, the efforts here aren’t always as obviously valuable.
• On a long enough time horizon, it’s easy to lose sight of the bigger picture in favor of many small tweaks.
• Leadership needs to be involved to plan out the longer-term roadmap.

Keep Adding Features to Your Application

Sure, an application made it out the door, but what it could be is so much more impressive than what it is. Everything’s on the table: Rewrites, adding and removing features, and even wholesale pivots. Like the first section (just keep it running), categorizing this as “maintenance” is debatable — but founders everywhere really like this tier.

Apps That Often Go This Route

• Products looking to quickly meet a market need (teams, enterprise)
• Organizations with a sizable team and funding earmarked for rapid growth
• Applications with a backlog full of valuable, low-hanging fruit

What’s Usually Involved

• Most of the same pomp and circumstance that went into version one
• Extra care to not break the production build
• Some extra time set aside to manage updates and upgrades

Cost Considerations

Sky’s the limit. The floor here is usually a few full-time folks, but there’s virtually no ceiling.

The Good

• Everything’s on the table.
• Dedicated team members add velocity and avoid issues around starting and stopping.
• Product knowledge can be spread across a number of team members (and management), mitigating issues if people leave or are otherwise reassigned.

The Bad

• Even more than any of the other approaches to maintenance, the costs and team sizes here punctuate a need for active product leadership.
• To that end, the rise of middle management is a pretty common side effect of this tier.

Where Software Maintenance Stumbles

Beyond the branding problem we’ve been covering, maintenance also comes with its own set of unique challenges. Here’s a handful of topics worth keeping an eye on.

Developer Task Switching

If you watch a new season of a television show end-to-end, it’s pretty easy to track what’s happening. If you stop after each episode and wait a month (and watch other shows in the meantime), the details fall away.

Maintenance follows the same pattern. If a developer has long periods of downtime between tasks, extra time is needed for reacclimation.

Onboarding New Contributors

Similarly, anyone new to the project needs time to understand the codebase, get a handle on what can be found where, and sort out the impact their changes may have — even for small things. Applications with a really tight upkeep budget have trouble clearing this hurdle when it’s time to onboard a fresh team member.

Shortcut opportunity: The whole process is much easier if an already-familiar developer is available to act as a guide.

Long-Term Developer Burnout

Developers are people too (there’s a key article insight), and each is motivated by a different set of tasks and challenges. Some maintenance can be sufficiently interesting over the long term; some may be more of a chore. Keeping engagement high for different types of team members on different types of projects generally requires a rotation, which runs up against the onboarding concerns we just covered.

Scheduling and SLAs

Service-level agreements set expectations for communication and scheduling when an issue pops up. Everyone’s a fan of immediate action, but that’s a heavy lift if maintenance is only happening intermittently — folks that aren’t retained full time will have other responsibilities, too. A quick turnaround requirement can balloon an otherwise frugal approach to upkeep.

Quick Application Tweaks and Short-Term Vision

From the leadership seat, keep a close eye on the roadmap. It’s easy to get caught up in the week-to-week tweaks, bug fixes, and small improvements. A few months in, you’ll wake up and realize all of the really valuable, longer-term stuff could’ve been done by now if it’d been prioritized.

Unique Software Project, Unique Maintenance

Custom applications beget custom maintenance needs. We’ve covered emergent patterns in this article, but updates and upgrades look a little different for every project. Just like the customer experience, the developer experience is something that’ll need iteration, reflection, and growth.

Looking Ahead to Post-Launch Life

Launching a project feels like reaching the summit, but it’s usually more of a checkpoint. The start of an application should include some planning for the end: What do you consider maintenance? What are you hoping to accomplish after the first release? What will that take?

Upkeep means something different to everyone and every platform. Make sure it’s a discussion early on in your new project process.