Sunday, 18 April 2021

Finding defects(on paper)

The shelf life of technology is decreasing and the contraction is accelerating every day. What does this mean? The time from ideation to production is shortening and new disruptions have quickly become a norm. 

High quality of the service and/or product is an implicit assumption for the organization/product to exist. 

How do we measure product quality? Run it through a test cycle, file the deviations, fix what is necessary, and document what can be managed.

The testing phase involves writing a test plan, building testbeds, environment, recording/reporting deviations, validating the changes, and finally handing it over to the customers. Testing is a costly but mandatory endeavor to gain confidence in the success of the product. 


So what is finding defects on paper mean? 

In the current system of product validation rewards/recognition is based on what is recorded 😀. 

Organizations tend to reward folks where NO(or almost) defects were reported for the Software/Hardware piece they delivered AND/OR folks who reported maximum high-quality defects. Seems to be a sensible way to differentiate among employees providing the maximum value in a specified time. 

What most organizations don't measure is how many of these defects could be found without testing literally(remember literal testing is a cost to the organization and profitability) and continuously encourage (and provide time, resources, and training) to find as many defects as possible on paper(without testing literally).  

Finding defects on paper means how many defects can be found during PRD review( yes as early as PRD), design review, code review, and test plan review. 

Now we can debate, that is how it is done today so how is it different?

There are two tactical actions that organizations can start to measure the effectiveness(current) and build a feedback loop for continuous improvement. 

First, for any review, feedback/comments/AI which are not clarifications but problems(defects) caught early,  start tracking them as early offline defects. Keep the overhead of tracking these offline defects as minimal as possible by using automation. Closing them automatically when the review owner confirms the compliance. 

2) During  PPA(post-project analysis)  review the defects which were found "literally" and identify if strengthening any upstream review process would have helped to find them "on paper". This will build a feedback loop that continuously strengthens the review processes. 

In summary, for us, it is difficult to appreciate and reward the actions that we cannot measure(and 👀) and compare. 

Finding defects through the review process helps to reduce the cost of defects(because they are found early), save cost (running labs, servers), enable any participants in the review process to report, and moves the focus of improvement(and investment to strengthen) on upstream processes.  



1 comment:

Protobuf ?

Hello friends this is a follow-up to my earlier post related to gRPC Vs Restconf and as promised below is a quick summary on Protobuf (the...