POKA YOKE

Shigeo Shingo demonstrated the concept of poka-yoke in 1961, The initial term was baka-yoke, which means ‘fool-proofing’ or ‘idiot proofing’. Due to the term’s offensive connotation, the term was changed to poka-yoke, which means ‘mistake-proofing’.

 

The term “poka-yoke” comes from the Japanese words “poka” (inadvertent mistake) and “yokeru” (prevent/ to avoid).

 

The essential idea of poka-yoke is to design the process so that mistakes are impossible or at least easily detected and corrected, In Shingo’s words “The causes of defects lie in worker errors, and defects are the results of neglecting those errors. It follows that mistakes will not turn into defects if worker errors are discovered and eliminated beforehand” He later continues that “Defects arise because errors are made; the two have a cause-and-effect relationship. … Yet errors will not turn into defects if feedback and action take place at the error stage”.

 

To overcome the above Shigeo Shingo describes three major inspection methods: (1) judgment inspections that discover defects. (2) informative inspections that reduce defects, and (3) source inspections that eliminate defects.

 

It is this paradigm which has made it’s entry in software development and now needs to proliferate, QA is not just testing, it doesn’t have to happen at the fag end of software development but should be manifested in the design ( principles of design for manufacturing/development) & in the development process so that the over head on testing is limited.

 

A lot of literature gets generated on this yet adoption remains a challenge, A result of which is we continue to have production surprises, The production surprises precipitate knee jerk reactions wherein the general finding is inadequate QA, and the often suggested remedial measure is augment QA team. There have been instances where in as a knee jerk reaction the QA team size was increased and made bigger than the dev team.

Though in reality The real issue is a defective development process that allows defective code to be added. Defects in code are generally the symptom as we seldom remove defects from the system for building systems,We rarely focus on them. It is more economical to correct the system for building systems so that it prevent defect injection in the first place.

As humans by nature are fallible and it’s this fallability which manifests in defects. Defects persists, this helps us identify one of causes of defects.

Taking a stab here, we have 2 options to minimize if not eliminate defects,

  1. Invests in skills to reduce the fallability of the team members.
  2. Create hooks in design, and development process help eliminate defects by prevention
  3. Create macro’s , utilities to inspect code which facilitate early feedback  ,help in early detection.

 

 

Defect elimination has two distinct disciplines i.e

  1. Defect prevention
  1. Defect detection and removal.

 

Poka Yoke attempts to address both the dimension of defect elimination , yet the common refrain among the software fraternity is that it is a manufacturing technique and not amenable to software development, while the reality of those who have tried it is remarkably different.

 

 

Defect Prevention:

A prevention construct wherein emphasis is made on engineering the process/design so that it is difficult if not impossible to make mistake. Some examples of defect prevention in software development are.

 

  1. One of the tricky source of errors has been requirement ambiguity and its incompleteness, here processes like Test driven development which mandates building detailed testcases by QA    team before the dev team begins to code and these test cases are reviewed by the user / BA community providing an early feedback on the requirement documentation and its understanding by Dev and QA team helps improve requirements understanding and eliminate ambiguity and its incompleteness.
  2. Use of Drivers and synthetic test data can give quick feedback on Database response times. Thereby avoiding surprises in meeting response time SLA’s.
  3. High level languages prevent self-modifying code. Code modularization /Structured programming saves the development team from spaghetti code and resultant errors.
  4. IDEs and Compilers: IDE’s indicate issues in code while you code (intellisense). They catch mistakes around incorrect type casting, generics etc.
  5. Formal software development process like Cleanroom Software Engineering developed by Harlan Mills or Watts Humphrey’s Personal Software Process(PSP) have proven utility in defect prevention.
  6. Use of appropriate templates for test case design helps ensuring coverage.
  7. Pair Programming where programmers work in pairs, with one typing and another observing, correcting deviations and commenting.
  8. The application of the single responsibility principle introduced by Robert C. Martin where every class have responsibility over a single part of the functionality provided by the software, and that responsibility is entirely encapsulated by the class. This helps in maintenance, reduces misuse thereby preventing errors.

 Defect Detection

  1. Use of prototyping or simulation helps in quick turnaround of requirement analysis and exposes requirement issues.
  2. Peer reviews ,infact systematic checklist based reviews help in early defect detection.
  3. Software testing is a classical defect detection activity, just that it should not start at the end of sdlc.
  4. Juran’s concept of internal customer satisfaction where the architecture team is the internal customer of the requirements team, the coding team being internal customers of requirement team ,architecture team and process team and so on have to sign off the work of their internal suppliers thereby mandating successive inspections and reviews.

 

QA can happen only if quality is build into the application, While testing just gives us a view on the quality of the build, it does not improve quality, Building quality starts from requirements phase wherein requirements are specified keeping the user in mind , usage of combo boxes over text boxes where applicable are Poka yoke aids for the user, and prevent accidental entry of erroneous data. Similarly source/self inspection and successive /peer inspection/review at end of each phase help eliminate errors in phase.

 

The current literature in defect prevention is loaded towards inspection / reviews & TDD. Jidoka’s i.e widgets / tools/templates/macros which help detect abnormality need to be encouraged, Also principles of design for development which encourage componentization , reuse of code , handling of errors and amenable to change need to be institutionalized, though all this may initially create resistance at some places with epithets of over engineering, stifling creativity ,increasing monotony etc yet over a period of time on correct implementation the benefits will far outweigh the concerns.

 

 

REFERENCES

  1. The Pokayoke Guide to Developing Software written by Aaron Swartz     http://coder.zoomquiet.io/data/20120708005006/index.html
  2. The Development of Zero Defect Computer Software by G. Gordon Schulmeyer, CDP , http://www.pyxisinc.com/Shngopapr.pdf

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s