Fog Creek Software
Discussion Board




Fixing bugs rather than taking time

Did anyone else notice this quote:

"The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. "

umm...if you put in lots of bugs and fix them all, and it takes less time than doing it without bugs in the first place, wouldn't it be better to put in the bugs and fix them?  In both cases, according to the quote you end up the same place...

Not that I think this would really happen - it's quicker to do it right in the first place, but I thought the wording could have been better...

Tom Haviland
Tuesday, July 16, 2002

A lot of people like to believe it takes "extra time to get it right in the first place".  I agree it is quicker to "do it right" the first time and I have not found it true that it takes extra time to do it right.

Sometimes, I get the impression that "doing it wrong", or putting in the bugs... is a form of intentional rebellion that tries to prove extra time is necessary to do it right by getting it wrong.

Joe AA.
Tuesday, July 16, 2002

Believe me this does happen. I know a case where a manager insisted on measuring progress by the percentage of bugs fixed per week. Since the team was already working as hard as it could, the rate was achieved by simply introducing bugs and then fixing them until the rate was high enough. The manager was later sacked for incompetence.

Anonymous for obvious reasons
Tuesday, July 16, 2002

I work in a place that rewards you for the amount of code you write and the amount of bugs you fix, and we can still seperate the troublemakers from the truly good coders.  I guess that's what you get when your manager used to be a programmer, though it may have something to do with not getting credit for fixing your own bugs.

not that difficult
Tuesday, July 16, 2002

"may have something to do with not getting credit for fixing your own bugs."

OH!!  I have to agree with this!  "Your bug, you fix it!!" is a powerful feedback mechanism towards quality code.

One of the absolute worst places, with the lowest quality and bug ridden code, that I have ever worked on... NEVER traced back the bugs to their original source - each was merely entered into the "work management system" (i.e. bug tracking) as a "new defect".

Joe AA.
Tuesday, July 16, 2002

I think the "extra time to get it right in the first place" comment might be best viewed in the context of a shop that doesn't include QA and bug fixing as part of scheduled development time.  You could "release" to QA on time with a whole bunch of bugs that you can fix without impacting the original schedule, or you can release late, but have fewer bugs to fix.  The total time to develop and release a fairly bug free product would probably be shorter for the "get it right" group, but if the incentive is to release to QA on time...

Sorry, I'm a little off today.  I hope that made sense.

Malachi Brown
Tuesday, July 16, 2002

Some of this is a matter of interpretation and semantics.

One viable development methodology is to get to "working" code as rapidly as possible, then iterate over the working model until it works "well enough".  The actual definitions of "working" and "well enough" are, of course, flexible and depend on the project in question.  One can view this as "not taking the time to do it right the first time", since the iteration invariably involves fixing bugs.  However, I view it as figuring out what "the right way" is by using an actual working model.

As for measuring by number of bugs fixed, my credo for a long time has been: "Either you're making bugs, or fixing bugs.  Often, you're doing both."   

James Montebello
Tuesday, July 16, 2002

So what is that fixing bugs about? Is that fixing bugs in the code? Or the design? Or the concept?

Getting to working code quickly is oke if you have first plotted a course. Too often the first bit of working code is just a wild stab in the dark. After that, there is no way of getting from the office buidling that you created, to the country house that you should have...

Erik van Linstee
Wednesday, July 17, 2002

I think that was my point.  The very idea that "fixing bugs" should be a measurable goal is insufficient, since the very idea of "fixing bugs" is itself too vague.

All too often, a task will be roughly defined, only to have major parameters change after the work has started.  These changes are either driven by outside forces (the marketeers didn't understand the problem), or inside forces (the engineers didn't understand the problem).  Frequently, no one realizes the disconnect until after something is working and everyone can see it.

Essentially, the problem is deciding what's "right" when you want to take the time to "do it right".  If you spend a lot of time designing and building an excellent solution that ultimately doesn't meet the needs of the market, the product fails.  Since no one has yet invented the perfect communication mechanism, yet, one proven way to get past that is prototyping, testing, and iteration.

So, yes, make a reasonably guided blind stab in the dark and go with it.  Iterate until all goals are met.  This may not be the ideal way, but it's a proven, effective way.  To me, any way that results in a working solution is the "right" way.

James Montebello
Wednesday, July 17, 2002

Fixing bugs is the wrong thing to measure. What you should be measuring is remaining bugs.

In other words: you don't care how many bugs have been fixed, you care how many are left.

Of course, this presupposes you've got someone (QA, Customers) actively finding and logging bugs.

Andrew Reid
Wednesday, July 17, 2002

James Montebello wrote:
"So, yes, make a reasonably guided blind stab in the dark and go with it. Iterate until all goals are met. This may not be the ideal way, but it's a proven, effective way. To me, any way that results in a working solution is the "right" way."

So I respond:
But then your point is also that it is not a blind stab in the dark, but but a reasonably guided 'something else' :-)
And there are reliable ways to get to reasonably guided, so that you can avoid stabbing. And yes, building something (like a prototype) is is one of them, but not the first, because you have to have some sense of where you're going first.
Studying the subject and subjects (users, machinery, or whatever else is involved), asking stakeholders (users, service people, sponsors,...), drawing storyboards, are all much cheaper than and easier to accomplish under most circumstances than is having programmers program.

Erik van Linstee
Thursday, July 18, 2002

Andrew Reid wrote:
"Fixing bugs is the wrong thing to measure. What you should be measuring is remaining bugs."

Remaining bugs, I say? Are those the ones you found, or the ones you didn't find but are still there regardless?

So what does remaining bugs tell you then? That once remaining bugs drop, your skill at finding them is going? Or that there are less to find?

At least bugs fixed tells you something about the rate at which your fixing bugs so you can decide to add people who can fix bugs.

But remaining bugs by itself does not tell me anything. Should I add more people when the remaining bugs count goes down?

Erik van Linstee
Thursday, July 18, 2002

I think rather than measuring how fast bugs are being fixed, or how many are remaining, a better thing to measure (if you have to measure something) is the percent of test cases passed.

This does several things:
- it forces you to write test cases up front.
- It gives you an easy way to measure your projects progress (i.e. velocity)
- You can tell when you're done (all the test cases pass)

I think Boeing used this technique for the 777 control software.

Tom Haviland
Thursday, July 18, 2002

>>Remaining bugs, I say? Are those
>>the ones you found, or the ones you
>>didn't find but are still there regardless?

Well, by definition, you can't measure unfound bugs :)

>>So what does remaining bugs tell you then?

How close you are to a shippable product.

Andrew Reid
Friday, July 19, 2002

What about just having the developers count the bugs as they code them?

Ooops!!!  Are we still pretending they come from some mystical source outside our control???  I'm sorry... I'll do better to keep in sync...

Joe AA.
Sunday, July 21, 2002

Andrew wrote in response to:

>>Remaining bugs, I say? Are those
>>the ones you found, or the ones you
>>didn't find but are still there regardless?

>Well, by definition, you can't measure unfound bugs :)

Well, that was my point.

>>So what does remaining bugs tell you then?

>How close you are to a shippable product.

But my point was, which you confirmed, that you can't measure remaining bugs, because there are always bugs that have not yet been discovered.

Of course you do keep track of the bugs you did find and use them as one of the criteria of when to ship, only not as a primary criterion.

Sadly enough, there are places where this soon turns out into an excuse for not testing or confirming bug reports. (A project down the hall of were  I am working is doing exactly that now they are under pressure to release :-(

Erik van Linstee
Monday, July 22, 2002

comes down to this:
motion .ne. progress

and btw, a related one -

change .ne. improvement

too many folks are fooled by appearance over substance and think when the "engines are roaring and the mud's flying" there must be a lot of good stuff getting done (take a look at swamp buggy races on espn sometime - loud as hell, wheels are spinning, crap's flying everywhere, but they don't really go that fast).

re: swamp buggy races?? - ok, it was a lousy late night on cable and I was channel surfing. hell, if people can race riding lawn mowers, why not swamp buggies? ;-)

anon
Tuesday, July 23, 2002

*  Recent Topics

*  Fog Creek Home