Stop doing stupid things May 28, 2026

Before we launch into this, a disclaimer: Please note that nowhere in this post am I labeling people as stupid! Stupid things happen to the best of us. The trick is to recognize them as such and deal with them appropriately.

Recently, I've seen a spate of blog posts along the lines of:

1. We did this stupid thing.
2. We stopped doing it.
3. The world is so much better now. Everyone should stop doing this!

An example would be replacing the frontend framework every six months, resulting in a lot of work and frustration, but no real gains.^[1] This is the kind of thing I mean when I say stupid. The kind of thing where, if you take a step back and look at it dispassionately, you cannot help thinking, “How on earth did anyone ever think this was a good idea?” The solution in this case was to not replace the frontend after six months but to go with the current incarnation for at least a year and then decide how to proceed based on actual needs.

I think this is great because doing fewer stupid things (a) has great potential to improve the world, if alone because there are so many of them going on, and (b) is much less demanding than coming up with clever solutions to hard problems.

For example, I've done my share of performance optimizations during the course of my career, some trivial, some clever, and I can tell you this: never have the gains been greater than when I found something really stupid that I could just stop doing. Like a performance-critical application I worked on that was deep-copying a lot of hash maps around. Not by accident, because it was implemented sloppily, but by design. My redesign included some more sophisticated optimizations, but the greatest gains came from avoiding making unnecessary copies and the memory allocations associated with them, i.e., from the simplest measures.

To be clear, I'm not talking about situations where you implement something and it turns out later that the solution is not optimal for such-and-such reason, which you could not have known at the time. I'm talking about situations where you could have known if you had just stopped, taken a step back, and thought for a minute. Or an hour. Yes, I know, I know, thinking is hard and stopping and taking a step back isn't in fashion right now when acceleration is everything, but skipping it does yield stupid “solutions” the cost of which is measured not in minutes or hours, but in days, weeks or months.

One project I worked in had implemented publishing events to Kafka this way:

1. Run domain logic in one service that determines that the event has occurred. At this point, this service has all the data about the event in memory.
2. Notify a “Kafka producer” service (belonging to the same team) via HTTP that an event has occurred for a domain entity, transmitting only its ID.
3. In the “Kafka producer” service, call the REST API of the first service 10 times to load various parts of the data required to assemble the event, assemble it, and then send it to Kafka.

As a result, sending an event often took longer than 10 seconds, was not atomic, and had a non-trivial chance to fail because there was no retry mechanism or anything else that would allow recovery if any one of the HTTP requests failed. If we had just stopped splitting the system into so many “microservices” with technical (not domain) boundaries, we wouldn't have had this problem. At all. The thing is, at no point during the design of this system did anybody think, “Wouldn't it be great if we made 11 cross-service calls to publish a single event?” Of course, there were reasons. There always are. They arrived at this design in a series of steps, each one logical per se, but there is no getting around the fact that it has slowness and unreliability baked in.

So what can we take away from all this? Stop doing stupid things! If you feel that things are not running as smoothly as they should, maybe there is a stupid thing going on. Look out for it! Look at the system (or process) you have built from a bird's eye view, forget the details of the reasoning that brought you here for a moment, and ask yourself, “Does this make sense?” Don't just look at the latest decision and the local context it was made in either! Also look at prior decisions, the trajectory you set up for yourself, and the structure and behavior of the resulting system as a whole, and ask yourself:

• Does this support the system's goals when taken together?
• Or are we doing something stupid?
• If so, can we stop doing it?

For example, the team that wrote about stopping frontend migrations didn't just look at the latest decision to migrate their frontend to Vue, but also their past decisions to migrate to React or whatever. They could probably remember the reason for each decision, but they put those aside for the moment and asked themselves whether the pattern of rewriting every six months make any sense. It didn't, so they stopped doing it.

In my performance example, looking at a single function, you could be forgiven for thinking that making one copy of a hash map wasn't so bad. But when I looked at the whole process and saw how often this stuff was copied around, it struck me as stupid and made me think that we needed another approach. Of course, I could have taken the local view again and optimized the copying, but it was far better to just stop doing it.

And in the event publishing example, I know there were some (mainly technical) reasons for putting the Kafka producer in a separate service, but if the team had taken a step back at design time and really looked at the process they were about to build holistically, they could have solved those differently and created a much more reliable – and faster – solution.

So how about you? What stupid thing are you currently doing that you could stop?