The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Joel Test: 5. Do you fix bugs before writing new code?

The developers on my team answer this question "Yes" but we aren't quite sure about it. What are your thoughts and experiences? Here are some details:

We are close to a small milestone (releasing to first end-user test) and hence are simultaneously working on
1. the last few features scheduled for this release;
2. bugs reported by testers; and
3. stabilising and productionising.

We assigned one guy, a speed demon, to item 1. We only assigned him bugs that turned up in the new features he had just written. He fixed those bugs as he went when it was convenient, but his main focus was turning out the new features. He's just finished the new features and has a backlog of 10 or so bugs to work through now; these bugs will be his only priority until he finishes them.

To everyone else, we assigned bugs as they came in from test. These are, as I said, the bugs _not_ relating to the new features written by our speedy guy. Each such bug went either in the "must be fixed by deadline" pile or the "can wait" pile; as you'd expect, the first priority was the "must fix" bugs.

An example of a "must fix" bug is "I can't enter a price in the data entry screen." Users will be testing this feature, so we need to be sure it works. Incidentally, one of us was working on this feature recently, so we assign it to him and expect to get it fixed faster (since he remembers the code well).

An example of the second kind of bug is "The confirmation message for adding a user sometimes doesn't appear." The users won't be testing admin screens in this phase, so the immediate benefit of fixing this bug isn't high. Further, there's no substantial _loss_ from fixing the bug later, since we haven't touched the admin screens in weeks and therefore don't have someone who can say "I just wrote that, I know where the bug is".

After fixing all the "must fix" bugs, each coder's second priority was productionisation tasks (from a list of these we made). An example of productionising is changing "Null pointer on line 12" to "Could not update price. Please contact your system administrator and report error code ABCD123." The goal is to make the application more robust and easier to support, without disturbing any features.

Finally, the third priority was fixing those "can wait" bugs.

Once we reach our milestone, we'll get to the "can wait" bugs, while simultaneously working on new features scheduled for user testing later. For example, if admin screens were the next things users wanted to test, we might assign Mr. Speedy to code up a new admin screen and fix resultant bugs, while giving others bugs and features on the existing admin screen.

So, are we "fixing bugs before writing new code"? Should we take this literally, and tell each coder to ensure that the bug count across the whole program is zero before he starts any new feature? How does your team manage its bugs and features?


Why am I asking this? In about a week, I need to make a presentation to the board about our development assets, and want to use the Joel Test to describe why our good processes are one of our assets. I am asking a series of questions about different Joel Test items to help me prepare.
Squirrel Send private email
Wednesday, October 20, 2004
Depends on the severity of the bug - if it's just a nuisance it can wait while we do more important stuff.
Actively Disengaged
Wednesday, October 20, 2004
Compare and contrast what Joel says about #5 on the Joel Test, and
i like i
Wednesday, October 20, 2004
Users don't "test" features, they use them. That aside, your arguments sound perfectly reasonable to me.
Daniel Daranas
Wednesday, October 20, 2004
> So, are we "fixing bugs before writing new code"?

It doesn't matter as long as you get a good product at the end.

Wednesday, October 20, 2004
No process, methodology, or "Joel Test" is a substitute for using your own brain. The question is: "Are you doing the Right Thing" for your project? And if not, why not?
Wednesday, October 20, 2004
"Compare and contrast what Joel says about #5 on the Joel Test, and"

Joel is the King and all, but I remember reading this in his book, and its like he goes on for pages about how you should NOT fix EVERY bug, and then he blithely says, "oh yeah, well screw that, at FogBugz, we are so great, we fix EVERY bug". He kinda shot his own credibility in the foot.
NetFreak Send private email
Wednesday, October 20, 2004
As a CityDesk user, I can assure you that Fog Creek does NOT fix every bug before adding new features.

Wednesday, October 20, 2004
I think the whole *point* of fixing bugs before you implement new features is that removes the risk from your schedule.

If I have a bunch of features to implement, I can ask a programmer to give me an estimation of how long it's going to take to complete each one. As a general rule, the amont of time it takes that programmer to produce a reliable estimate will be very small compared to the overall time it will take to add the feature. But bugs often (not always though) work differently. The amount of time spent understanding the issue and designing a solution is going to be a huge proportion of the total time spent fixing the bug. In other words, you'll spend about 3 weeks debugging, then when you realise what the problem is you'll spend about 2 seconds changing "<" to "<=".

