Picture courtesy Icons8

If

you’ve been programming for longer than a hot minute, you know the fun of going deep into a new project. You get to start from scratch, with no dead weight or legacy code. For a short while, it’s all about design and architecture, mapping out the relationships between different components, trailblazing your way with new APIs, and figuring out how everything should talk together. Hours disappear.

And then, two paths open up. If you’re lucky, you climb the high road to a successful release, a stable product, and a steady grind of fixes and improvements. But if you’re not — if the project you were building is cancelled, retired, or rebooted in someone else’s hands — your work shudders to a stop.

Most programmers will run down this steep path to project death more than once. And despite everything we know, there’s always a question at the end. Can I salvage something? Is there any way to extract value from the countless hours of coding work?

The answer is yes — but not in the way most of us hope. Here’s what I’ve learned.

A case study

A few months ago, a programmer and startup co-founder I’ll call Ravi (all names changed) lit up Hacker News with a question. He’d built an app, a content management system, a website, and all the back-end plumbing over the course of two years of unpaid work. Now his tiny company was splitting up, with the co-founder planning to sell a similar service — but with an off-the-shelf product and none of the tech Ravi had built.

Ravi felt sure there was a place for his code. All around him were startups trying to get into the same market. None of them had the same code, and all of them were hustling to make things work. He walked away with no compensation, no equity in the new venture, but all of the intellectual property—and permission to sell it. Could he recoup some of his sunk costs? What would someone pay for his codebase?

The answer was easy: probably nothing.

Code is a liability

Here’s the first problem that confronts anyone trying to sell code from a failed project, no matter how well written that code is: Every line of code is a liability. It requires maintenance. There are bug fixes, new features, updates to make it work with new products and protocols. As its age increases, its problems only grow.

The liability of old code is unbounded.

As a business, it’s not enough to own code. You need to have developed the team, structure, and in-house expertise to manage it. And the only reliable way to do that is to have written the code in the first place. It’s a circular problem.

Preexisting code is legacy code. It’s code from another time, place, and author, that will pose (at best) integration challenges and (at worst) a black box of potentially catastrophic problems. Worst of all, the cost of potential problems is very difficult to gauge. As a data scientist might say, the liability of old code is unbounded.

In fact, even if a company needs to solve the same problem in the same industry using the same technology stack, they will almost always choose to build the solution it in house. They really don’t have any other choice.

• They need control. Other people’s code will be shaped by the assumptions of whoever wrote it. Often, this code will be tightly coupled to the business environment where it was built — its practices, workflows, and favorite technologies.
• They need certainty. If a company can’t be certain that code doesn’t include nasty surprises, they at least need to be certain that they have employees who know the code well enough to fix it.
• They need in-house experience. Even if the code is perfect. Otherwise, they can’t grow the product.

#software-development #failure #startup-lessons #programming #sofware-engineering