The Harrowing Story of Every Software Rewrite
The head of engineering has called a meeting.
“Listen,” he says, “we’ve got too much tech debt. The codebase is full of unsupported dependencies. We have no test coverage.” He pauses — overly dramatically, you think. “We need to do a rewrite.”
You have a backlog of feature requests and bugs as long as an arm. Two lists, each is as long as an arm, in fact. Every day, more requests come in. Your hands are full of arm-long lists. The engineering team asked for user stories, so you wrote user stories — even ones like: “As a user, given I am on the profile screen, I want to be able to change my email without the application crashing.” They’ve asked for the list to be prioritized and you’ve done that, too, mercilessly pushing back features you really, really need. You’ve deprioritized minor bugs that you hope most people won’t see. Every morning you have an email from someone who tried to import an XML file and got “that crash.”
“What do you mean by rewrite?” you ask.
The head of engineering shrugs. “We’re on Doohickey version 1.6,” he says, “but Doohickey 4.3 was released last week, so we should be on at least 4.x.”
“Okay,” you say, “will this affect the features we’ve already got on the list?”
“Well, yes, we can’t do everything,” he says with the exhausted tone of one fed up with dealing with people that don’t get it. You do get it, so you cut to the chase: “How long will this rewrite take?”
“Difficult to say,” he shrugs, “the logic is already in the application, so we won’t have to work that out. But really we need to rewrite it from the ground up because we’re using Sprocket for build and release.” He gives a scoffing laugh. “Can you believe we’re not using Gizmoid?”
“Do you need more people?” you ask. You’re already over budget and behind schedule, so now is as good a time as any to ask for more money. You’re in the CEO’s good book, so you might be able to wrangle it.
An expression flashes across the head of engineering’s face as if you are an idiot for even suggesting that more people might result in more work. He mutters darkly about the “mythical man-month”: adding more people to late projects makes them go even slower. You wonder, in that case, whether to suggest taking people away, but you’re not sure you can land that joke without escalating things.
You aren’t in the business of letting off steam by making passive-aggressive comments. Everyone else does that.
You’re a product manager: the balance between engineering, users, design, and the business. You don’t escalate things — you smooth them out so work gets done. You aren’t in the business of letting off steam by making passive-aggressive comments. Everyone else does that.
You agree in the end that you’ll reprioritize the list of features and bugs (again) and the head of engineering will start work on the rewrite. You also manage to persuade him to make three of the most urgent fixes in the current product, or, as he’s now taken to calling it, “the legacy codebase.”
A week later, you meet again. “How’s the rewrite going?” you ask.
“Yeah, really well,” he says, “we’ve got the test framework up and we’re doing TDD. Our automated release process is working, so we can release multiple times a day now.” You wonder what they’re testing and releasing. Of the three changes you asked for, they’ve managed to do one of them.
A month goes by. You meet again. “How’s it going?” you ask.
“Yeah brilliant,” he says again, “the team is really enjoying it. They’re motivated by a greenfield project. We’ve decided not to use Doohickey at all now. They had some maintainers leave to work on Spasm, so we’re thinking that would be better. We’ll have to rewrite what we’ve done, but overall it’s a better fit and we can separate out the business logic.”
Every time they wrote some code they shot each other with a nerf gun. He’s annoyed there isn’t a table tennis table in the office.
Business logic is, basically, anything you’re interested in. The actual value of the application, relegated to “business logic,” which can be “separated out” somewhere. The head of engineering has a developer with him, a junior who spent eight weeks on an intensive coding course at Codiversity. There, every time they wrote some code they shot each other with a Nerf gun. He’s annoyed there isn’t a ping-pong table in the office.
The junior developer explains several of the advantages of Spasm. It is MVVM, whereas Doohickey is MVC which is, like, really old-fashioned. You wait your turn and politely ask about a couple of features you urgently need.
“Oh yeah,” the junior developer says, “they’ll be fine. We can add them into the backlog.” You are relieved. Finally, some good news. The weeks of waiting have paid off.
“Oh, no,” the head of engineering says, stepping in, “they’re talking about the old shitty si…” he catches your eye, “I mean, the legacy site, not the new build.”
“Oh man,” the junior developer says, “that’s a right pain.”
“Yeah,” the head of engineering agrees, “it’ll hit timelines a lot. Context switching like that has a really high cognitive overhead, you know.”
The application you’ve rolled out to thousands of customers, which has been running for years, gradually enhanced and improved, with only minor tweaks needed here and there, the money from which pays all your salaries? That site is now “the old shitty site.”
You look at the screen. There is no danger of you thinking it is finished.
The next time you meet, the head of engineering has a demo. “We haven’t finished all the, you know, UI stuff,” he says, waving his hand, “UX hasn’t got back to us with the designs and we wanted to keep it lo-fi so you’d know it wasn’t finished.”
You look at the screen. There is no danger of you thinking it is finished.
“We’re still doing user testing on some low fidelity prototypes,” the creative director, who has joined the meeting, says. “We’ve done a card sort and have a pretty good idea of how the information architecture should work.” She sips her cup of coffee, actually pausing to take in the aroma.
Apparently, research from UX has shown that the site thousands of people use every day is hopelessly difficult to navigate. The slick presentation she shows gives the impression users are stumbling around randomly clicking on buttons in a fruitless endeavor to get the site working. If anyone ever manages to complete a task, it is seemingly more by luck than judgment.
Certainly, some parts of the current site are rough around the edges, the padding is off on a couple of forms and overall it looks a bit 2012, but you expected most of the design could be copied into the new site. You’re not exactly ecstatic about the way it looks, but getting new features released and bugs fixed is what’s keeping you up at night. You suggest holding off on a full design review and using what you have for now.
The creative director disagrees. “Now is a great opportunity,” then, abruptly changing the subject: “Can we talk about analytics?”
The analytics framework, which generates monthly reports of usage for management, is not fit for purpose. “It doesn’t allow any sort of A/B testing,” the creative director says, “or track user journeys across multiple sessions.”
Each quarter you go into the analytics console, copy out the large number on the top, and put it into a PowerPoint. When you first rolled out analytics, everyone was excited to click around the pie charts and line graphs. But after a few months, they gradually stopped logging in. The stats are largely the same each month.
“I suggest we use Analogix,” the creative director says. The head of engineering does a quick search on his computer and finds there is a plugin for Spasm so he’s all for it.
“And can we add it into the current site, so we’re comparing apples with apples?” the creative director asks.
The head of engineering takes a sharp intake of breath, a plumber looking at a leaking boiler. “That’s going to add a load of time,” he says.
“Because of the context switching?” you suggest.
“Yeah,” he says, “it adds a cognitive load.”
“What about GDPR?” some wag in the room asks. They all agree they’ll need to run it past the lawyers and data protection.
In the end, you manage to persuade them that you don’t need the new analytics engine added to the “legacy codebase” and you will find a way to compare apples with oranges. You also manage to get them to agree to fix two urgent bugs in the next sprint. The creative director suggests doing some user research on the bugs, but you head that off at the pass and get them to focus on the designs for the new site.
Another month passes and this time when you meet, the creative director demos the new designs. They have designed an icon set and have huge buttons to do two tasks.
“How do you do other tasks?” you ask, “Like importing XML.” Fixing the XML import bug was one of the things you managed to get done in the last sprint.
“Oh, this is just the most common user journeys,” the creative director says, “we haven’t gone deep into all of the other journeys yet.”
Four months have passed and all you have to show for it is a website where everything is black Times New Roman on a white background and a beautifully rendered picture illustrating two of 378 features.
At the next meeting, the head of engineering tells you that he’s leaving for a job at Dunkr. “It’s a startup. Like Uber for clothes,” he says. Apparently, they use Spectral Spasm. It’s a new version of Spasm that blows the current one out of the water. He’s excited about the role. “I get stock options,” he tells you.
The new head of engineering will be starting in a couple of weeks. You can already picture it. The replacement will explain you need to switch to Spectral Spasm as what you’re using is hopelessly outdated and all the developers are fed up working on it.
Two weeks later, you meet the new head of engineering in a coffee shop. “I have some thoughts,” she says. You prepare yourself. Another reprioritization exercise, the same content rewritten into a different format or style. You’ve forgotten now if they’ve just switched to or from Jira.
“I’ve been looking at this rewrite the team started,” she says, and you feel your heart sink. “I hate to start on the wrong foot, but I was wondering how you’d feel about us revisiting the existing site and seeing if we could enhance the features in that, rather than throwing it all away.”
You pause. She wants to go back to the current site and look at making small incremental improvements to what people are currently using rather than spend an indeterminable amount of time on a project that looks like it’ll never finish. She wants to actually work with you to get things for the users right now.
“While the current site may be a bit old,” she says, “it’s been running for years, as far as I can tell. It’s had the edges knocked off it. We could work to improve it piece by piece without having to do a big rollout every time and worry we’re going to accidentally miss something.”
Play it cool, you say to yourself. You tell her you’ll be able to make that work, as long as she’ll prioritize the list of outstanding bugs you’ve got. She agrees to your terms. You are a product manager and deal maker. The CEO of the product. A politician, too. You tell her about the current list of bugs and features you have. “Just send them over in whatever format you’ve already got them in,” she says, “I don’t want to put you to any extra work.”
You’re touched by this small gesture, of someone looking to help you out rather than put a barrier in front of you.
You check your diary. Your next meeting is with the creative director and you prepare to tell her there is a change of plan.