fuzzylizard

For the past five months I have been involved in debugging a Java application. I hate debugging, but it wasn’t until recently that I understood why. I think there are three main reasons why developers hate debugging.

The first reason is that developers like to solve problems. They like to understand a business problem/domain in its entirety and implement a solution to that problem in code. Debugging is simply fixing someone else’s solution; it is not solving real problems. In many ways it feels like you are coming along after and cleaning up other people’s mistakes.

The second reason is that it is always harder to read someone else’s code then it is to understand code you have written yourself. The result is that to fix a bug takes considerably more work then it took the original developers to implement the solution originally. This makes debugging long, hard, tiring and frustrating work as you struggle, on every bug, to understand what someone else has written, and worse, what they intended.

The third reason is that due to the very nature of debugging it is incredibly difficult to understand the entire problem space. This is caused by the fact that you are solving a bunch of random bugs that jump all over the source code, never allowing you to stop and fully understand any one area of the implementation.

The result is that you work on an application for months and months and never feel that you understand it; never feel that you have contributed anything to it. The application never becomes yours; it always belongs to those who implemented it. You are simply a trespasser fixing those small errors left behind by those who went before.

In sports, if a team isn’t doing well, it is the manager who is held responsible. If the Bears or the Cubs (I’m in Chicago right now, can you tell) don’t win, people are upset with the players, but ultimately, the blame is placed squarely on the manager. He’s the one who gets fired.

In software development, I wonder if the same is true? I have not worked at enough companies yet to say categorically that blame tends to be placed on the developers and not the managers, but it is a general feeling I get while reading websites like Worse Than Failure.

I wonder how many projects would be more successful if the managers knew their jobs were on the line if the project failed?

I realize that I probably have a very naive view of the world and there are most likely many managers out there who have lost their jobs due to failed projects. The feeling, however, that I get is that the blame is always pushed down to the lowest person–the developer–and the managers try to figure out a way to make themselves look good through the developer’s failure.

It was just a thought.

I have added a page to my site called Acronyms. The page contains a list of things software development teams should keep in mind while developing applications. These include acronyms like FIRST, SOLID, and INVEST. The page is really just a handy way for me to remember them. Something I can look at every once in a while and remind myself about some important characteristics that various artifacts (tasks, story cards, classes) of the development process should have.