Guilt-Driven Development - Markus EliassonGuilt-Driven Development
3 August, 2026A few weeks ago, the day before Midsummer, I went on my summer holiday. I merged my last pull requests<br>and shut down my computer, looking forward to a few weeks of relaxing.
Come Midsummer morning, I checked my work emails 1 and I noticed that a failure had<br>been reported earlier that day for one of the services I maintain.
1. Maybe a bad habit, but I tend to at least skim the subject lines while on holiday,<br>to see if anything important has happened.<br>Damn it! The failure was regarding an HTTP endpoint, and among the last few changes I made before<br>shutting down was to migrate some of our endpoints to newer technology.
I absolutely hate this feeling. Someone innocent, who was not fortunate enough to be free on Midsummer,<br>could not do their job. Or at least that was what I thought. I made some coffee and booted my computer<br>again - I needed to take a closer look at this error before I would be able to relax enough to start<br>our celebrations 2.
2. It was not only Midsummer that was approaching; two days after, we were having a<br>birthday party for my daughter with 25 guests, and the day after that, we were going on a 2.5-week<br>road trip.<br>When investigating the error, it turned out to be a false alarm. The failure was real, but it was bot<br>traffic that caused it, not "real" traffic, and the error had nothing to do with my changes. Phew!
Still, the request should not have caused an error to be reported (bot or not). That needs to be adjusted,<br>but it is not urgent. I added some comments to the error and once again shut down my computer to<br>celebrate Midsummer.
This got me thinking: what is the essence of that bad feeling, and what do I do to avoid it?
Guilt
Whenever I introduce an error in production I feel guilty - I have let someone down. Someone was<br>trying to accomplish something using the software I have built (or been part of building) and they<br>could not do it. Something that worked yesterday is no longer working.
Maybe the task the user tried to accomplish was critical to them? Could this failure stop them from<br>doing their job? What about their income, or their customers? What is the extent of my failure?
You see, failure cascades across domains and organisations. I like to think of it like ripples on<br>the water. Throw in a stone (an error) and it will ripple across the surface. How many rings? It<br>depends on the shape of the stone (error). And like ripples on the water, the effect eventually<br>fades out, but there might be an awful lot of rings.
Failures also scale, in the bad way. How many of your users are suffering from these - one,<br>a hundred, thousands? That might be a lot of rings.
Many years ago, I was involved in a project that made a big-bang release3. Everything was running<br>smoothly until it didn't. The project manager called me and said that the point-of-sale systems of<br>a thousand shops were down. I asked of how many. A thousand, he said. Fortunately this was detected<br>in the evening and not during prime time. My colleague and I stayed up all night reverting the<br>change everyone thought was causing the outage (we were not sure, we had basically no automated<br>tests). Later, it turned out that there was an infrastructure change made as well, which was<br>most likely causing the problem, but no one knew for sure.
3. Has this ever been a good idea?<br>That was the worst day in my professional life.
Neglect
The world is full of crap software - we have all experienced this. Poorly designed "solutions",<br>or unstable software we have to use.
Poor software is such a waste of money and/or a missed opportunity. But what really annoys me is<br>bugs, when things just don't work. Or when you are forced to work around a system to perform your<br>task!
Suggesting a workaround as a fix has almost been normalised these days. This is ridiculous, a<br>workaround is NOT a fix!
Time. Time itself is infinite, but for each person and organisation it is finite, and very<br>precious. This is true for all persons. Then why are we (as software makers) so disrespectful<br>of others' time?
Value. Software is supposed to add value; when software fails to deliver what it is supposed to,<br>the value is not zero, it is negative! The user needs to compensate for the malfunctioning<br>software with, you guessed it, their time.
Guilt-Driven Development?
I do not remember where I first heard this term (I guess a lot of people might have independently<br>coined it), but I like it.
You should not (and should not be forced to) deliver something that gives you guilt, guilt of not<br>being done, not being robust, not being maintainable, etc.
That feeling of guilt I felt at Midsummer is something I'd rather avoid, and I do so by following<br>my four T's. Thinking, Types, Tests and Telemetry .
Thinking
This might come as a surprise to you. Everybody thinks, right? Right? Well, no. I have both fallen<br>into and seen others fall into the trap of immediately bringing out the keyboard and...