Developers Enable Planned Obsolescence. That’s the Future, and It Needs to Stop.
Image: https://carthing.spotify.com
If you didn’t know, Spotify decided to discontinue its Car Thing. Although this is a win in terms of discontinuing products with appalling names, it’s also another chapter in the saga of planned obsolescence.
It’s one thing for hardware to fail due to age and quite another for a software update (or the lack thereof) to transform a functioning device into a glorified paperweight. As software developers, we need to ask some uncomfortable questions about our complicity in this trend — and decide where we draw the line.
The Death of Products (Not Just a Hardware Problem)
Spotify released Car Thing to do one thing well. Offer a streamlined way to access Spotify in vehicles with outdated infotainment systems. The idea that a product with no offline capability can essentially be transformed into ewaste is a stark reminder of how software support (or the withdrawal of it) can effectively kill hardware. There is no end-of-life update that is going to mean owners of Car Thing have a product left in a usable state.
This anti-consumer behavior isn’t limited to hardware either. Sega games are vanishing from platforms like Steam. Entire catalogs of digital content have disappeared, leaving gamers with no legal way to access titles. Often publishers leave Digital Rights Management (DRM) in games after servers have been pulled offline, leaving paid for games unusable.
Consumers are left with products that don’t work, or no way of accessing software they wish to use. Developers are complicit and also work in the knowledge their work can be deleted, nullified, or rendered inaccessible at the whim of a company’s profit margin.
The Unintended Outcome of Corporate Choices
Enter hackers and pirates to save the day.
Hardware is often hacked so it can retain some use into end of life. Consumer heroes break into hardware and get it to work in some form for those customers who supported the product and company rather than leave them to nurse intentionally bricked hardware.
When beloved games are pulled from stores or hardware is intentionally bricked, users have little choice but to turn to unauthorized means to preserve what they value. Pirates strip DRM from games, so they are still usable when servers go offline, and publishers are no longer interested in supporting games or taking money from willing customers.
As developers, our work is often what enables these decisions, whether through restrictive DRM, lack of offline functionality, or refusal to provide source code for abandoned projects.
Yet there is another way. Developers for a long time have been saying no by helping the hackers and pirates, even when they have been working against each other for years.
A Call to Action: Say “No” to Anti-Consumer Practices
We need to recognize that as developers, we have a moral responsibility to our users. Just because a company decides to move on doesn’t mean the software we build should cease to exist.
We are also in a privileged position to advocate for better policies within our teams and organizations. This might mean pushing for open-sourcing old projects, ensuring that hardware is designed to work independently of cloud services, or lobbying for post-support migration paths.
Sure, we can’t always stop a product from being sunset. But we can ensure our code doesn’t enable the outright destruction of functionality for paying customers.
After all, the software we write isn’t just a job — it’s a promise to the people who use it. Let’s make sure we’re keeping that promise.
Conclusion
We should remember that the software we write isn’t simply a job. As soon as we sell products they become a promise to the people who use them, and frequently our work is loved by customers.
Developers should work to create the best software they can, and work in service to customers who (ultimately) pay our salary.
Let’s make sure we’re doing all we can to encourage the world to appreciate developers and our work.