You are correct. It's possible. Very few PMs are willing to pay the cost for it, but it CAN be done.

Its sad that only one answer out of five states that it is OK to expect zero bugs. When did mediocrity become so acceptable?

@JustinOhms, I see it as an outgrowth of the defeatist ideology promoted by Kant, that there are "things beyond the realm of human knowledge," which we can never know about at all (and never mind the question of how did he know about them, then, to tell us this). Of course it is possible to have perfectly bug-free code.

The trick is what the "well defined parameters" are... If you want a program that runs a specific function on a specific machine, then sure, bug free is easily within the realm of possibility. If you want a program that can run on any computer anywhere... then there will be bugs. Not because the software is hard to write, but because I can't test every combination of hardware and software that exists, and sometimes, it's the hardware's fault.

While it may be possible to write bug-free systems using functional programming, it would be unreasonable of the project manager to expect no bugs from their employees with whatever constraints the project manager simultaneously gives those employees.

I'd be very worried about a PM who, when building something like aircraft control software, thought any bugs were acceptable. I'd also worry about a PM who demanded 100% bug-free at any cost on a kids' phone game. Context is everything. @Justin maybe only 20% of us work on stuff where bugs actually have major consequences?

In practice it's not possible to remove all bugs in a sufficiently complex system. Depending on how you define "bug" - even the test cases could have bugs that lead to them missing undesirable behavior. Aircrafts have bugs, rocket controllers, medical equipment, etc.

@JuliaHayward my point was one more exemplified by what Wildcard said. I would add that just because bugs may be permissible due to the nature of the product, IMO we should always be expecting bug free code. If you are not expecting bug free code you are logically expecting bugs in your code. A bug is a type of technical failure, even if only minor. Generally speaking if you expect to fail, you usually will.

And if you expect to not fail (without extreme cost which most businesses will not tolerate), then you're delusional, if your definition of fail == having bugs.

@JuliaHayward - you are kidding yourself i you think aircraft control software is bug-free. Google "bugs in aircraft control software".

This answer would be improved a lot by elaborating on how, exactly, "everything" can be tested to ensure the absence of bugs. As written, this answer might give people the idea that testing "everything" by hand "at least twice" is sufficient to ensure the absence of bugs, which is clearly an absurd notion.

Kilisi, when I assert that all software has bugs, I'm not advocating defeatism, or mediocrity (not your words). Perhaps we're "speaking past one another" when we're using the term "bug"? I'd be more than confident with the software you develop, probably happier than the general case. When I'm asserting that all software has bugs, I'm saying that all known bugs can and should be addressed. The assertion, though, is that because we're fallible people writing the code and tests, we can never completely prove that there are no unknowns. What are your thoughts on eliminating unknown bugs?

@DonBranson: It's technically possible to prevent unknown bugs by using formal verification methods. When used correctly, this proves the correctness of the software and means that no undefined behavior can occur. In practice, however, it really just shifts the burden to the formal specification that must first be created.

@DonBranson I have to agree with tonysdg - the process of making bug free software isn't easy - it requires a huge budget before the code is started, while it's being coded, and after coding is "complete" - i'd expect you spend way more on definition and testing than you do on the actual coding.

@DonBranson there are none if you define and understand the operating parameters completely and maintain properly. After that the only problems that should occur are not bugs, it's because the customer is operating outside the design scope or have issues with their hardware. I'm not a developer, my devs are very good. But in engineering terms if I design a switch to be used in a controlled dry environment, and then the customer tries to use it underwater or other failure in the controlled environment and it doesn't work properly, that's not a bug.

@tonysdg yes, it's not cheap, I don't cut corners :) an hours downtime for my biggest client could lose them several customers and perhaps $12000, if the timing was really bad it could be over $50000.

@tonysdg: Re shifting the burden: No kidding. Formal verification takes as input a program, and a machine readable, unambiguous, formal description of desired behavior. In other words, a program. So to write bug free code, you must first write bug free code.

This seems like a tautology. Define "no bugs" as "provably passing all the pre-defined specs" and then test to the specs. This is a very suitable methodology for critical systems - with real, possibly physical consequences for failure. With a cost - extra up-front effort, and a highly controlled environment, it should be possible to reduce risk from bugs hitting live infrastructure right down. About the best you can do, if you are feeling confident, is provide a guarantee and offer to cover customer costs (and hope any failures can be legally shown to be operating outside agreed parameters).

“I can't understand these other answers saying it's not possible” — I can’t find an answer to this question that actually says that. Are you thinking of the first comment?

@Kilisi you can define bugs away. How can you say your software has no bugs if you're not a developer? Maybe your developers just reworded the meaning of bug.

I'm a software tester for a large engineering firm and I couldn't disagree with @Kilisi more. Testings fundamental aim isn't to find issues but to reduce the risk of issues. This can be done by finding issues, however to find every possible issue according to the International Software Testing Qualifications Board (ISTQB) is impossible. testing is a continual process that aims to reduce risk of the system and only stops when the agreed level of risk is achieved. Therefore to ensure something is bug free is impossible and to get as close to bug free would require infinite testing.

What complete and utter nonsense.

@tonysdg formal verification is great, but it is unrealistic to think that it can just be applied to anything and it will magically deliver a bug free product.. there are practical limitations which usually require a decent amount of abstraction and compromises, except for few very specific applications

This smells like the answer of someone who doesn't really understand software (and - based on the comments - is drawing erroneous comparisons with other technical fields). And whose employees recognise this and are working around the problem by essentially lying about producing no bugs. "There are none if you define and understand the operating parameters completely" - this is essentially an impossible scenario in nearly all software environments.

@AntP I beg to differ, I'm not a moron... if you find it impossible not to produce buggy rubbish, don't project that on my team.

The phrase "cloud cuckoo land" comes to mind.

Yes, it does :)

I agree with Ant P when it comes to completely defining operating parameters. Imagine that I ask you for a program to multiply two numbers. Simple one. So you use a program that handle most cases such as big number size, arbitrary precision and whatnot. But then I test it on complex numbers, and notice they are not properly handled. This is a bug. It stems from a specification loophole, but it truely is one, since in this scenario, the program does not multiply. So unless you use pure source code translation as specification, there will be bugs.