When Software Dies

The curiously prosaically-titled Chorus: The Modern Media Stack is full of poignant observations and thoughts about the creation of software products. (See Vox Media drops its own CMS for context.)

…something I found challenging about being a professional software developer was feeling okay—even good—about code I’ve written being removed from a codebase, features being turned off after I had agonized over the lines of code required…your measure of success is based on you using your brain and fingers to accomplish something, and then have that manifestation continue accomplishing good things forever.

The next paragraph is a vignette of a “funeral” held at a “small ecommerce startup in 2011” that is so evocative that I don’t want to excerpt just pieces of it, but I will anyway, and hope the original survives when I stumble back across this post in 10 years.

The funeral was for all the features and experiments that had been discontinued in the past year—the greatest of all a huge Facebook integration that lots of people had worked hard on, and that had brought them so much frustration, and they were proud that it ever worked, but so, so happy to be free of the consequences of all of it…I realized that these features, these lines of code, these product specs were just as well sent off into the sea if we took a look at what we had and realized we were better off without the things we had piled up around us.

They then describe how they learned “what it means to build software products.”

I had worked places where we actually published periodic updates, some of which got burned to CDs and shipped to important clients with high-level security requirements, and still thought of my job as writing code. With the help of the people I learned from, people who worked across a lot of disciplines, I came to understand why you would refer to a team made up of many different skillsets and job requirements as a “product team”.

…and then the crux:

I’m not actually grieving the individual lines of code I wrote, or even the ones that other people wrote that probably worked much better. I’m grieving the product, grieving the loss of jobs for people who found value in working on something that I also found value in, and grieving the loss of a time when the type of people who work in management…understood and valued the kind of work that I found so fulfilling, that I witnessed bring happiness to the people who used it, that gave me the opportunity to be around people who made me a better engineer, a better product thinker, and a better person.

A couple reactions [to the shutdown of Chorus] seemed to indicate a confidence in a simple idea: that leadership retiring it in favor of Wordpress means that the platform was a failure. This is the most bizarre idea to me, that only a platform that survives until the heat-death of the universe can be considered a success. The fact that many of them were saying it on social media sites and Mastodon instances, neither of which have exactly been a paragon of durability on the Internet, was not lost on me.

It’s an unfortunate truth that the team didn’t always have the shared vision, the focus, the teamwork and the energy to solve every problem they wanted to…But one thing I’m fairly sure of is that none of the people who have already been laid off, or will be laid off next month, or whenever the Wordpress migration is “complete”, are to blame for Chorus not succeeding in a way that may have made it look more appealing to the kinds of people who decided that it’s time to end it.

The interesting things about building software products together with other people are complex, nuanced. I’ve been revisiting my own 2011 post, Life Is Too Short to Make Shitty Software, lately:

The problem is most of The People Using Our Software are within an even larger set of boundaries: rules, expectations, norms, mores, groupthink, culture, ignorance…part of the reason we make shitty software is because we live in a frequently shitty world.

Previous: Photos from Sarajevo
Next: Reading

Archives | RSS