“Just Fix It” — Development Doesn’t Work Like That

Lately, I’ve been vegging out on competitive cooking shows. I’m talking Snack vs Chef, Nailed It, Sugar Rush, all of that. I find them both on-the-nose and weirdly inventive. Like in Best Leftovers Ever, contestants have to take – you guessed it – leftover takeout food and make something amazing out of it. 

The other night, while watching one of these shows, a team challenge made me sit up on my couch. 

In this challenge, the first team member was assigned a dish to cook and started working on it. After a short amount of time, this chef was kicked out of the kitchen, and the next team member had to come in and pick up where they left off — without knowing the assigned dish or what all the previous chef had done.

Just imagine walking into a kitchen with half-cooked things in the pot on the stove, in the oven, in the blender, and being told to finish it to gourmet quality. 

This is exactly what working with inherited code can be like. 

I’ve had several clients lately bring their projects to WLCM and give our team a punch list of tasks they need completed. Tasks the previous developer didn’t do, didn’t get around to, or didn’t do right. 

These entrepreneurs have dumped tons of money and time into their projects already. Their back is against the wall, in one way or another. “Just fix it,” they ask.

And my heart breaks for them. They don’t even know how deep in the shit they are, or how badly they’ve been taken advantage of. 

Decoding the code

Let’s talk about documentation for a second. 

So documentation is like a user’s manual for a product’s code. It says which parts of the code do what, what functions depend on which others, and why functions were coded in a particular way. 

Documentation is half the battle when working with inherited code. 

I have never encountered a “Please fix it” project that came with good documentation. In the absence of documentation, we have to spend a lot of time — like months — to understand the code and the state of it. And even then we can only know so much. 

Like in that cooking challenge, you can taste whatever’s in the pot on the stove and get a decent sense of what it is, but you still don’t know exactly what ingredients are in there.

The other half of the battle is the state of the code itself. High-quality code is simple and straightforward. Individual functionalities and components aren’t tangled up (dependent) on others. It’s easier to understand and work with. It’s more resilient and won’t break as easily. 

Again, we hardly ever inherit a project with high-quality code. So our team has to fly blind in bringing it up to speed. 

• Because low-quality code is so tangled up and incomprehensible, remediating an issue creates three more. 

• Even if a component passes QA tests, we can’t be sure it works in all the scenarios it needs to. 

• If we fix it and it works how it’s supposed to, we can’t be sure the next addition or update won’t break it again. 

This is how projects become an endless amount of work with no actual forward progress. Usually, in the amount of time it takes to whack-a-mole all the project’s issues, we could have rebuilt it completely and correctly. 

Out of the frying pan, into the fire

When we inherit a “Just Fix It” disaster, there’s always a cheap team behind it. 

I know that’s not nice, but it’s the truth.

I see it time and time again. Founders get taken in by impossible promises like “We’ll build your app in six weeks at a quarter of the cost.” I guarantee you, behind that offer is a factory of junior coders overseas who are coding (badly) in a vacuum, producing zero documentation, and not giving a whit about you or your vision. 

So when a founder brings their project to WLCM, they want us to put lipstick on a pig, fast. 

But by then, doing it both right and fast is impossible. 

To do it right, the founder must make investments to resolve the project’s technical debt. But a complete refactor/rebuild takes time, money, and guts. Most founders don’t have it by this point. They’re at the end of their rope. 

So instead of rebuilding it right, they hire a new cheap team out of India or China who will “get it done” no questions asked. But they’re not fixing anything. They’re just stacking trash on top of trash and incurring more technical debt. 

I say all this to say: If you want to build something your business is going to run on, do it right from the beginning. And if you don’t, when it comes time to give it to someone like WLCM to fix it, you must also give them time.