How to make a program bug-free (or, with the less possible bugs)

Question

OK, I know it's a stupid question to ask, so let me clarify.

My boss thinks that, "by now, with your level of knowledge, you should never have bugs in your software anymore". While it may be correct, given the correct set of tools and with a proper method, those are never allowed to me, maybe because I don't know what to answer him exactly (I'm the only developer here, so I don't have anyone to turn to when it happens).

So, here is my question : what tools and methods do you use to have the less possible bugs in your software ?

---

Bottom line : a code without any error is impossible. However, here is what is possible to do :

Testing

• Test-driven development
• Unit testing
• Automated testing
• Functionnality testing
• Mutation testing
• Test by a team and bypassers

Tools

• Source control
• Good editor / IDE
• Bugtracking software
• Static code analysis

Practices, management, environment

• Code coverage
• Peer code review
• Assertions to check assumptions
• Continuous integration
• Development stages
• No distractions while working
• Time

Answer 1

Test Driven Development is a good start, but it's not enough. Good practices, pair code review and programming, a high level of attention and the collaboration of a good tester can improve the bug control effectively.

But I think that "error free software" pertains to science fiction...

Answer 2

Unit testing! Its not a silver bullit but it saves a lot of debuigging time.

Answer 3

You really need to get it into your boss's head that it's virtually impossible to write software of any complexity without bugs.

As soon as you accept that writing bug-free code is an impossible task, you can start focussing on what's actually important: making all your bugs easily detectable

Unit testing is a great way to do that, and there are lots of little tricks that you'll pick up over time that will help you avoid them, although really that only comes with experience, and knowing what kinds of errors you are likely to make.

An often-cited (and probably now-irrelevant) example is to reverse the order of your comparisons, eg:

"bar" == foo

rather than

foo == "bar"

so you don't end up doing an assignment (foo = "bar") when you mean to perform a comparison (foo == "bar"). If you reverse the order, then the error case ("bar" = foo) is an easily-detectable syntax error, rather than a much-harder-to-find logic error. But that's really only useful if that's the kind of error you make regularly.

Answer 4

Perhaps your boss is not familiar with human error. That being said, using practices like unit testing, continuous integration, and static code analysis can improve your code quality and reduce certain types of bugs.

Answer 5

A few ideas:

1. Make a practice of writing unit tests. This has saved my life (not literally) a number of times.
2. Use Source Control
3. Use a code coverage tool - for example, in Java I use Emma or Cobertura
4. Use a continuous integration build tool such as Cruise Control
5. Use assertions to check your assumptions. The Pragmatic Programmer (book) goes into this in more detail. In fact it's a book I'd highly recommend reading.
6. Functionality tests - for example, in Java you could look into jFeature

I would like to reenforce what other people have said about writing error-free code -- it's impossible. However using some or all of the techniques above should at least help cut down your bugs.

Obviously, and maybe even most importantly, you should have someone testing your software (i.e. not just automated tests) before it gets deployed / shipped.

Answer 6

I don't think bugfree is possible unless the application is very small.

I do think that you can, and must try to, limit the amount of bugs in your software through rigorous testing.

Answer 7

I think "by now, with your level of knowledge, you should never have bugs in your software anymore" is not posible.

But you can use a TDD ( Test Driven Developent ) in yours project, for minimalize bugs in release versions. But this is not a total-solution. some bugs are very complicated and can be caused by update of 3rd party component or whatever else.

Answer 8

JUnit (or some other unit-test program) is useful when you have clear requirements to test for, and for preventing regressions. When the tests are automated and run frequently you can be assured that your changes are not breaking other parts of the system. It's also helpful when designing tricky classes because you can plan out all (well, many) edge cases you want to test and test them all together.

The key points are

• Automated Tests
• Run tests frequently
• Make sure test cases cover the known requirements
• create test cases when you find bugs; these tests fail until the bug is fixed

Answer 9

First of all: Bug-free software is a myth!

Second, the tools themselves depend on a lot of things, but if you want to keep things as general as possible:

• A good editor
• A good version control system
• Proper development stages (functional design, technical design, etc.)
• A proper test-team
• An improper test-team (basically the milkman, the cleaning lady and the bus driver you brought in... people who have no idea what they're doing if it comes to computers and interfaces)
• A way to indicate that you want no distractions whatsoever
• The time to be able to resolve issues when you get stuck on them

Answer 10

I sympathize with both you and your boss. I think it is remarkable that, in this day and age, to make software "perfect" would be so expensive that nobody would want to pay for it. In the end, customers accept the level of bugginess that makes software affordable.

I'll contribute a simple piece of "method". It's the idea of a zero-defect milestone. It's very common in software projects to talk about milestones that represent significant points in the project's timeline. In most cases I've seen, people say they've hit a milestone at the point where they've finished typing in the code for the features in that milestone. In reality of course, this gives you no idea of progress towards completion.

The zero-defect milestone doesn't attempt to have zero defects. Rather, it means that you don't declare that you've reached a milestone until you've done some testing and have a certain level of confidence that you know what all your bugs are. You may choose to fix some before declaring the milestone, or you may not, but at least you know what they are. You determine how much testing to do, and which bugs are acceptable, but those things are agreed in advance.

This kind of milestone is a far better measure of how far you've progressed towards completion, but it's surprising how rarely you see projects managed in this way. I recommend it.

Answer 11

What kind of defects do you have in your software?

Out of bounds errors? Reading non-initialized variables? Dereferencing invalid pointers? Those can be detected by a static analysis tool.

Incomplete understanding of requirements? Here test driven development and a review culture helps.

Design problems? Again, reviews are a big help.

Using out-of-date code? That calls for version control.

And: keep a defect log, so you know what kind of defects you make.

Answer 12

I have been successful with the "release early, release often" pattern in which you select less features at a time and you extensively test those feature before you include them in a release. Features that don't meet the quality criteria are not included in the iteration.

Obviously, this doesn't work alone and you need to have good development practices like the ones mentioned by Phil, Manrico, Twan and others...

Answer 13

Everything as bove regarding best practices, good dev process + TTD, BUT use also ... Mutational testing - very cool tool to measure unit tests quality! http://nester.sourceforge.net/

Good luck.

/Ievgenii

Answer 14

Bug-free software is a myth. For comparison, when your boss says that you shouldn't have bugs in your software now, that's like telling a mathematician that they should have figured out the precise decimal value of π by now, or found all the prime numbers. Bug-free software is a target that you approach, not a goal that you achieve.

This is not to say that we aren't culpable for bugs in our software, or that skilled developers won't have a lesser incidence of bugs. But your boss needs to have realistic expectations of your abilities. There are no perfect drivers, no perfect managers, and no perfect programmers.

Answer 15

cosmo0, I'm sorry, but I feel pity for you.

To me, your boss thinking that you must write bug-free code is the same as you thinking that you must have an infinite salary. Adding the word "almost" to that "bug-free" doesn't change the meaning at all.

There is bug-free code. The code that has 0 functionality is bug free. But it is useless.

Writing computer programs is very similar to playing chess. Tigran Petrosian, a world chess champion known for his strong defence skills, was once asked by a not very polite journalist why he makes blunders sometimes. The answer was surprisingly simple: "Because playing chess is not easy. Try playing yourself and you'll see."

Of course, I would advice to use this example as justification only if your boss is a smart person and will get it right. Otherwise it might be better to look for another job.

Answer 16

It is stupid from the ground up and not limited to programming. Just a few counterexamples. Most of us have their drivers licence for ages and so they should never be involved into just on accident any more. How real is that?

Another example, it should never happen that screws should break under "normal" conditions, but they still do. The may be overloaded, or they may start to rust or someone may think it's good idea to use a worse quality. And guess what you don't see that, you can must say with some high probability that a charge of screws is ok, but you can not test them exhaustivly. There can be weak places in it, hell it could be that air is included which you hardly can's see while not x-raying them. And so it goes on over and over again, if that attitude would be just a bit sound, we'd live in a totally different world....

Answer 17

Can your boss give you error free and complete specifications which don't change from the minute he completes them to the minute you finish the software? When I say complete, I don't just mean a list of features. How about all the interactions between all the features, all the expections of behaviour for every possible user input, every possible condition of the environment (eg OS, files present, other applications running, access to shared resources, font size, colour schemes, keyboard layouts), which processes take priority over others, timing to the millisecond etc.