The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Bug vs Flaw

What is the difference betwen Bug and Flaw?

Tuesday, May 31, 2005
 
 
If I were pinned down to define them:

A bug is an error in the code.  Whether it is a bug if it has no observable behaviors will be left to the code philosophers.

A flaw is any defect in the program.  It could be a bug, it could be that the program addresses the wrong problem, it could be a typo, it would be bad workflow in the program, etc...

In short, as I've heard these terms used, a bug is a code specific subset of a flaw.
Lance Send private email
Tuesday, May 31, 2005
 
 
I think a flaw is something that the programmers meant to be there that shouldn't be.

Something that the users will think is a bug but the programmers won't.
Colm O'Connor Send private email
Tuesday, May 31, 2005
 
 
A bug is something that simply does not work as desired.

When someone says "flaw", I tend to think of it in more architectural terms than a bug.  A flaw would be like "Does not support a granular permissions system."

A bug is easily fixable... well, relatively so.  A flaw means some major rethinking/re-work of some part of the system.
KC Send private email
Tuesday, May 31, 2005
 
 
The usage of the word "flaw" or "defect" as opposed to "bug", in my cynical experience, has simply been a rebranding exercise. Sort of like political correctness. Flaw or defect are more smarter sounding words and, well, they're not bugs.

In a few years, defect and flaw will carry enough negative baggage that the cycle will need to start again. We'll have new terms like "expectation misalignment" or "specification conflict".

Of course, it is possible that some places make a distinction between flaw, defect and bug. YMMV.
Joel Goodwin Send private email
Tuesday, May 31, 2005
 
 
A BUG is a fault in the code that causes a repeatable and erroneous condition.

A FLAW is the same as above but you couldn't find it in time before shipping. The documentation is changed to reflect the condition and relabeled a FEATURE.
Johnny Moondog
Tuesday, May 31, 2005
 
 
Nothing. Call everything a bug and just embrace the word. Even enhancements are a bug because the product doesn't do what the customer wants. Othwerwise more time is wasted pissing over how to assign blame than getting workd done.
son of parnas
Tuesday, May 31, 2005
 
 
Here is our definition of Bug vs. Error/Flaw. This comes from our contracts. We commit to fixing all Errors/Flaws. We do not commit to fixing all Bugs (although we typically do anyway).

"Error shall mean incorrect results by or failure of the Software to perform a material function described in the software specifications in an environment for which it was designed, and which Error can be reproduced at XXX’s facilities."

"Bug is a minor problem with the Software which can be easily avoided or circumvented."

Tuesday, May 31, 2005
 
 
I should also state that Errors/Flaws can stop payment of a contract. Bugs cannot. This is the main reason for the distinction. It gives you an out for those pesky customers who are constantly looking for a reason not to pay you. As long as you deliver what you committed to in the specifications, you should get paid.

Tuesday, May 31, 2005
 
 
Oh, I LOVE 'no-name's definitions.  Since software cannot be proved to not have bugs, his contracts allows bugs to continue to exist without violating the contract.  Brilliant.  This means you don't HAVE to prove there are no bugs before you can deliver.  And get paid.

And he defines bugs as some problem with the code that can be worked-around.  If there is not work-around, THEN it's a Flaw or Error and contractually must be fixed.

I like this a lot.  This balances the risk the developer must take (to produce code that works) with the risk the customer takes (to accept that the code works, and pay the developer, even though there may be minor bugs).
AllanL5
Tuesday, May 31, 2005
 
 
AllanL5...

There will always be bugs. And we will do our best to fix them. But there are customers who will use the presence of bugs to keep from ever paying you. They will have your software rolled out to all of their locations and be using it every day as a core part of their business but will claim they can't pay you until ALL bugs are fixed. And then they hand you a list of totally trivial things that they call bugs (many of them completely debatable). You need to draw a line in the sand about what has been promised. We promise to create software free from errors. We couldn't possibly promise to create bug free software.

It is not a loophole to allow programmers to be sloppy. After all, it is the way you respond to the actual BUGS that define you as a company. Even though we don't commit to having bug free software we still fix all bugs that are fixable. We just can't commit to doing so before getting paid for the core software. Otherwise, we would be out of business.

Given that most responses here have been geared toward the "bugs and flaws are the same thing" mentality, I would say that most of the respondants so far have not had to deal with the contractual side of the software business.

Tuesday, May 31, 2005
 
 
Dear Blankety Blank, the definition you have put forward with respect to your business model makes a lot of sense.

I have participated in the contractual side. I would still be concerned that such a contract could lead to Jerry Springer style bug vs flaw debates with your clients. But then again, it sounds like you've got it sorted. We probably inhabit different contractual worlds - I lived in bespoke T&M on top of core product license.

However, considering that it is difficult for two people to agree on what a bug is in the first place, my response for the OP still holds. Although there are places that define bugs and flaws to be different, whether they be subsets, intersections, unions or kissing cousins of each other, there is no universally accepted definition of a "flaw" distinct from a "bug".
Joel Goodwin Send private email
Tuesday, May 31, 2005
 
 
Dear no-name: I was definitely NOT being sarcastic.  I really do think his 'bug' versus 'Flaw/Error' definitions were brilliant.

I've dealt with several software systems (the Big Dig system in Boston, which manages the new Tunnel being one) where convincing the customer that you had "done enough" to get paid was a major issue.

In fact, the software developer is usually the one who gets blamed if the software doesn't do everything the customer WANTS it to do, never mind what the customer signed saying what the software SHOULD do.

So having this very nice distinction to cover both the developer and the customer was nice to have.  I may use it in the future myself, if I can get a customer to agree to it.
AllanL5
Tuesday, May 31, 2005
 
 
Joel, I agree. We actually side with the customer almost every time when it comes to these types of debates. We care about customer satisfaction and about software quality. The contract is simply there for the few times when you get someone who wants to try and weasel out of paying for something that you truly deserve to be paid for. That's what contracts are all about anyway. ;)

I also didn't include information about many other aspects of our contracts that are meant to protect the customer (warranty periods, customer acceptance phase, third party bugs, maintenance agreements, etc.). I simply wanted to let the OP know that there are some people who do distinguish between different types of software defects. Many of the others here probably claim that all bugs are created equal because they are doing in-house programming or dealing with shrink wrapped software. Our software is highly customized and can run anywhere from 20k to several million dollars. In these cases, many companies find it advantageous to create specific clauses to address the different types of software defects that may arise.

Sorry for remaining a "no name" for so long. From here on out I shall be known as "squidward".
squidward
Tuesday, May 31, 2005
 
 
If it's software I wrote, it's just a little ol' bug.  If it's software someone else wrote, it's a defect.
Kyralessa Send private email
Tuesday, May 31, 2005
 
 
A flaw is what you stand on. Actually, so is a bug, but they go *crunch* *squish*, and that's the difference.

Wednesday, June 08, 2005
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz