Probably Dance

I’m not good at prioritizing tasks, but there is one rule I follow and that I can justify very well: If something worked yesterday and is broken today, I will drop whatever I’m doing and fix that thing. No matter how small and seemingly unimportant the broken feature is.

To justify this I will quote from the paper “The Mundanity of Excellence” by Daniel F. Chambliss:

Superlative performance is really a confluence of dozens of small skills or activities, each one learned or stumbled upon, which have been carefully drilled into habit and then are fitted together in a synthesized whole. There is nothing extraordinary or super-human in any one of those actions; only the fact that they are done consistently and correctly, and all together, produce excellence. When a swimmer learns a proper flip turn in the freestyle races, she will swim the race a bit faster; then a streamlined push off from the wall, with the arms squeezed together over the head, and a little faster; then how to place the hands in the water so no air is cupped in them; then how to lift them over the water; then how to lift weights to properly build strength, and how to eat the right foods, and to wear the best suits for racing, and on and on. Each of those tasks seems small in itself, but each allows the athlete to swim a bit faster. And having learned and consistently practiced all of them together, and many more besides, the swimmer may compete in the Olympic Games. The winning of a gold medal is nothing more than the synthesis of a countless number of such little things

I claim that the same thing is true for software, and what’s important is to lock in those small wins.

I learned this lesson when working in video games. The company I worked for had trouble shipping high quality games. We didn’t ship bad games, but we just couldn’t compete with the likes of Blizzard or Nintendo. Since then I have worked at different places to learn how to ship high quality software, and mostly learned that there is no magic. You just have simple improvements like

• better processes that aren’t too surprising to anyone (e.g. more tests, more code review, ensuring that there are never any broken builds etc.)
• shorter feedback loops so that you learn quickly when there are issues
• better coding practices and higher standards for what code is acceptable to push (e.g. if it’s not easy to see that code is correct, don’t push it)
• priority for bug fixes instead of fixing things when you next feel like you have some free time

These are equivalent to the examples in the “mundanity of excellence” quote in that they lead to better programmers. But I want to focus on the last one because if the processes lead to excellent programmers, the bugfixes are required for excellent programs.

When software reaches a certain level of complexity you can no longer get improvements with big wins. It’s similar to the olympic swimmer example from the quote above: you need lots of little improvements. Things like tooltips, shortcuts, customization, responsive performance or correct handling of edge cases and niche use cases. These are the things that elevate your software from “works and mostly does the job” to “people like it and like working in it”. But these are also the things that tend to break and stay broken. If you don’t keep these things working, your software will always erode back down to a 7/10 quality level.

If you work at a good organization, all of this may sound trivial to you. But I can assure you that most places do not work like this and it’s surprising to lots of programmers that bug fixes, even for features that are of low importance, should take priority over work on new, highly important features. As a very visual demonstration of this, here is a comparison of all the details that worked in Far Cry 2 and were broken in Far Cry 5:

Far Cry 2 came out in 2008 and ran on a Playstation 3, Far Cry 5 came out ten years later on the Playstation 4, a much more powerful machine that was much easier to program. There is no good reason why so many things should be worse in Far Cry 5. The only reason is that these are details, and details tend to break and this is what it looks like when that has gone on for ten years. Far Cry 2 was a great game (yes, there is one big complaint that everyone has, but ignoring that it was a great game) and Far Cry 5 is just meh. Many developers over the years thought that details like this weren’t that important to keep working, and as a result you get a much worse game.

And it’s not just game development. Condition variables had been broken in glibc since 2016 and I have been trying to get them fixed by submitting patches since 2020 and haven’t had much luck until I finally got through in 2025. They mostly worked and only broke occasionally, so people just didn’t prioritize it.

But if you actually want to ship good software, you have to do like the “mundanity of excellence” quote says and lock in those improvements. Good software is a collection of small wins, and unfortunately small wins are the first thing to erode away if you don’t lock them in.

Automated tests obviously help for this and are a necessity past a certain level of complexity. But they can’t catch everything and when something slips through, you just have to fix it first.

Excuses

Whenever you push for better practices, you get the same excuses. There is no time, we don’t have the manpower, we’re already behind and this feature was supposed to be released two weeks ago. These are all very real reasons why people are not doing things, and if you dismiss these complaints they get very mad at you because they really have these issues. It’s just that from the outside, it’s clear to see that they’re stuck in a capability trap. The reason why you have no time is that you have bad practices. If you think you need more manpower to have more tests, you’re doing it wrong. The tests would allow you to ship the same software with fewer people, not with more people. Unfortunately this is not true in the short term, (when adopting new practices, things get worse before they get better) so switching is hard.

The article to read on this topic is “Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement“.

Quotes

To back up that you should fix things early and lock in a high quality early, I’ll quote from highly successful game developers. Here is Blizzard:

There’s this idea out there, that the reason why Blizzard polish is better is because we get six months at the end. And obviously we’re very fortunate to get more time, but the polish doesn’t happen at the end. The polish happens all along the way, from the very beginning. […] If you just leave it to the end, you’re not going to get there.

From the GDC talk “Making a Standard (and Trying to Stick to it!): Blizzard Design Philosophies” by Rob Pardo:
https://www.youtube.com/watch?v=FhC0NaB6ock at 53:30

Here are several quotes about id software:

“Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.”

“It’s incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.”

“We are our own best testing team and should never allow anyone else to experience bugs or see the game crash. Don’t waste others’ time. Test thoroughly before checking in your code. No throwing it over the fence for testers to find and put a bug in the database and then fix it later. It’s a wasteful cycle.”

“As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.”

From the GDC Europe talk “The Early Days of id Software”
https://www.youtube.com/watch?v=E2MIpi8pIvY

Summary

So why should bugfixes take priority? Let me slightly modify the quote from the beginning:

Superlative software is really a confluence of hundreds of small polishes or features, each one designed or stumbled upon, which have been carefully locked in by tests and then are fitted together in a synthesized whole. There is nothing extraordinary or super-human in any one of those features; only the fact that they are done consistently and correctly, and all together, produce excellence.