Fog Creek Software
Discussion Board




Where do bugs come from?

In my earlier thread, Anon said:

"While writing software, one must pay careful attention to being able to maintain it later."

This is obviously true, but why?  Is there no market strategy that would allow you to be competitive, while at the same time being able to sell a product, shake hands, wish 'em well, and get onto the next thing?

Is this maintenance stuff a revenue generator?

Clearly, bugs are one of the big reasons software shops have to own the product in perpetuity, so my next question is "where do they come from?"  I mean what are some of the root causes.  Unclear requirements?  Sloppy programming?  Developers not familiar with problem domain?  Complexity?  Having to rush to get the thing out the door?  Something else?

When you think about it in the abstract, it seems like it should be a simple affair to produce bug free code, so where are they coming from?

I know a big source of bugs in my code is integration with third party libraries.  I call a function, it goes in, does its thing, and returns, but while its gone it does something secretive.  Later on, I get strange behavior and it takes a while to find the pattern that sets it off.  It turns out that the function call has side effects I am not aware of, or it has some bugs of its own.  In other words, it doesn't behave as expected - my assumptions were wrong.

So, where do your bugs come from?

nuttin' to read
Thursday, March 06, 2003

I guess for me it would be a lack of experience in certain libraries, unclear requirements and system complexity.

To answer your question, bugs are the direct results of programmer ineptitude. =)

Wei
Thursday, March 06, 2003

Human incompetence and incompleteness is the sole reason, IMHO. It is "the root of all evil".

Why do we fail exams by sloppy mistakes ? Why do we balance our finances incorrectly ? Why do we make mistakes at all ?

I believe that the answer to these questions will lead to the answer to your question.

Then I confronted the movie analogy in the last thread (that was me, sorry for the Anon) - maintenance came from a painful experience. We do mistakes, and we'll always do them. We can reduce them with competent techniques, helpful tools and languages, experience, but there will always be bugs. The sky is blue. Facts of life

Eli Bendersky
Thursday, March 06, 2003

If debugging is the process of taking bugs out, then programming must surely be the process of putting them in! Next question? ;-)

John Topley
Thursday, March 06, 2003

hahaha... i never saw it that way... =)

i'd always tot of writing software as creating functionality for a computer... =)

Wei
Thursday, March 06, 2003

Before we can answer the question "Where do bugs come from?", we must answer the question "What are bugs?"

Sure, we all have some kind of understanding of what a bug is, but the exact definition of a bug is kind of fuzzy. We can probably point out a handful of slightly distinct bug definitions (if we're lucky).

So I'll have to ask: WHat makes a bug a bug?

Martin
Thursday, March 06, 2003

What makes a bug a bug?  What makes a weed a weed?

Undesirable behaviour in the wrong place at an inopportune time in front of the wrong audience.

Much like taking a toddler to Sainsbury's

Debugging toddlers takes time and patience and attention at the time of the bug.  Similarly with software.

Simon Lucy
Thursday, March 06, 2003

What makes a bug a bug? Good question.

My view is that a bug is a flaw that results in a piece of software failing to behave as originally specified (or substitute 'intended' if you prefer).

Clearly this implies that software can also exhibit design/specification flaws, i.e. the software functions as specified, but the specification itself was incomplete or inaccurate. I wouldn't, for example, haul a programmer over the coals for selecting an inappropriate sort routine if the specification doesn't indicate how many records are likely to be encountered. I would, however, give a designer a hard time for not asking the question, or worse for accepting a test data set having a few hundred records when the live system will process millions!

David Roper
Thursday, March 06, 2003

It's also noticeable that toddlers exhibit heisenbugs that you think you've fixed only to recur again when they're 16!

David Roper
Thursday, March 06, 2003

I thought Turing once produced a mathematical proof that it was impossible to turn out a bug free program.

Bugs are an inevitable result of the complexity of the system. Their number can be greatly increased by sloppy design, poor integration, having to work in a hurry, or having programmers that don't understand the underlying concepts of what they are doing, but they will always be there.

Rigorous testing will get rid of many of the most common ones, but new ones will always turn up because your program has to work with other programs that weren't even in existence when you did the testing.

Stephen Jones
Thursday, March 06, 2003

When I change something in the program, or add something, I test it and make sure it works. However, I don't test it under all possible conditions because I can't predict them. I don't even try because it's impossible. After the program is used for a while I will eventually hear about the bugs and fix them.

The Real PC
Thursday, March 06, 2003

"However, I don't test it under all possible conditions because I can't predict them. I don't even try because it's impossible"

But, it is not nearly as unpredictable or impossible as some would have you believe.

More often it is not economical, or desirable, rather than impossible.

Always a good step is to at least define under which circumstances something will work, or is supposed to work, and then restrict usage to those circumstances.
In other words, validate input and fail gracefully in the presence of errors. It'll get you a long way.
That'll still leave you with the honest mistakes, of course...

Practical Geezer
Thursday, March 06, 2003

"Undesirable behaviour in the wrong place at an inopportune time in front of the wrong audience."

I like that definition. Here's why.
Take this simple program:

echo "Hello, world!"

This simple program is bug-free, right?
Wrong!

Tell a blind user that he'll get a message when he runs it, and when he does, he'll report that it has a bug because he didn't get any message - he's the "wrong audience".

Or run it on a computer with no visual output devices attached. No message? It's a bug! This particular computer is the "wrong place".

I'll leave it up to the reader to create an example with "inoppertune time".

Bottom line is: Bug free programs do not make any sense! It's the whole setup; user, hardware, place, time, _and_ of course the program, it is in this whole context that bugs are emerging.
Granted, often there's something wrong with the program involved, but since non-program factors can introduce bugs, it isn't enough to buy some cool debugging tool and a good programmer (although it certainly helps!) - we have to have a holistic view of the setup, not just the source code.

That's how we nail the bug! Or maybe that's why we'll never nail all the bugs?

Martin
Thursday, March 06, 2003

> I thought Turing once produced a mathematical proof
> that it was impossible to turn out a bug free program.

The only Turing related theory I can recollect from computing theory lectures was the halting problem.  It is impossible to write a program that can decide if an _arbitrary_ other program will halt in a finite amount of time (given a particular input)

A lot of other problems can be mapped onto the halting problem.

Anon
Thursday, March 06, 2003

Martin, umm yes that's exactly the kind of thing I meant.

Simon Lucy
Thursday, March 06, 2003

Bugs come from lines of code. With careful programming, you can reduce the number of bugs per line of code, but nothing beats not writing the line of code in the first place. That is why we should always try to avoid writing code to solve problems that only live in the mind of the programmer.

Big B
Thursday, March 06, 2003

Nuttin said, "Is there no market strategy that would allow you to be competitive, while at the same time being able to sell a product, shake hands, wish 'em well, and get onto the next thing?

Is this maintenance stuff a revenue generator?"

Nuttin -- I don't think I've ever worked on a project when the client didn't request changes after install, whether one week or one year later.

Sure you can never turn back and "get onto the next thing".  But if you ignore clients whose needs change and who need increased or modified functionality from your apps, they're going to be unhappy with you even if they liked the app to begin with.

And if you don't design your app to be easily maintainable and modifiable, it's going to be a nightmare when you go to modify or extend it later.

So I would say that, sure, you can "shake hands and wish them well" if you want.  But in the end, you're not going to have any happy clients.  Applications usually need to grow and change over time.  And you're not going to be competitive if people think you've abandoned them.  In some cases I bet they'd even have to scrap your application -- even if it worked fairly well -- and replace it with a new one, because having another consultant modify your unfamiliar app is more difficult for them than building a new one from scratch.  Especially if your app isn't built to be friendly to modifications.

Herbert Sitz
Thursday, March 06, 2003

Well, just to provide a point, the computer games industry is an example of one where you can mostly ignore maintenence. Most games are released and only followed up by a year or so of patching the worst bugs (there are exceptions, but I did say most). This example isn't really relavent to the rest of the industry, but the original poster did say something like "are there any products where you just make the sale and say goodbye".

On the second question of bugs. I'd have to agree with the sentiment that humans just aren't perfect. This can be compensated for by checking, then checking again, and again, and again, etc. And there are some software projects that do this and achieve very near bug free code (the space shuttle software team is often given as an example).

So why don't we just do this on all projects? Simple economics. How much are you prepared to spend to get bug free code? Every project has to answer this.

Bill Tomlinson
Thursday, March 06, 2003

>> "Well, just to provide a point, the computer games industry is an example of one where you can mostly ignore maintenence. Most games are released and only followed up by a year or so of patching the worst bugs (there are exceptions, but I did say most)."

MMOG's are an example of a game that is patched consistently.  Then again their users have some strange ideas of what bugs are.  Like, "I'm not advancing at a fast enough rate, make it easier?".  I love game bugs actually.  L33T UBER SP|_O1Tz.

Ping
Thursday, March 06, 2003

halting problem is not indiciative of bugs, because all bugs are not halts.  You can map some, but not all, bugs to the halting problem.

Bugfixing *can* be profitable if you arange your finances right.  For "Shrinkwrap" software, it's not because you have to do a feature upgrade before a good chunk of your users will pay for anything.

If you sell software as a service, which is what some folks would *love* to do, bugfixing keeps the users satisfied.

Stability-intensive and/or reputation-intensive industries are also cases where bugfixing is profitable.

Multiple products that share code will have areas of code that it will be profitable to bugfix.

There's more here, but it would be an epic.

flamebait sr.
Thursday, March 06, 2003

As a wise program once said:
"Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work."

Nick Grimshaw
Friday, March 07, 2003

There are no bugs.

There are programmer errors and unmet requirements.

UpAndDownTheCityRoad
Friday, March 07, 2003

There is only one definition of bugs that I can think of that is objective and non-vague:

"A bug is a deviation in the code from specification".

Deviations tend to be bad.

Of course this assumes that the specification is 100% complete, and that the specification has no bugs in it (bad design decisions, incorrect assumptions).

I don't think it is possible to specify non-trivial programs in such a way that the code implementation is deterministic. So the spec is always incomplete, as it would take longer to spec out a program than the rest of its lifecycle put together.

So the code produced to serve the requirements accretes a lot of design decisions during implementation, based on best judgement of the designers. Convention goes into it a lot too.

With vagueness in what is a bug, it will not be possible to make 100% bug free code.

Richard
Thursday, March 13, 2003

The largest percentage of bugs (90% or so) come from incorrect or incomplete requirements.  Programmers introduce a very  small percentage in the process of coding.  I am an analyst by the way, but I used to be a programmer.  Spend more (enough)  time in analysis and you will have a lot fewer bugs!  Requirements review is very important, because it is 10 times less expensive to fix a bug in analysis than it is in testing/implementation.
Been there, done that, Jim

Jim Hert
Thursday, April 29, 2004

*  Recent Topics

*  Fog Creek Home