Reading · Bad Software Advice

This page did not load. You can still read it on the original site — the toolbar below keeps your place in the directory.

Bugs means mistakes, which means that you are stupid, which is frankly quite upsetting

From time to time, software does not behave as it should1.

When this happens, there is usually an effort to fix it. However, there is a gap, called reality, between the person who sees something odd and a software developer assigned a detailed description of something to fix.

Choosing the victim

The person responsible is chosen using a series of heuristics based on how the organization works:

Often, the teams are created so that routing bugs is easy. If the UI has a problem, assign it to the UI team.
Other times, an on-call person is assigned the problem. They review it and then curse.
Other times, mentioning a word or phrase invokes a person’s name. “It looks like the tax is wrong” => “Didn’t Terry work on that?” => Terry’s phone starts to ring.
Sometimes, it goes through a few less experienced people before the right person, which takes more time. This is called a mature support organization. These typically have Levels - Level 1 can’t figure it out and then Level 2 gets involved. The levels map to the current heart rate of the reporter of the bug as they wait on a fix.

What To Do If You Are the Responsible Party

Once you find the right person, you have also seen the person most likely to have caused the problem. This might be you.

If you work on the tax invoice engine (v1)2 team now but didn’t 3 years ago, you might be a proxy person for the person who wrote the bug. You are now the most experienced person in this area of the system, so any issues with it are mostly your fault. You might be thinking, “well I’m responsible, but I’m not at fault”, which indicates that you think language matters in the workplace - a common fallacy.

You may have never heard of the part of the system that contains the bug, understand the bug, or be aware of the component that is failing, or what it is supposed to do, or how urgent it is, or that it saying “17” instead of “19” even means in terms of impacts to users, or any other number of logical questions. These do not matter and frankly sound a lot like excuses springing from a bad attitude on your part.

Providing Resolution

The person responsible then set off to determine what happened and work towards a solution. This process is called Debugging. Writing bugs is called Software Development. Half-fixing a problem is called Rebugging. Ignoring a problem in the hopes that it goes away is called Unable to Reproduce. Anything that causes people to stop talking to you about a problem is called Resolution.

After you fix the problem, you might think that some effort should be made to figure out how it happened and how it could have been prevented. This is naive, and a little cute, but allowed.

Finding the fix

We have written about how to actually debug before:

Documentation

I don’t know why I put a section here; it is a bad idea to write stuff down.

Bad Software Advice is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

All the time based on your experience - developers only see the software that needs changing, so it seems like nothing ever works. Everything they hand you is broken, on fire, needs paint, or needs an upgrade. At the same time you feel like everything should be working, right?

v1 - there is no v2 really, v1 is still live in production and serving all traffic. v2 is a project that gets started every few years and then the budget or people working on it dissappear.

How to assign a bug report