Join the DZone community and get the full member experience.
Join For Free
are you a
software professional
or not? i'm not talking about having some kind of
official certification
here. i'm asking whether creating high quality code on a repeatable basis is your
top priority
.
professionals do everything possible to write quality code. are you and your organization doing everything possible to write quality code ? of course, whether you are a professional or not can only be answered by your peers.
if you are not doing software inspections then you are not doing everything possible to improve the quality of your code. software inspections are not the same as code walk throughs, which are used to inform the rest of the team about what you have written and are used mainly for educational purposes. walk throughs will find surface defects, but most walk throughs are not designed to find as many defects as possible.
how do defects get into the code? it's not like there are elves and goblins that come out at night and put defects into your code. if the defects are there it is because the team injected them. many defects can be discovered and prevented before they cause problems for development. defects are only identified when you go looking for them, and that is typically only in qa.
benefits of inspections
inspections involve several people and require intense preparation before conducting the review. the purpose of inspections is to find defects and eliminate them as early as possible. inspections apply to every artifact of software development:
- requirements (use cases, user stories)
- design (high level and low level, uml diagrams)
- code
- test plans and cases
inspections as a methodology have been around since the 1970s and certainly well codified since m. e. fagin wrote a paper in the ieee in 1986. the idea behind inspections is to find defects as early as possible in the software development process and eliminate them. without inspections, defects accumulate in the code until testing when you discover all the defects from every phase of development simultaneously.
this diagram from radice shows that defects will accumulate until testing begins. your quality will be limited by the number of defects that you can find before you ship your software.
with inspections, you begin to inspect your artifacts (use cases, user stories, uml diagrams, code, test plans, etc) as they are produced. you attempt to eliminate defects before they have a chance to cascade and cause other phases of software development to create defects. for example, a defect during requirements or in the architecture can cause coding problems that are detected very late (see inspections are not optional ). with inspections the defect injection and removal curve looks like this:
when effective inspections are mandatory, the quality gap shrinks and the quality of the software produced goes up dramatically. in the economics of software quality , capers jones and olivier bonsignour show that defect removal rates rarely top 80% without inspections; but with inspections you can get to 97% .
why don't we do inspections?
there is a mistaken belief that inspections waste time . yet study after study shows that inspections will dramatically reduce the amount of time in quality assurance. there is no doubt that inspections require an up-front effort, but that up-front effort pays back with dividends. the hidden effect of inspections is as follows:
many defects in a software system are caused by ignorance, a lack of due diligence, or simply a lack of concentration. most of these defects can be found by inspection, however, people feel embarrassed and exposed in inspections because simple problems become apparent.
professional software developers are concerned with high quality code . finding out as soon as possible how you inject defects into code is the fastest way to learn how to prevent those defects in the future and become a better developer. professionals are always asking themselves how they can become better, do you?
conclusion
code inspections have been done for 40 years and offer conclusive proof that they greatly improve software quality without increasing cost or time for delivery. if you are not doing inspections then you are not producing the best quality software possiblebibliography
- bonsignour, olivier and jones, capers ; the economics of software quality ; addison wesley, reading, ma; 2011; isbn 10: 0132582201.
- fagan, m.e. , advances in software inspections , july 1986, ieee transactions on software engineering, vol. se-12, no. 7, page 744-751
- gilb, tom and graham, dorothy ; software inspections ; addison wesley, reading, ma; 1993; isbn 10: 0201631814.
- radice, ronald a. ; high qualitiy low cost software inspections ; paradox icon publishing andover, ma; isbn 0-9645913-1-6; 2002; 479 pages.
- wiegers, karl e. ; peer reviews in software – a practical guide ; addison wesley longman, boston, ma; isbn 0-201-73485-0; 2002; 232 pages.
Topics:
java,
opinion,
defects,
quality,
inspections,
tools & methods,
productivity
Published at DZone with permission of Dalip Mahal, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments