DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Software Professionals do Inspections

Software Professionals do Inspections

Dalip Mahal user avatar by
Dalip Mahal
·
Dec. 17, 12 · Java Zone · Interview
Like (0)
Save
Tweet
4.81K Views

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:



the issue is that people know that they make mistakes but don't want to admit it, i.e. who wants to admit that they put the milk in the cupboard? they certainly don't want their peers to know about it!

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.

for inspections to work, they must be conducted in a non-judgemental environment where the goal is to eliminate defects and improve quality.  when inspections turn into witch hunts and/or the focus is on style rather than on substance then inspections will fail miserably and they will become a waste of time.

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 possible


bibliography

  • 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.
Inspection (medicine) Software development

Published at DZone with permission of Dalip Mahal, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • OPC-UA, MQTT, and Apache Kafka: The Trinity of Data Streaming in IoT
  • Top Six Kubernetes Best Practices for Fleet Management
  • Stupid Things Orgs Do That Kill Productivity w/ Netflix, FloSports & Refactoring.club
  • Why I'm Choosing Pulumi Over Terraform

Comments

Java Partner Resources

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo