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

no bugs

Well something weird happened at work, for the first time I actually managed to deliver a full working feature ( around 500 LOC) with no bugs found yet by QA. The feature was unit tested, before sending off to QA. I myself am rather shocked that no bugs were found.
Have other software developers managed to perfect the art of delivering bug free features?
anon for now
Saturday, October 01, 2005
If you unit test and you have acceptance tests, should you have bugs?
son of parnas
Saturday, October 01, 2005
son of parnas:

It all depends on how good your unit and acceptance tests are. 

OP: My bug counts are always low when I've spent the time to design really thorough unit and integration tests.  I have had zero defect counts before but that is also a function of how good the QA process is.  If my code and testing sucks then I could still get a zero defect count  if the QA process is weak.

Ideally, testing and QA should be just as important to developers and organizations as the code itself.  Unfortunately, the real world is far from ideal.
Saturday, October 01, 2005
"Have other software developers managed to perfect the art of delivering bug free features? "

Or perfected the art of over confidence and ego maniacal arrogance?

There is no such thing as bug-free software. Your QA group is not doing a good job.
Master of the Obvious
Saturday, October 01, 2005
Bug free is bug free.  If it meets the design criteria, passes unit tests, works when integrated, passes the larger product tests - then you are truly bug free.  Congradualtinos.

Not many things are as satisfying as doing the job right - especially the first time.

Some people never get the satisfaction of the doing the job right - even the N, N+1m N+2, ... time.

And then there are people who claim there is no such thing as bug free software. Its merely a pathetic excuse for writing really f---d up software.
hoser Send private email
Saturday, October 01, 2005
If you really got the things out bug free, then congratulations. It's definitely the Holy Grail.

I've been there only once, but it was very sweet. We also busted our asses to get it that way, though...
QADude Send private email
Saturday, October 01, 2005
No offense but 500 LOC is a piddley little program. The smaller the program the higher the probability of delivering without any bugs.

But kudos for doing a good job. Hopefully it is a sign that you are indeed a good programmer. Unfortunately, I know programmers who can't deliver a program with 1 LOC without bugs. ;)
Saturday, October 01, 2005
Software is written by humans. We _are all_ inherently fallible. We use engineering discipline to eliminate defects we anticipate, and minimize the damage of defects we don't. If you believe you can write defect-free code, you're deluding youself and exposing your users to potential dangers.

"If it meets the design criteria..."
The design may be defective, in which case your software is defective, even if you can't find any bugs.

"...passes unit tests..."
Passing unit tests does not confirm the absense of defects. Even if you achieve 100% code coverage. It's the Maxim of Uncertainty in Software Engineering -- MUSE.

" when integrated..."
Integration only increases the possibility of defects. Your potential defect domain now includes the domains of the program(s) with which you're integrating. You're suggesting you can test all possible inputs?

"...passes the larger product tests..."
Just increasing your potential for defects even more...

Zero-defects is a worth while goal, but you'll never get there (like absolute zero). At some point, you have to stop testing/developing and ship software. Reliability models give us a level of confidence that we've done the best we can, but we'll never find every defect.

If you have truly written bug-free code then your program is either trivial, or you've spent so much time writing it, it's cost you billions of dollars.
Master of the Obvious
Saturday, October 01, 2005
"Have other software developers managed to perfect the art of delivering bug free features?"

Yes.  I did it once.  I can't remember exactly what I was doing but it was a huge chunk of code doing something complicated and poof it worked perfectly out of the gate.  I was pretty amazed, which is why I remember it.  Of course, it's only ever happened like that once.

"No offense but 500 LOC is a piddley little program."

I believe he said 500 LOC for a single feature, not a whole program.  Adding something to an existing program is worse than creating one from scratch.
Almost H. Anonymous Send private email
Sunday, October 02, 2005
Some day I'll like to have a QA department around to test my code for bugs.
Sunday, October 02, 2005
I am willing to bet 100 USD to prove that this 500 LOC feature is /not/ bug free. Just send me the source.

If I can't find a bug within 24 hours, you get $100.

The whole concept of bugfree code is naive.
Comp. science guys have mathematically proven that the complexity of ensuring "mathematical" bugfree-ness goes up exponentiallyt with the LOC figure. AFAICR, it is, with current state-of-the art technology, impossible to ensure mathematical bugfree-ness of the typical/average 100 LOC piece of code.
Frank de Groot Send private email
Sunday, October 02, 2005
How can the OP and others here claim to have "perfect(ed) the art of delivering bug free features" when, by their own admission, they've only ever done this once (which is a dubious claim to begin with)? That's like having sex for the first time, achieving orgasm, and then claiming to have perfected the art of lovemaking. This hubris astounds me.

When someone does find a bug in their code, will they report it here? Will they even acknowledge the defect? "Oh, that can't be a bug in _my_ code. For I have perfected the art of bug free features. Go, lowly subordinate, and seek the cause of your defect elsewhere, for I am without flaw!"

Pride goes before the fall...
Master of the Obvious
Sunday, October 02, 2005
> Pride goes before the fall...

Before the fall was the trip over low standards.
son of parnas
Sunday, October 02, 2005
Look here guys All I am saying is that we should all strive to make our code as bug free as possible through whatever means - unit tests. acceptance tests, etc before sending off to QA. I am pretty sure the feature I am talking about has bugs, yet to be caught by QA.
Sp long it is good enough it will ship, but what is the definition of good enough?
anon for now
Sunday, October 02, 2005
There is a second side to this post that I find even more interesting. The ability to deliver quality software on the first try. I'm not talking about bug free. I'm talking about software that meets the criteria necessary to be shipped to the customer. Some programmers can and always do deliver quality code on the first try. Others can't seem to ever deliver quality code. The code is so bad that you have to send it back to them over and over. Each time they try to fix it, they end up breaking something else. It drives me absolutely insane to work with these people!
Sunday, October 02, 2005
anon for now: I agree with your latest post 100%. However, this is different than your original post where you claim to have perfected the art of delivering bug free features.

I'm sorry, but this (original) attitude always rubs me the wrong way; perhaps this wasn't your intent, but was how I perceived it. Your latest post is more even-tempered and less self indulgent. You're probably not a bad person, just keyed up over the perceived delivery of "bug-free" code.

As for the definition of "good enough"; IMO that's a business decision. Development engineers the code to be as fault tolerant as possible. QA verifies that the requirements have been met with minimal defects. The business people (should) weigh the risk of shipping the software with the known defects vs. the cost of those and other unknown defects being discovered "in the wild". QA can use tools like reliability models to assure the business people that they've done due diligence and have tested enough to mitigate the risk of shipping. Ideally, you have some customer representatives or proxies as stakeholders that will validate the product before shipping, so you know you not only built the thing right, you built the right thing.

As matt posted, the ability to do the process above and ship quality software the first time is what's truly amazing. This takes a well-oiled machine with Development, QA and the Business working in concert; great coders alone won't be able to do this, it's really a team game. If you're on such a team, consider yourself lucky. Unfortunately in our industry, that's far from the norm...
Master of the Obvious
Sunday, October 02, 2005
hoser Send private email
Sunday, October 02, 2005
bugfree software is an accident
A Nony Mouse
Sunday, October 02, 2005
As were you.
hoser Send private email
Sunday, October 02, 2005
Hey hoser,

Why don't you post some of your "bug free" code so we can learn from your superior intellect?
Master of the Obvious
Sunday, October 02, 2005
As for the original post, assuming QA is on top of their game, if they say it's bug free then for all intents and purposes it IS bug free.

But bug free isn't the issue. The issue is: is this code acceptable? Bug free is often overkill for most applications.
Sunday, October 02, 2005
I agree with Master, and those who said 500 LOC is a small 'feature', or 'deliverable'.  And with those who said delivering ONCE something that passes QA doesn't mean you've 'mastered' or 'perfected' anything.

It's a nice occurrence, but it does not change the nature of software engineering -- which is that first the entire process is fraught with communication 'noise', so people don't or can't ask for what they really want.

And second software complexity is in large part arbitrary -- we can relatively easily inject more complexity into a software product than any other thing created by man.  Verifying correctness of that construct can then be very difficult and costly and time-consuming.

But I do congratulate you on your delivery.  We do shoot for that goal.  It's that "Perfecting the method" comment that sets us off.
Sunday, October 02, 2005
before shipping they're bugs, after shipping they're "features"
Ben Bryant
Sunday, October 02, 2005
I've had bugs that were actual features.

I had a bug and the consequence of it was maybe what you could consider a feature.  Users had somehow figured it out on their own (I had no idea about it) and when the bug was fixed it elimated the 'feature'.  So after the release I get angry emails about how they want their feature back!
Almost H. Anonymous Send private email
Sunday, October 02, 2005
Software quality metrics overview:

Three-Mile Island - the reality of component failure and systems interacting in unusual ways:

A bug only uncovered after more 3 million operational hours (340 years!):
Mark Pearce
Monday, October 03, 2005
To claim to have mastered the art of "bug free" programming is hubris and quite possibly inviting disaster, but to state, "If I can't find a bug within 24 hours, you get $100." Now that is just pure f*cking arrogance. Bug free, absolutely 100% does-what-it-says-on-the-tin code does exist and is achievable. I can't remember ever managing it on the first attempt, but I have done it and it is always my aim in any project or part thereof.

Also, if "the spec is wrong", well that's a bit of a childish definition of a bug, isn't it? If the spec says build a small city car and that's what you make, when the customer decides that they really wanted a fifty foot long Hummer that's not a bug or an error on your part; you did as you were asked and fulfilled your part of the bargain. Pyschic abilities are not part of the job spec.
Paul Brown Send private email
Monday, October 03, 2005
Hole-in-one, nice shot.
A. Nonymous
Monday, October 03, 2005
See Chapter 2 of "Testing Computer Software" <>:

* You can't test a program completely
* You can't test the program's response to every possible input
* You can't test every path the program can take
* You can't find every design error (yes, an error in the spec is a bug, I'm not making this up)
* You can't prove programs correct using logic
* You can't verify that the program works correctly
Master of the Obvious
Tuesday, October 04, 2005
    print("Hello World");
    // .
    // .
    // Copy and paste this same line 500 times please
    // so that the program meets the 500 LOC criteria.
    // .
    // .
    print("Hello World.");

Amazing! It defies all laws of computer science! An actual program that has no bugs! It does exactly what the spec says it should! And on the first try no doubt... so where's my $100?
Tuesday, October 04, 2005

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

Other recent topics Other recent topics
Powered by FogBugz