Becoming a Better Bug-Fixer

Question

I love being a programmer. There, I said it. However, with that said, I've realized lately that I really can't stand bug-fixing. At all.

In fact, while I'm developing something, my productivity is extremely high. Even when writing unit-tests and doing self testing of my development, I'm generally really productive. I can focus well, and I can get tasks done.

However, when QA time comes around and I'm working on fixing bugs, my inspiration takes a massive nosedive. I have to force myself with pretty extreme measures (you know, high BPM music, excessive amounts of caffeine, etc.) to get anything done. My job is usually involved with stepping into an existing massive project and adding new features or fixing bugs, so I can't exactly tell my employer that I need a couple weeks to write unit tests for all of their code :) In addition, the server technology that we often use is very prohibitive to both unit and integration testing, as it has quite a few Java classloader issues. I'm not completely against bug-fixing, sometimes it can be fun, but it's not fun at all when you have to make minor changes and wait 30 seconds to 3 minutes to be able to see if they worked or not (due to the way the system works).

How can I improve my productivity and motivation when bugfixing? Is this something that most programmers deal with?

related: [What is the most effective way to add functionality to unfamiliar, structurally unsound code?](http://programmers.stackexchange.com/questions/135311/what-is-the-most-effective-way-to-add-functionality-to-unfamiliar-structurally) — gnat, Mar 13 '12 at 15:31
*"so I can't exactly tell my employer that I need a couple weeks to write unit tests for all of their code"*. Is there a reason for that? I do that a lot, and it really pays off for everybody. I mean, if you take 3 weeks to unit test, you might just save 3 weeks of bug fixing. Usually I even find loads of *eventual* bugs that totally went under QA's radar. Sure, you probably don't want to do that all by yourself. — netcoder, Mar 13 '12 at 16:07
I almost prefer fixing bugs to writing new code. I especially prefer it to writing unit tests. Maybe I'm weird. — Paul Tomblin, Mar 13 '12 at 17:11
@PaulTomblin I understand what you're saying. I know some developers who love frontend development...me I like non-UI code the best. Writing new code is difficult at times because you sometimes get "writer's block" — Michael Brown, Mar 13 '12 at 18:09
It's difficult to measure the "productivity" of bug-fixing because you might spend a lot of time finding out what is "not the problem", just like Edision is purported to have said that he found "1000 ways NOT to make a light bulb", and I think that the non-fixes are often instructive in teaching you what clues are important and the current (and future) bug-fixing task. — Zeke Hansell, Mar 13 '12 at 19:03
It's funny, I think I have the opposite problem, I like fixing bugs more than I like writing new features... — PearsonArtPhoto, Mar 13 '12 at 21:32
Unit Tests are not the panacea to fix bugs. And while they might be something you can do when you refactor and rewrite parts of the source code, they are not the solution for finding a bug that needs fixing "RIGHT NOW". Unit tests often while they can help you to insure that the code for a unit behaves "as advertised", can't catch those bugs that crop up when units interact in ways that are perhaps unexpected. It's like suggesting that your code include an "UNEXPECTED ERROR HANDLER". I mean how can you handle an error that is unexpected?? — Zeke Hansell, Mar 13 '12 at 23:18
possible duplicate of [How to improve your ability to debug existing code](http://programmers.stackexchange.com/questions/11726/how-to-improve-your-ability-to-debug-existing-code) — GSto, Mar 15 '12 at 17:35

score 21 · Answer 1 · answered Mar 13 '12 at 17:29

it's not fun at all when you have to make minor changes and wait 30 seconds to 3 minutes to be able to see if they worked or not

That's the real problem here. You feel unproductive when you have to wait so long for feedback, I know the feeling. Perhaps it is possible to fake out more services and create better test tools so you can get immediate feedback.

Unit testing legacy code is expensive or can involve dangerous refactorings. However, creating better test fixtures can let you hand test in seconds compared to minutes and you can get almost the same productivity as working with new unit testable code.

Waiting so long for feedback is boring and demotivating, not the act of fixing bugs itself.

Ever read the Mythical Man-Month? Just picture waiting 'til the next morning and trying to analyze the stack dump/register contents that were present at the time of failure... — sq33G, Mar 14 '12 at 08:39
@sq33G Or even worse, having your test team in India that you only talk to via email (real story). — Garrett Hall, Mar 14 '12 at 13:24

score 13 · Answer 2 · answered Mar 13 '12 at 16:09

13

Bug fixing is an extremely important skill that you should learn. I read somewhere that, normally one spends 80% of time fixing the 20% of issues in an application.

I believe in learning from mistakes, and bug fixing is an opportunity to learn from others mistakes. You can take it a learning and will help be a better programmer in future. This is the motivation I had when I started fixing a lot bugs and moving forward to re-factoring the code.

answered Mar 13 '12 at 16:09

ManuPK

822
1
8
16

2

What you write is true; however, your 80%/20% is only true because there is so much crappy code in the wild. By crappy I mean, under-designed or over-architected or mis-architected or just plain sloppy practices (crack-head programming). That being said, there is nothing wrong with a developer preferring development to bug-fixing. Add in the fact that most software is poorly designed from the start and you are already setting most bug-fixers up for failure. – Wil Moore III Mar 19 '12 at 18:55
@wilmoore: You are right with the crappy code, and there is also the changing requirement. – ManuPK Mar 20 '12 at 02:29

Alexander Gessler · Answer 3 · 2012-03-13T18:35:49.500

6

Personally, I've found it helpful to stop thinking of bugs as 'small things' but rather as big showstoppers that are just as important as huge features even though they just involve changing a few lines of code after hours of debugging. That way, having spend an entire day to kill 3 bug tracker entries is way less depressing (the approach depends a bit on your personal ability to talk yourself into believing it :-).

Maybe it helps to make it a game, for example together with your co-workers (who fixes the most bugs a day? Or, even worse, who did the least number of rebuilds a day?)

edited Mar 13 '12 at 18:35

answered Mar 13 '12 at 16:24

Alexander Gessler

742
4
11

I strongly disagree with making it a game of fixing the most bugs in a day, or the likes of that. Some bugs are trivial to isolate and fix once you know how to trigger them: paste that particular value into this field, and watch: the length remaining is now wrong. (Maybe you're counting bytes instead of characters and forgot about the space above, say, U+007F.) Others (particularly bugs involving various race conditions or multithreading) can easily take days of work to reproduce, but be critical when they do occur in the field. They both warrant only a single entry in the bug tracker, though. – user Mar 14 '12 at 08:44
Counting such bugs equally would mean that everybody would just fix the simple bugs rather than tackling i.e. race conditions .. but isn't that the case with unmotivated, unfocused bugfixing too? :-) Not letting 'hard' bugs rest in favour of simple things is a totally different topic. – Alexander Gessler Mar 15 '12 at 16:16
There is also the matter of the quality of the fix. In many cases you can make a quick workaround-ish fix to a bug without getting to the cause, but then a similar error crops up either in some other place or in some other situation. Understanding and fixing the nature of the error often takes longer, but generally leads to a much more robust fix. Unless it's "this is failing all the time in production and we have to publish a fix *now*", I know which approach I would prefer (and even if it is, going back to fix the broken bone rather than just bandaiding the cut would be a good idea). – user Mar 16 '12 at 08:48

score 5 · Answer 4 · answered Mar 13 '12 at 15:31

5

I've been in your shoes. Build automated tests when and where you can. It doesn't have to be all at once. When you find a bug, take a minute to try to program a test case. If you can't program a test case, write a quick blurb somewhere about how to manually test it, e.g. click-here, type this, etc. and put it into some sort of Knowledge Base.

Debugging can be very tiresome, especially with complicated code you didn't write. Come up with a goal, "Fix Bug 13533 by Friday". Then setup a reward if you meet the goal, "Grab a pint with my mates Friday night". This will help make it a bit more rewarding.

Other than that, sometimes work is just that... work.

answered Mar 13 '12 at 15:31

Michael Rice

151
1

For this current project, I have, in fact, written unit tests. The only problem is that no matter what I seem to be able to prove using my unit tests, everything goes to hell in production/real life, due to the issues with the server technology. Unfortunately, there's no other alternative and I'm not in the place to change the engine, so to speak. – Naftuli Kay Mar 13 '12 at 15:34
You need to write an "unexpected error handler" routine to help you catch those ;-) – Zeke Hansell Mar 13 '12 at 23:19

score 3 · Answer 5 · answered Mar 13 '12 at 15:31

In this type of a situation, you need some kind of creative challenge. Normally, it's writing code, but here it isn't.

But, all is not lost. Work on solving your meta-problems and pour your energy into that. Why does it take 30 seconds to 3 minutes to get feedback? How can you shorten that time? (Maybe you can write some kind of script or utility app that you don't check in that helps you do this). That's your new problem domain -- your new creative challenge.

Personally, anytime I'm in a defect fixing phase, I identify my biggest barriers to getting it done quickly and painlessly, and I automate what I need to automate to remove those barriers. This often results in boosted productivity and additions to my personal portfolio to boot.

So, in short, I'd say "always be developing." :)

I hear you. I wish I could do something to automate things. I've got a server and a client, and I can't exactly automate the client easily. There are multiple stages in the workflow of this thing and many of the bugs arise between stages, so I have to do a 30 second stage, then a 3 minute stage, or in reverse. Bottom line, it's pretty nightmarish >:) — Naftuli Kay, Mar 13 '12 at 15:38

score 2 · Answer 6 · answered Mar 13 '12 at 16:32

Is your problem debugging or bug fixing? If you can debug enough to isolate the component that's causing the issue, then look at it as a new development task.

Write some unit tests for just the piece of code that's breaking. Make sure you have tests validating all of its desired functionality, plus some that particularly isolate the buggy behavior.
Write new code that passes all the tests you just wrote.
Replace the old code with the new.
Run some integration tests. This is where you'll run into your three minute server reboots, but it should be minimized if you did steps 1-3 well.
Voila!

score 2 · Answer 7 · answered Mar 13 '12 at 18:56

Maybe you should look at Brian Hayes' Debugging Myself, an article that appeared in American Scientist in 1995. You could take steps (like habitual use of Yoda Conditions) to reduce or eliminate the most hated kinds of bugs you produce.

I am of the opinion that debugging is a skill different than programming, although related. In particular, debugging multi-threaded programs is almost entirely different than writing them.

kevin cline · Answer 8 · 2012-03-13T16:34:09.870

1

If software development is boring, you are doing it wrong. In other words, it's not a problem with you, but a problem with your platform and process. Have you considered looking for a position using a dynamic language (e.g. Python, Ruby, JavaScript), where you don't have to wait for server restarts?

edited Mar 13 '12 at 16:34

answered Mar 13 '12 at 15:34

kevin cline

33,608
3
71
142

Unfortunately, it's not an option at this stage. Plus, the workflow, as mentioned above, requires multiple stages and steps and the bugs emerge between these stages. If I were writing this from scratch, I'd for sure look into using a scripting language, but we're stuck with what we have for now. – Naftuli Kay Mar 13 '12 at 15:41
1

@TK: At my last company we had great success integrating Groovy into our Java development process to automate formerly manual processes. It's not Java, but it was close enough, and so effective that we had very little push-back. – kevin cline Mar 13 '12 at 16:35

score 1 · Answer 9 · answered Mar 13 '12 at 17:03

It's part of the job, unfortunately. You will have crappy projects and crappy employers (I'm not saying either is the case here, just generalizing).

You can write unit tests against their code. Sneak it in as you can. Once you have something you can show to the bosses, you may be able to turn the tide.

Use debugging tools to fix the slowness, use unit tests to test new code and use them to fix existing code's issues as well as breakdown the existing code into smaller pieces.

You can make it a challenge and become a process improvement hero. And, if it doesn't work, you will have good experience to take to the next employer.

score 1 · Answer 10 · answered Mar 13 '12 at 17:17

Most programmers have to deal with bug-fixing personal issues at some point in their career.

The right sense of person-to-work distance is essential for your motivation. Do not over- or underidentify with your work. If you are overly identifying yourself with your work, problems such as the ones you have described can surface: You might be very reluctant to fix the bugs since you are half of the time blaming yourself. Get some inner distance and find out how you can work on your problem rationally.

Regarding the particular issues on your platform, there are a few ways to mitigate long deploy and test times (and, on the side, yours aren't particularily long).

Firstly, the longer your test time is, the more averse you should be to cargo cult. If you make a change, think about it until you are confident it will fix the bug. Of course, just how confident is subject to the length of your test cycle. But if your test cycles get longer, and long tests can't be avoided, spend more time thinking, and you'll be rewarded and more happy in debugging because it is faster and has the rewarding effect of a good moment of "fiat lux".

Secondly, bias more towards unit tests and less towards integration tests. Remove every point-of-failure from the hard-to-debug platform you can.

score 1 · Answer 11 · answered Mar 13 '12 at 17:37

Bug fixing can be "awesome" or "tedious". I have some game credits that are entirely due to fixing one single bug - the crash bug that no-one else could fix. But the day-to-day grooming of bugzilla is mind-numbing. Minor bugs are tedious. Major bugs are worthy.

Here's the realization: The fact that you have a giant list of minor bugs is itself one major bug. Its just not a code bug. Its a process or management bug.

Find that bug, and fix it.

score 1 · Answer 12 · answered Mar 13 '12 at 18:55

One thing I have found among colleagues and acquantances who are good "debuggers/bug fixers/problem solvers" is that they generally like to solve puzzles. That might mean crossword puzzles, number games (like Sudoku), and logic puzzles, etc...

So one way you might become a better bug fixer would be to spend some time working on your problem solving or puzzle solving skills.

Here is a Wikipedia link that might be a good starting point for things to help you to be a better problem solver.

Mind you, some people are just better at problem solving, or they just enjoy it more. Some people don't like it at all, which makes it hard to force yourself to do - but make no mistake - if you force yourself to learn to be a puzzle solver it will make it easier to be a good bug fixer in the future.

score 0 · Answer 13 · answered Mar 14 '12 at 08:36

Bug fixing usually feels like a chore because it can make you feel like bugs are taking up all of your time and keeping you away from the fun new stuff. The reality is however that bug fixing is a very large part of what we do, and it starts as early as writing the first line of code and executing the compiler. When you release code for the first time, you have probably already spent hours fixing bugs, only it doesn't seem that way because you've been fixing them as part of the process of implementing features. Realistically speaking, no matter how good a programmer you are, bugs will creep into your system.

So how do you make it fun? Well, I can't really answer that for you as I really can't imagine what it is that floats your individual boat. For me, I'm a bit of a tool junkie, so the answer has been in having a very reliable tool chain, and a flexible development process that all contribute to making bug fixing less of a chore, and more simply a problem to solve quickly. I'm presently developing mostly in C#, and I am always on the lookout for tools that will remove the tedious time wasting parts of writing software. I use a test first development approach supported with a very good BDD API called StoryQ. I use Resharper to automate much of my refactoring and StyleCop to keep a lid on things like coding style. My latest addition to the tool chain has been to include NCrunch which runs my tests continuously and concurrently in the background while I code, and it's really been NCrunch which has proven to be the game changer.

The combination of all of these tools has seen my productivity go through the roof lately, as I waste very little time waiting for things to compile or execute. I get instant feedback visually within my IDE to let me know that I have issues to fix, and I lay out my test code in such a way that I can pinpoint to within a only a few lines of code the exact place where not only the failure occurs, but to where the cause of the failure occurs due to the lovely verbose reporting that I get from StoryQ which tells me exactly which parts of my test pass, which fail, and where in the code the failures are. With all of the time wasters removed from my development time, I spend very little time actively debugging, and more time solving problems and writing tests and code. The high turnover off issues keeps me busy, and brings a lot of variation in my tasks. It has also given me lots of time to pursue other areas of interest during my work day so that I can inject new and innovative ideas into our product line, and our processes.

Becoming a Better Bug-Fixer

13 Answers13