rss feed
Also, Joel points out that:
And lastly:
Fixing bugs before writing new code is certainly a good general rule of thumb for exactly these reasons. But it is not always the best choice in any given situation. Allow me to explain why.It's often said that highly skilled programmers are an order of magnitude more productive than poor or even average programmers. That may be true. But even within the confines of an individual programmer, productivity can vary greatly over the course of several days.Whether or not you count yourself among the set of highly skilled programmers, I'm sure you've had days where you've gotten almost nothing done, and not for lack of trying. You stare at your code, looking for the cause of a bug. You get some coffee. You stare some more, adding a few prints. You check Reddit and cycle through your email. You go back to your code. You close your door or put on headphones. You try a few ideas out, but to no avail. Before you know it, it's time to go home, and you've gotten almost nothing done.Other days, you're amazingly productive. Code falls out fully-formed from your head right into your IDE. You almost intuitively know what's causing a bug, and after a few minutes, it's fixed. You're, well, on fire. Not in the overheating lithium-ion laptop battery sense, but more in the NBA Jam sense of the word (http://www.youtube.com/watch?v=X7dFMbubxr4).What accounts for this great variability in productivity within a single programmer? Well, as you can imagine, there are a number of factors. Maybe on your unproductive days you're having trouble concentrating due to constant interruptions, or perhaps you just bricked your iPhone and you're too sad to focus on your code. Still, despite these problems, the number one cause of variable productivity within a single programmer is that programmer's motivation.On your best productivity days, you're interested in the problem you're working on, you've got everything you need to get your job done, and you're invested in the outcome. On your worst days, you're feeling like your efforts will make little impact, you're fed up with management, or you're just tired of the problem at hand. So other than slight variations due to interruptions, bricked iPhones, and so on, an individual contributor's motivation is the single greatest determiner of their personal productivity level.Now, back to the original topic. When Joel asserts that you should always fix bugs first, he's leaving out a very important component from his "What should I do next?" task selection algorithm. He's making the selection of his next task based solely on the relative priorities of the available tasks. In other words, he's claiming that bugs are higher priority for the reasons stated above, and therefore they should be fixed first.But just because something is the highest priority doesn't mean it's the next thing you should work on. This sounds counterintuitive, but a programmer's productivity, their individual contribution to making a product customers want, is like a function with many inputs. One input is the priority of the task they're working on. Another input is that programmer's motivation. By just blindly working on bugs first, Joel is only looking at the priority input while completely ignoring the motivation input.There are two rather interesting properties of a programmer's motivation. One is that you can consciously manipulate your own motivation, with varying degrees of success, and the other property is that your current motivation has a fair amount of momentum. In other words, it tends to change slowly over time, at least in the absence of stimuli that cause it to spike or crash.So, if you're getting frustrated and upset when unsuccessfully tracking down a particularly difficult bug, and therefore wallowing in the depths of unproductivity, sometimes it can help tremendously to take a break to clear your head and get motivated again. You can often accomplish this simply by going and implementing some small, well-defined feature. By putting aside the bugs for a bit, you can finish an easy task and get your productive juices flowing again, thereby giving a much-needed spike to your morale. Then, once the feature is done, you can go back to tackling that annoying bug with renewed motivation and a clearer head.In general, whether or not you're working on bugs, you can often get a huge morale boost simply by stopping work on a boring high-priority feature in order to work on a more interesting lower priority feature. You may even end up getting the high-priority task done sooner, and with at a higher level of quality, than if you had just slogged through it without taking a break to code something more fun.Also, because of the tendency of motivation to stay at its current level for a while (in the absence of shocks like "Oh, by the way, this all needs to be done by tomorrow"), if you take a break to code up something that gives a boost to your motivation, that new level of morale can carry you throughout the day while you bang out less interesting tasks. One might even go so far as to say that the best programmers are experts at personal motivation management. They know how to manipulate their own morale such that they get the most done, even if that means not always working on the absolute highest priority tasks all the time.So, just to clarify, I'm not suggesting that Joel's "fix bugs first" rule is a bad idea. All I'm proposing is that like with any good rule, it pays to know when to break it.
blog - don't blindly fix bugs before writing new code
posted by witten on October 07, 2007
One of the questions on The Joel Test (http://www.joelonsoftware.com/articles/fog0000000043.html) is "Do you fix bugs before writing new code?" Joel gives a few very reasonable justifications for why this is a good idea:
In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
Also, Joel points out that:
There's another reason, which relates to the fact that it's easier to predict how long it will take to write new code than to fix an existing bug. ...if you have a schedule with a lot of bugs remaining to be fixed, the schedule is unreliable. But if you've fixed all the known bugs, and all that's left is new code, then your schedule will be stunningly more accurate.
And lastly:
...if your competitor introduces a killer new feature that is stealing your customers, you can implement just that feature and ship on the spot, without having to fix a large number of accumulated bugs.
Fixing bugs before writing new code is certainly a good general rule of thumb for exactly these reasons. But it is not always the best choice in any given situation. Allow me to explain why.It's often said that highly skilled programmers are an order of magnitude more productive than poor or even average programmers. That may be true. But even within the confines of an individual programmer, productivity can vary greatly over the course of several days.Whether or not you count yourself among the set of highly skilled programmers, I'm sure you've had days where you've gotten almost nothing done, and not for lack of trying. You stare at your code, looking for the cause of a bug. You get some coffee. You stare some more, adding a few prints. You check Reddit and cycle through your email. You go back to your code. You close your door or put on headphones. You try a few ideas out, but to no avail. Before you know it, it's time to go home, and you've gotten almost nothing done.Other days, you're amazingly productive. Code falls out fully-formed from your head right into your IDE. You almost intuitively know what's causing a bug, and after a few minutes, it's fixed. You're, well, on fire. Not in the overheating lithium-ion laptop battery sense, but more in the NBA Jam sense of the word (http://www.youtube.com/watch?v=X7dFMbubxr4).What accounts for this great variability in productivity within a single programmer? Well, as you can imagine, there are a number of factors. Maybe on your unproductive days you're having trouble concentrating due to constant interruptions, or perhaps you just bricked your iPhone and you're too sad to focus on your code. Still, despite these problems, the number one cause of variable productivity within a single programmer is that programmer's motivation.On your best productivity days, you're interested in the problem you're working on, you've got everything you need to get your job done, and you're invested in the outcome. On your worst days, you're feeling like your efforts will make little impact, you're fed up with management, or you're just tired of the problem at hand. So other than slight variations due to interruptions, bricked iPhones, and so on, an individual contributor's motivation is the single greatest determiner of their personal productivity level.Now, back to the original topic. When Joel asserts that you should always fix bugs first, he's leaving out a very important component from his "What should I do next?" task selection algorithm. He's making the selection of his next task based solely on the relative priorities of the available tasks. In other words, he's claiming that bugs are higher priority for the reasons stated above, and therefore they should be fixed first.But just because something is the highest priority doesn't mean it's the next thing you should work on. This sounds counterintuitive, but a programmer's productivity, their individual contribution to making a product customers want, is like a function with many inputs. One input is the priority of the task they're working on. Another input is that programmer's motivation. By just blindly working on bugs first, Joel is only looking at the priority input while completely ignoring the motivation input.There are two rather interesting properties of a programmer's motivation. One is that you can consciously manipulate your own motivation, with varying degrees of success, and the other property is that your current motivation has a fair amount of momentum. In other words, it tends to change slowly over time, at least in the absence of stimuli that cause it to spike or crash.So, if you're getting frustrated and upset when unsuccessfully tracking down a particularly difficult bug, and therefore wallowing in the depths of unproductivity, sometimes it can help tremendously to take a break to clear your head and get motivated again. You can often accomplish this simply by going and implementing some small, well-defined feature. By putting aside the bugs for a bit, you can finish an easy task and get your productive juices flowing again, thereby giving a much-needed spike to your morale. Then, once the feature is done, you can go back to tackling that annoying bug with renewed motivation and a clearer head.In general, whether or not you're working on bugs, you can often get a huge morale boost simply by stopping work on a boring high-priority feature in order to work on a more interesting lower priority feature. You may even end up getting the high-priority task done sooner, and with at a higher level of quality, than if you had just slogged through it without taking a break to code something more fun.Also, because of the tendency of motivation to stay at its current level for a while (in the absence of shocks like "Oh, by the way, this all needs to be done by tomorrow"), if you take a break to code up something that gives a boost to your motivation, that new level of morale can carry you throughout the day while you bang out less interesting tasks. One might even go so far as to say that the best programmers are experts at personal motivation management. They know how to manipulate their own morale such that they get the most done, even if that means not always working on the absolute highest priority tasks all the time.So, just to clarify, I'm not suggesting that Joel's "fix bugs first" rule is a bad idea. All I'm proposing is that like with any good rule, it pays to know when to break it.
2 comments
Write a comment!-
Have Your Cake and Eat it Too posted by pmcelhaney on October 11, 2007 04:37 AM
It's possible to both fix bugs first and put off bug fixing to start a new feature. Just create a branch for the new feature. That way you're not adding code to the mainline, and it won't be harder to fix bugs later. Once the bugs are fixed, you can land the new feature on the mainline. -
Re: Have Your Cake and Eat it Too posted by witten on October 11, 2007 11:19 PM
That approach does take care of properly sequencing the integration of bug fixes and feature implementation into the mainline code base, but I don't think it addresses Joel's other reasons for fixing bugs first. Namely, creating a branch to work on a feature doesn't mean bugs actually get fixed first. It only means that they're checked into the mainline first. So your schedule won't become "stunningly more accurate" until after you implement the feature and then implement the bug fix.Of course, in all of this discussion I'm talking about the "next task" selection for a single programmer, assuming that a single programmer can't both fix a bug and implement a feature simultaneously. Once this scales to multiple programmers, some things can be done at the same time, such as one programmer working on the feature branch and another working on the bug branch. But such a scenario doesn't scale in anything remotely resembling a linear manner..