Confronting our technical debt

My colleagues express frustration every day with what our technical debt is costing us. Decisions made in the past—often by others—with the knowledge and constraints and tradeoffs from that moment in the past, now limit the scope and the speed of our decision-making and execution in the present, as we work to incorporate our current knowledge and confront our new constraints.

For the moment I’m talking about websites and software.

You can make a (pretty sweet-looking) website from scratch with a bit of HTML, CSS, and images. Of course your website might not do much of anything, but let’s imagine that you’re just responsible for marketing the cool app that the rest of your company builds.

Your company’s app solves a problem, you see, in a clever—even delightful—way that no one else thought of first. People like it. They use it. Your company’s going places.

Turns out, though, there’s a ceiling on your success. Because in leaping ahead to the future, free from the expectations and constraints of the past, your company’s app left out a few things that turn out to be kind of a dealbreaker for an awful lot of people. People you will eventually want as your customers.

So with each new ability your app adds, to address the needs of a new set of customers, your marketing website needs to adapt. Highlight one feature with a paragraph here. Add a new page for the next. Actually there’s no good place to highlight this third update because it changes the story of the app, at least for the potential new customers the feature seeks to attract.

So you make the best choices you can, but they all feel like compromises, some of which feel embarrassing and stupid, because of how much you’re constrained by the structure of the website you built when you first launched—your technical debt.

Until you get the go-ahead to start again from scratch.

So while the creative team does their concepting and wireframes and rounds of review meetings, you set about the work of rebuilding the website as something more modern and scaleable. You turn it into an app that serves pages dynamically, because security-wise what were you even thinking the first time. And because you know you’ll be launching in new countries, you build helpers to serve up translated text strings and assets, based on where the user is visiting from. (Plus a country switcher, because you built your auto-detection based on browser language rather than asking for permission for device location, which seems unnecessary.) (And creepy.) So when the new site design launches it’s built on a foundation you’re proud to have made ready for your company’s exciting global future.

Until someone on the new markets team identifies an issue with EU privacy law that will prevent you from launching with your full feature set. There’s a hiccup in Canada as well, but it‘s a minor one (some Quebecois regulation), and while the EU workarounds might take months (or years), a fix for Canada could probably be done in a sprint or two.

Except that your app’s engineers are tied up building new features for the US, so you’ll apparently be launching in Canada without the fix.

So now you need to serve up custom edits to the site as it will appear in EU countries, and different exceptions for Canada (or at least the French-speaking portions of Canada), when what you built was designed to serve up identical content everywhere, with translated language and assets.

And it’s messing with the site architecture, because you’re having to make custom exceptions to the navigation, or to remove the only paragraph that links to a key support article, forcing you to find another way to surface it on the site (but, again, only in the EU).

And the company who built your content management system is no help, because the tool was engineered to handle translations, not differences in content across locale.

So the months go by, and your company keeps shipping features that build upon other features that aren’t available in all countries. So you’re consigned to keep building exception upon exception, forgetting what exceptions you’ve already made, until the queue of requests to fix things that are broken or missing in one country or another becomes endless, and you dream, every day, for the go-ahead to start again from scratch.

If you are the sort of person who tends towards blaming others, the cost of the technical debt rises in resentment and self-righteousness toward the obliviousness and wrongness and slowness of others. Why won’t they give the go-ahead to rebuild? Why can’t we get additional resources?

If you are the sort of person who tends toward engaging with your own responsibility, the cost can grow to feel deeply personal. Should you have made different choices in the past? Could you have with the information you had available at the time? Would it have been possible for you to have been given better information, or a clearer set of requirements?

But even the desire to own the decision forces you to confront obstacles placed by others. Why did you start off with bad information? Who knew better? Who should have known better? Can’t they see how important this is?

When the frustration becomes intolerable, you have your own way (at least within the modern tech economy) to get out from under the debt. You can move to a different team in the company, to work on a different sort of problem, or you can find yourself a job somewhere else.

You find your own way to start again from scratch.

It is at this point that I remember Carl Sagan’s words about the challenge of making an apple pie from scratch.

And I remember that I’m not talking about websites and software.

I’m talking about America in 2016. And there’s a lot to talk about.