The Quest to Make Software Better™

I feel like too many software products that we all use on a daily basis don’t care enough about their user experience and the problems they were supposed to solve. For whatever reason, too many programs suffer from bugs and design mistakes that persist and even grow over many years. I believe it’s possible to change that, and I strive to do that daily.

What is good software?

Here are some important characteristics that define good software in my eyes:

• solves problems and doesn’t create too many new ones
• continually proves its own functionality (e.g. through automated tests and health checks)
• uses the right tool for the right job (e.g. not using Python for parallelized workloads)
• doesn’t build upon too many external dependencies (looking at you, npm left-pad incident)
• uses sane defaults and doesn’t need too much custom configuration (looking at you, Neovim and NixOS)
• easily reproducible on as many systems as possible as far into the future as possible
• contains readable readmes that describe installation, usage and development process, even if it’s just for ourselves in the future
• makes it easy to read, contribute to and change the source code, e.g. by adding a permissive license

There are many great examples for software that already adhere to most of these criteria, especially in the FOSS community. Sadly, much of the software we depend on for daily use, and especially for critical infrastructure, doesn’t. Examples for important software that doesn’t adhere to these principles:

• Windows, Microsoft Teams, basically anything from Microsoft
• macOS
• Android, Google Chrome, basically anything from Google
• Cloud hoster CDKs and SDKs (Azure, AWS, Google Cloud)
• Spotify
• etc.

I could get into great detail about the reasons for why each and every one of those made it into the list, but I feel like they are glaringly obvious and everyone of us has had more than enough problems with those kinds of software. Feel free to challenge me to write detailed essays on specific problems of specific products if you care about it that much /s.

I could also go into great detail about positive examples, and I might actually do that some time soon, but that would be another blog post and I might even link to it here. For now, let’s continue.

What using and developing good software can look like

Some more concrete scenarios that describe working with and using good software might be:

• Coming back to a code base after 2-3 years and immediately being able to understand the code, change it, build, and deploy the changed solution.
• Noticing a bug when using a program, being able to post about it in a well-defined place, being replied to in a timely and respectful manner, and having the bug fixed in a matter of days.
• Noticing a server being offline before a user files a report by performing regular health checks and receiving notifications about down times. Being able to debug this from anywhere at any time on almost any device, and deploy a fix in a matter of a few hours.
• Ten completely different tools that are independent from each other perfectly fitting together and working in unison, not getting in each other’s ways. Enabling me to write a blog post via SSH+tmux and nvim, render it via astro, and easily deploy it with Nginx on my NixOS server. Getting a bit meta here, though, haha.

What good software feels like

I can easily go on about what using and developing good software looks like. But I also want to emphasize what it feels like. It’s a feeling of ultimate joy, of getting in touch with the positive side of human history, of thousands of people working together to make something work properly. It’s a gift that keeps on giving, because yes, while it might require lengthy setup, careful design and configuration at first, it will just work from then on and not get in your way again.

I think every developer and software user who doesn’t have as strong of a fondness for good software as I do, may never have experienced this wonderful feeling of working with it. I hope you, dear reader, know what it feels like and if not, let’s keep working for a world that makes this possible for everyone to experience.

The extra mile

You can even go the extra mile and try to evolve what should define good software even beyond what most FOSS projects tend to do. One idea that I regularly rediscover is the need to transparently define all supported use cases and create documentation based on that.

For example, if the docs for the program rclone wouldn’t just explain how to use the bisync command, but rather talk about how to use it exactly like Dropbox. That would make them realise that they still have to implement missing functionality to even compete with the Dropbox use case. Sure, the rclone maintainers don’t have a unified opinion on whether they should compete with that at all, but that is certainly a use case which thousands of people coming to rclone have. And it would help a great deal for rclone to make transparent that they are aware of this use case and not supporting it (yet).

Conclusion

So, if you feel like you can get behind most of the ideas laid out here and The Quest to Make Software Better™, I’m always happy to see people joining in on the cause. Feel free to hit me up about a project you’d like some support on, or any thoughts on how to make good software. I’ll be happy to hear from you.

For now, farewell traveler and DON’T PANIC.