Software Changes Take Too Long. Why?

The words we use to describe software updates sound fast: tweak, alter, adjust, iterate, change, and so on. In practice, it feels like those application “tweaks” take an awfully long time. Much longer than they used to, especially as the project matures and your team gets larger. What’s up?

Technical debt is the usual scapegoat for anything time-related in development. Let’s change it up and tread some ground less-traveled in the form of process — the organizational debt you pick up with an application out in the world, and with a growing staff. There’s some (unavoidable) overlap with technical debt, but we’ll move forward assuming that the code is as friendly to update as possible.

For our run-though, let’s set a sample change to keep revisiting:

• The top navigation bar should be blue instead of gray.

A color swap sits firmly in that sounds fast lane, but we’ll answer this article’s title with a series of new questions about our task.

Translating the Need to an Engineering Ticket

There’s a scene in the cult classic Office Space that’s a bit too real to be funny (a Mike Judge staple). Before a change can be tackled, we have to employ some people skills and translate the need into a finalized request.

Is the Request Prescriptive?

Gray to blue is relatively direct, but what’s the context? A change that’s overly prescriptive (instead of a problem statement) opens up more questions:

• What’s wrong with gray? Is it too drab, not noticeable enough, or have the designers changed their opinion?
• Why blue? Are we using it elsewhere in the app?
• What else was considered or tried in the past?

The why of it all is important for making an educated recommendation. If we started with “the top navigation bar doesn’t stand out enough,” the team could talk through past iterations, ideas, and how change may impact surrounding elements. Maybe the navigation used to be blue, and a quick reversion will do the trick. Maybe that blue doesn’t work well with other components, and an update as simple as “make it blue” comes with a full design overhaul.

Those wide swings make context key for developers now (time and budget) and later (recalling decision paths).

Are the Requirements Set?

Assuming blue is the way to go, there are still specifics to hash out. Which blue? Will anything else need a new color too? Are there key goals or results in mind once the blue version is out in the world?

Distilled: Can detailed instructions be written yet? If not, whose plate is that on?

Which Roles Do We Need?

We’re big fans of developers, but they can’t do everything. What other specializations are needed to cover the requirements? Our sample change skips roles like copywriting and legal review, but it does call for design input to look at consistency and accessibility. To make progress, the design crew should be available, informed, and part of the schedule.

Picking a Developer to Assign

The approach is set, instructions are ready, and we have a handle on additional contributors. Who’s on the bench to take this on?

Who’s Done This Before?

This question is two-pronged, covering:

• Who’s worked in this codebase already?
• Who’s done something similar to the stated requirements before?

Checking both off (or even one) isn’t strictly necessary, but it’ll have a direct impact on how long our prompt will take. How much experience with this specific issue in this specific application are we looking for?

Should We Onboard Someone?

Slow down now to speed up later: Sometimes, taking a moment to bring new developers into the fold is the right call. Cross-training adds redundancy, flexibility, and it’s a great way to add an outside pair of eyes to a project. Is it worth delaying this issue to onboard another set of hands?

Is This a Good First Ticket?

For someone who hasn’t worked with this codebase before, is this issue a good starting point? Here, yep. Trickier tickets are also possible, but usually come with pairing, heavy review, and high-touch oversight to cross the finish line.

So, another assignee-picking wrinkle: It’s worth keeping an eye out for tasks that double as good learning opportunities for newcomers.

Sorting the Development Schedule

Task, check. Responsible party, check. Now it’s time to pull the calendars out.

What Moves?

If this navigation color swap was dreamt up recently, there’s a solid chance that our assignee has other things on their plate. Where does this fall on the priority list, and what needs to move (to a different date, or a different person) in the shuffle?

Visualizing someone’s priority list — one item per line! — sits right at the intersection of difficult and valuable. Ranking informs what’s realistic and sets expectations.

Will Stakeholder Schedules Match Up?

If a developer knocks out a task but there’s no one around to approve it, is it done? (No.)

Part of scheduling includes making sure stakeholders are available to give the final thumbs up, so we have a few more calendars to sync up.

Spinning a Developer Up

Still pre-code, there’s one more section to go before meaningful progress kicks off.

What’s Involved in Project Setup?

What does it take for a developer to set up a working environment, local or otherwise? This is the closest we’ll fly to the technical debt sun, dealing with concerns like:

• How up-to-date is the project readme and development instructions?
• How long has it been since the application was last updated?
• Is there a consistent coding style to adhere to?
• What does it take to reliably recreate the issue?

And so on. Have a dusty application written on Intel-based Macs? M-series chips may not play nice with the old version numbers of libraries and frameworks in there. Can the schedule accommodate a round of dependency updates? These issues and more await a developer setting up for the first time.

Can We Protect the Assignee’s Time?

This is less about the umbrella concept of priorities and more about the day-to-day: Can we give a developer enough focused time to efficiently check this task off?

Getting a project into working memory — especially if it’s new to that developer, or if it’s been a while — takes effort. So does finding where to do the actual work. Interruptions knock efficiency down a few pegs, and there’s value in protecting time to really concentrate. We’ll stop short of making this an article about flow state.

Who’s Familiar With the Codebase?

As we’ve covered, the assignee doesn’t have to be familiar with the codebase. But, if they have specific questions or run into something that resembles a kitchen junk drawer, is there someone available to turn to? Some solid documentation, maybe?

The difference is like doing something new on the fly versus pulling up a YouTube how-to. (Except for taping drywall, which I’m terrible at either way.)

(Finally) Writing Some Code

The bottom of this article isn’t too far away, and we’re just now getting to the code-writing part. If nothing else, that’s a pretty good indication that the answer to “why do updates take so long?” has a lot to do with process.

“Quick” Fix, or Lasting Change?

Development is craftsmanship, and just like all of the construction analogies we could make, quality is on a sliding scale. Do you need a new energy-efficient window, or a sheet of plywood?

An oft-repeated warning: “Temporary” fixes are usually permanent.

What Are You Already Paying For?

Modern apps are a collection of integrations. Most of the big ones — payment processing, server monitoring, content management, version control, etc. — are paid services. We’re in the clear for our color swap, but other tasks may need to pull in one (or more) of these integrations.

Organizations managing more than one piece of software usually have a handful of subscriptions in places. What’s already paid for that we can evaluate?

Who’s Keeping Track of Licensing?

Open source is great, but folks can be pretty cavalier about tossing libraries and tools into the project. New dependencies:

• Add a dependency. It’s right in the name — you’ll have to manage updates, watch for deprecations, and give it attention.
• Have their own licenses. You’ll have to make sure that all of the licenses under a project and your intellectual property play nicely together.

What Else Is Impacted?

Tweaks have a bad habit of doing that butterfly wing tornado thing. Maybe the old gray navigation color was shared with other components that shouldn’t be blue, and now we’re on the hook to decouple those two variables. It’s an issue inversely correlated with how much time someone’s spent in a codebase: The danger is in not noticing.

Automated tests and structural decisions veer back into technical debt territory, so we’ll cap this one off by asking how do we find out what else this touches?

Launching the Updated Application

The code’s in, our navigation is blue, but we’re still a few steps short of calling this one done. It’s time to get our change into production.

What’s the Review Process?

Before getting that dopamine hit from closing the issue, we have to make sure it passes muster. Is there a dedicated QA team? Code review? What does it take to deploy to a staging server? (Is there a staging server?) Should the designers make sure their vision has been realized?

As mentioned earlier alongside scheduling, there’s a herding cats step here to corral the stakeholders — something that’s probably worth its own article.

How Do We Roll This Out?

Our hand is hovering over the big red launch button that every developer has, but deployment isn’t a standardized process for every piece of software.

Will the update require any downtime? What’s a good time for release? Have we tested the backups lately in case something needs a rollback? Should all of the users receive the update at the same time? Pushing code out into the world comes with a lot of options and decisions.

What Should be Documented?

We’ve finished hanging the shelves (well, changing the navigation color, but it’s analogy time) — now we’re left vacuuming up that drywall dust:

• If quick fix was chosen over lasting change, should a follow-up issue hit the backlog?
• Does anything new need to be added to the project’s documentation?
• Changelogs or versioning that needs an update?

The further removed cleanup is from completion, the less likely it’ll happen.

Software’s Relationship With “Just”

Process, process, process. It scales with an organization, and it’s not necessarily a bad word: We’d be hard-pressed to find things to skip in this article for an important application.

The end result is a lot of steps, stages, and decisions to work through. Guide rails that make even simple-sounding color swaps seem a bit overwhelming. It’s why the word just (i.e. “just make this blue”) diminishes the work required just a bit.