Software Engineering Principles

Strive to have peer, rather than a customer, find a defect (25)

 

Explanation

"... a defect found early, or before a customer finds it, has value. To the producer, the value lies in a higher quality product that will have a better reputation, or, when the defect is found early the cost to fix it is substantially less than if found later in the project. To the customer, the value of a defect found by the producer is that the customer will not encounter the problems caused by the defect." (Rice, 1996 - 2009)

For Karl Wiegers, this value should translate, amidst a team, into a willingness to have its development products inspected by peers as early and often as possible. He presents software inspection as the most effective method to identify "faults (defects)" and specifies that not only code should undergo inspection. He considers any human-readable development artifact worthy of inspection : requirements specifications, design models and documents, test plans, system documentation, user aids... (Wiegers, 1994, p. 5 - 6; Wiegers, 1995, p. 1) Wiegers stresses, in particular, the great impact of requirements examination since a bug corrected this early in the project will save a lot of time and money. (Wiegers, 1995, p. 1)

In his book Creating a Software Engineering Culture Wiegers indicates that it is better to "suffer the slight embarrassment of having another team member find a flaw in a design or program" than to have to face a furious user or customer "complaining that bugs in our programs wasted their time, gave the wrong results, or otherwise aggravated them." (Wiegers, 1994, p. 5)

References :

Rice, Randall. 1996 - 2009. « Defects are good » in Rice consulting : Randy Rice's Software Testing site. Online <http://www.riceconsulting.com/articles/defects-are-good.htm>. Consulted on Novembre 16 th. 2011.

Wiegers, Karl. 1994. « Creating a Software Engineering Culture ». Online. 9 p. <www.processimpact.com/articles/culture.pdf>. Consulted on Novembre 16 th. 2011.

Wiegers, Karl. 1995. « Improving Quality through Software Inspections ». Online. 15 p. <http://processimpact.com/articles/inspects.pdf>. Consulted on Novembre 16 th. 2011.

How to apply the principle?

 

What are the consequences of non-application?

 

How can this principle be taught?

 

Link

Link to other principle?

External links

Rice, Randall. Defects are good (1996 - 2009) (Article) http://www.riceconsulting.com/articles/defects-are-good.htm

Wiegers, Karl. Creating a Software Engineering Culture, Software Development, vol. 2, no. 7 (July 1994) (Article http://processimpact.com/articles/culture.html www.processimpact.com/articles/culture.pdf

Wiegers, Karl. Creating a software engineering culture (Book) http://www.dorsethouse.com/books/cse.html

Wiegers, Karl. Improving Quality through Software Inspections, Software Development, vol. 3, no. 4 (April 1995) (Article) http://processimpact.com/articles/inspects.html http://processimpact.com/articles/inspects.pdf

Wiegers, Karl. Seven Truths About Peer Reviews, Cutter IT Journal, vol. 15, no. 7 (July 2002) (Article http://processimpact.com/articles/seven_truths.html http://processimpact.com/articles/seven_truths.pdf

Rothman, Johanna. What Does It Cost You To Fix A Defect? And Why Should You Care?, originellement publié sur Catapulse.com (October 2000) http://www.jrothman.com/Papers/Costtofixdefect.html

McConnell, Steve. Software quality at top speed, Software Development, (August 1996) (Article) http://www.stevemcconnell.com/articles/art04.htm

There has been error in communication with booki server. Not sure right now where is the problem.

You should refresh this page.