I define defect as :
"something within the application design or code which prevents it functioning as per requirements."
I'm looking for ideas about the causes of defects, eg the human factor, lack of testing, lack of prototyping, and possible ideas to mitigate these.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
The prime cause of software defects is interpretation.
The customer interpretation of a feature differs from the designer interpretation.
The designer interpretation differs from the programmer interpretation.
Most methodologies have invented ways to counter this effect. But in the end, we are only humans and we are not flawless. Besides, often there is a time pressure and most methodology magic is often skipped while under pressure.
Testing can only detect the problems early. But even testers are human, and it is imposible to test 100%. If you want to release before the universe ends.
I consider the prime cause of software defects to be programmers.
Not saying that just to be funny, but because one of the big problems I've observed at my job is poor requirements gathering, coupled with poor understanding of the problem domain, causing major defects and usability issues in the project.
Part of that comes from not being willing to learn/understand the terminology of the end user, causing misunderstandings.
Part of that comes from talking tech too early in the process to people who don't have a clue what you are talking about or why it matters.
Best example of that was when I overheard one of the programmers trying to figure out how long the questions/answers were going to be in characters... I knew he was trying to figure out what size field to use in the database, but the department requesting this hadn't the foggiest why that mattered - or that spaces counted. To us that seems obvious, but to them it was a real revelation.
The primary cause of defects is bad management ;)
Seriously, a developer that works in good condition, that is not asked to overwork, to cut on quality, have proper tools, quiet working conditions and so on will produce less bugs than someone working under hard pressure.
Also management hiring bad developers also helps increasing the number of bugs.
Bad management.
(disclaimer: I'm supposed to hire & manage developers)
I don't see any one primary cause--but one cause that hasn't been mentioned is unintentional coupling with other code. Writing code that has invisible side-effects, breaks through abstraction layers, makes assumptions about data (variables won't, constants aren't, and no input from a user is safe), mucks with things that it doesn't need to concern itself with, and so forth.
Most of the development practices that I study boil down to reducing N, because the complexity of a program is at least O(N^2) and possibly O(k^N). Defining N is left as an exercise for the reader, but I'm thinking of things like cyclomatic complexity here. Encapsulating logic and data has the effect of reducing N by compartmentalizing the problem.
The inablity to think of everything.
Being incomplet
Communication gap. In requirements collection. In schedule. In design document. In functional specification. In code (gap between what programmer wants and what he tells the compiler).
Social etiquette. It is socially unacceptable to call someone incapable.
Rushing into things without fully understanding them. Starting to write code without fully understanding the functional requirements or the technical architecture.
Programming should be almost automatic, just writing down that which is self-evident and has been already worked out in the mind. In practice, I see a lot of flailing in code to try to get a handle on exactly what the code is supposed to do. I've been guilty of this myself many times.
Errare humanum est
Schedule Pressure is certianly a strong source.
Rushed developers don't take the time to fully specify the requirements, or fully understand the intent behind requirements, or fully investigate alternates to find the best solution, or fully think through all the edge cases and interactions of the changes they are making, or develop a full set of test cases, or fully perform all the unit test, or perform a full integration test, or fully consider platform dependencies, or fully test out the installer, or fully document what they've done so the next developer can understand....
Another thing which should be mentioned is not having an outsider test. When the developer writes the tests and runs them, he only tests his interpretation not the actual requirement. While unit test written by the devs are useful to catch some bugs, most bugs will have passed these tests but not be what the user wants or needs. Any software not tested by someone other than the developer is not tested (And I don't mean just running the developer's tests).
It's because software engineering is inherently complex. The essay "No Silver Bullet" discusses this.
Ironically, many of the other answers here touch on topics that are "accidentally complex", in the language of that essay, whereas in reality most of what software developers do is "essentially complex", so it's just in the nature of it that creating software is difficult, software will have bugs, and our job is to deal with it.
The failure to understand software as a network of state machines, the principles underlying their operation (states, their determination and transitions), and the interactions of the state machines.
Writing code that fails silently vs. code that reports all errors.
Lack of checking for things that "can't happen" or are unlikely to happen is a big one. Sometimes the perfect is the enemy of the good. If it's not worth a well-thought out exception hierarchy, some quick and dirty handling is always better than nothing. I'm a huge fan of failing fast, of asserts and of leaving asserts that have negligible impact on performance on in release builds. Even in quick and dirty one-off scripts where I control all input data, I put some quick/dirty error handling in, usually just with a function that is equivalent to assert but stays on all the time. My rule of thumb is that, if it's not likely to occur or you think it can't happen, it doesn't need to fail gracefully with a user-friendly error message, but it should at least fail fast with an error message that gives a programmer some hints about what went wrong.
Edit: One related useful tactic is to use asserts as a major debugging tool and leave them in there after the debugging session is over. From that point on, your codebase will have some builtin sanity checks that make it very hard for related bugs to ever happen again. This is especially useful for code that is hard to unittest.
The prime cause of software defects is writing code.
Write less code and you'll have fewer bugs ;-)
At one level, management. But it's not just the PHB. It's the management of the code itself, which may or may not be a reflection of the corporate management.
The participants in the entire "lifecycle" need to be fully invested in quality and making a product that just doesn't die. Software itself has the promise of never breaking, given the proper abstraction reliability. It is only a question of whether the software constructors are interested in having that perfect operation.