If you have 100 features to implement, you can ask your programmers to get back to you with a detailed estimate and it wont take them very long. If you have 100 bugs to fix, you can ask your programmers for an estimate and they'll either give you a complete guess, or they tell you they'll get back to you when they've almost fixed it. Either way planning your release schedule is next to impossible. The only way to get an accurate release plan is to minimise the number of bugs on the plan. So, fixing bugs before writing new code is a way of making your project plans more accurate - which makes good business sense.
Wednesday, October 20, 2004
> How does your team manage its bugs and features?

I'm implementing a new system from scratch. I won't be able to write it all in one day ... and therefore I write it as a series of chunks (where "one chunk" is about one day's- or week's-worth of work).

An example of one chunk might be the GUI. I might write the GUI, before I write the underlying data model or business logic: and therefore, when you run the GUI, it will look good at first sight, but not behave properly (e.g. pressing the "Save" button does nothing).

At this stage of development, if someone said to me "The'Save' button doesn't do anything", I would *not* treat this as a bug ... instead I would say "it's working as (presently) designed".

I.e. at at early stage in the game, then a bug-that-I'd-fix-at-interrupt-level is when the software is doing anything that I (the developer) didn't intend it to be doing.
Christopher Wells Send private email
Wednesday, October 20, 2004
I think critical bugs that affect the general operation of a program in a popular/significant area of the program should be fixed before writing new code.  The idea behind this is to try and ensure that there is a fairly solid version for you to build features on to.  This allows more accurate estimating of schedules (as Dan pointed out) and also means that you don't code something that accidentally relies on a bug.  The other obvious benefit is that you can release a program without the bug in it :)

While you still have a lot of development it might help to split the program into sections.  Ie you don't write any new features for the product set up screen until all it's bugs are fixed, however, you can carry on adding new features to your bug free order entry screen.

The main problem with bugs is that you a) don't know how long it will take to fix, b) fixing it may mean changing significant parts of the code, c) a minor bug maybe a symptom of a serious one that hasn't been fully realised.

It might be worth asking your developers to triage the bugs list as they maybe able to think/implement the fixes quickly as they just made a silly mistake.

To be fair it sounds like you're doing it right.  So long as it's working for you then keep doing it :)
Steven Send private email
Wednesday, October 20, 2004
I personally do indeed fix all bugs as I go. If something's a problem, it's better to sort it out early in the cycle than later, since problems have a nasty habit of hiding other problems - and before you know it, there's your release date missed.

There is a distinction, however, between "bugs" (functionality that works incorrectly or not at all) and "missing/changed features" (stuff that is not completely implemented, or where the user spec has changed).

Basically if something is not working correctly in something that has been "implemented", then it hasn't *really* been implemented at all!

Saying something is "complete, except for a few bugs" is just fooling yourself that you have completed work that has not, in fact, truly been completed. Best to be honest about these things.

Main point: if it's a problem that might hide other problems, tackle it sooner rather than later.
Thursday, October 21, 2004
What the question probably tries to say is that if you are going to fix a bug, then you should do it before you add more code, since the more code you have the harder it is to fix a bug.

I think that when the bugs are somewhere that's not directly related to the new features, it's ok to have people work on both at the same time, especially if the bugs have been identified already.

If not, I'd priorize finding those bugs you intend to fix, because it's awfully hard to predict how long it'll take to find the cause of a bug, and it's generally easier to cut off (or simplify) features than to speed up bug hunt.

Finally, new features tend to introduce new bugs, and empirical experience is that having N bugs that interact with each other makes it x^N times harder to identify the real causes.
Friday, October 22, 2004
I remember one bug I came across which seemed pretty trivial at the time:  The condition would only occur once in a blue moon, wasn't fatal, only caused a minor application pause and I was unable to find conditions to duplicate it.  Heck, why worry about that when I have a schedule to stick to!

Once I handed the first iteration of the product off to a client for production use, it was a different story entirely:  The application froze, crashed and corrupted data.  The client was suddenly wondering if they wanted to take their chances with an application which otherwise looked good, but operated like an unreliable piece of crap in production.

Turns out, the issues were caused by one-and-the-same bug:  A single frickin' line of thread-unsafe Java code being used in a threaded environment.  Idiot me!  The minor error didn't show up often during testing, but as soon as 20 users were simultaneously pounding on the application, the bug showed up all the time.

My lesson:  If I find a bug, I fix it.  Now.

If a bug is too minor to bother with now, you won't touch it until it becomes major -- which sorta defeats the purpose of properly debugging code in the first place.
Saturday, October 23, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz