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.

  • 5
    I would replace "requirements" by "user needs" or "expected behaviour" since even requirements may be wrong.
    – mouviciel
    Commented Oct 12, 2010 at 13:13
  • That the requirements are wrong? (and the code right?)
    – user1249
    Commented Oct 28, 2010 at 19:08

17 Answers 17


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.

  • If I could only get that darn mind-reader module to work, all would be fine.
    – HLGEM
    Commented Oct 12, 2010 at 17:58
  • @Gamecat: and it gets even worse when working with people all over the world. Not only there is a language barrier (often times at least one of the participant is not that proficient in English) but there are also cultural differences. Commented Oct 12, 2010 at 19:17
  • 2
    You missed one--"the programmer's interpretation differs from the compiler's interpretation"... ;) Commented Oct 20, 2010 at 16:55
  • @Alex: I know what the compiler will do with the code I write. That knowledge wasn't real easy to acquire, but I did it. Now, we have my interpretation of the code I didn't write, as opposed to the compiler's and the runtime data. Commented Oct 28, 2010 at 19:16
  • @David, unless you wrote and maintain the compiler, your knowledge of what the innards are doing is an abstraction of what's actually going on--and that's probably for the best, as it allows you to spend brainspace on the actual application. Commented Oct 29, 2010 at 12:53

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)

  • don't think that's the primary issue, most of devs work in quiet conditions. I agree with AnonJr and Gamecat - inability to fully understand problem domain, only quick iterations and testing can help.
    – radekg
    Commented Sep 20, 2010 at 13:20
  • 1
    How come most of devs work in quiet conditions ? In dozen companies I've visited over the last year, none was quiet at all.
    – user2567
    Commented Sep 20, 2010 at 13:35
  • Good management can take you far, bad management can take you no where!
    – Chris
    Commented Oct 12, 2010 at 16:51
  • +1 regarding quiet working conditions. Every company I've ever worked at has been a Dilbertesque cubicle farm where you can constantly hear people 4 feet from you clipping their fingernails, munching their food, and taking phone calls. Commented Oct 28, 2010 at 19:12

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.

  • Four months into a new job, I am still only a small % into "fully understanding" anything. I am not going to rush; what you say is true. Sucks to be unproductive such a long time, though.
    – DarenW
    Commented Oct 28, 2010 at 18:13
  • It took me a year or two to get up to full speed on the system I work on (2 million line system). Even then there are large segments of it that I simply don't know. Commented Oct 28, 2010 at 18:58

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.