Abraham Marin-Perez

Always remember, the person we’re really working for is the person who’s restoring the piece a hundred years from now. He’s the one we want to impress.

That quote is from Hobie, a character in Donna Tartt’s novel The Goldfinch. Hobie is an antique furniture restorer. I am particularly thankful for this quote because it beautifully expresses what I’ve always thought about code: the best code is written thinking about the programmers that come after.

I think current software practices suffer from an illness caused by too much haste. Much like trees in a crowded jungle, the aim is to outgrow the competition. Trees competing for light often overstretch themselves, growing tall and thin and becoming susceptible to small disturbances. Strong winds or mild disease can make them collapse. I’m not saying we don’t need to look at short-term benefits—in fact, I encourage it—just not at the expense of long-term stability.

Today’s software industry is like these trees. Many “modern” teams focus only on the next week or month. Companies struggle just to live another day, another sprint, another cycle. And nobody seems to worry about this. Developers can always find another job, and so can managers. Entrepreneurs can try and cash out before the company has lost its value. So can the VC that backed the initial investment. Too often, the key to success lies in timing the exit so as to leave just before people realize that the amazing growth was just a tumor.

On the other hand, maybe that’s not so bad. Some pieces of furniture are meant to last hundreds of years, and some will likely crumble within a decade. You can spend thousands at Sotheby’s on a china cabinet—or go to IKEA and probably furnish your whole house. Maybe we just need to understand this new economy we’ve created, where everything is ephemeral and transient. Assets aren’t expected to last long, just long enough. We aren’t supposed to create things that stand the test of time, just the test of profit.

And yet I believe there is a middle point, a new role beginning to take form: the code restorer. Doing something that lasts forever at the first go is so expensive that it isn’t worth it, but focusing only on short-term profit will create code that collapses under its own weight. This is where the code restorer comes in, somebody whose job isn’t to “recreate the same thing but better” (a common wish that almost always fails), but rather to take the existing codebase and slowly reshape it to make it manageable again. Add some tests here, break down that ugly class there, remove unused functionality, and give it back improved.

We, as programmers, have to decide what kind of software we want to build. We can focus on profit for a while, build up something that holds, but at some point we have to choose between durability, carefully reshaping the code, or profit, abandoning it and starting afresh. After all, profits are essential, but some things are bigger than money.