The Quest For Imperfection
I decided to dabble with my culinary skills today. I made the north Indian delicacy, Cholae (garbanzo beans). I took my job pretty seriously, adding the thousand five hundred (kidding) ingredients at the right time, and in right proportions. So, when the stuff came to a boil, it was time to taste it to confirm that everything was OK. I had to do the tasting twice before convincing myself everything was ok. However, the whole process threw open a few questions which people might experience in their professional lives. The cooking part can be related to the “development” of a product, and the tasting part can be related to the “verification” of the product. Take the semiconductor industry for example. This industry is consumed by the need for verification. The time it takes to verify a product far exceeds the time to develop the product in the first place. Every second year, a new standard emerges. While, development has mostly been limited to Verilog language, verification has gone from C++ to systemVerilog to VMM to OVM to you name it.
So, how much verification is too much verification? In the kitchen parlance, when should I stop tasting the food? If I search for eternal quality, I might continue tasting the food until I have either consumed all of the food, or it is well past dinner time. On the other hand, I could do it just once, make some changes to my preparation and call it done. The former approach will ensure nobody gets food. The latter approach will ensure everyone gets bad food. The end result in both cases is the 먹튀검증 same: hungry and angry people. Similarly, over-verification delays the product’s time to market, making it essentially useless. Under verification causes production stops, which again hits the company’s schedule, and its reputation in the industry takes a nose dive.
The key to successful products is to find the right balance to ensure that the end product is excellent, but not perfect. The quest for perfection is like the 80-20 rule. It is relatively easy to get the product to 80% quality, but the last twenty percent becomes progressively harder. So, a 95% product quality may be acceptable to most customers, and achievable in reasonable time. Depending on the type of product, spending time over the last 5% may not be cost efficient. On the other hand, enough effort must be spent to get the product from 80 to 95%. If this is not done, the product may not be usable.
In kitchen parlance, a lot depends on what I do with my first tasting. Depending on how well I analyze the taste, I can make a significant progress between the first and the second tasting. A dumb me would just add salt, only to realize later that I added too much salt. Then I would add something else to neutralize the salt and end up running in circles. The smart me would analyze the amount of salt required, and also realize that certain ingredients are missing. I would add them in the right quantity, and by the time I taste again, my dish would have improved significantly.
Similarly, a verification engineer can choose to be dumb or smart. A dumb engineer usually would come back with a one line statement that reads “code crashed on line 1293”. The developer would go back, fix the problem and send the code back to the verification guy. His second report would read “code crashed in line 1324”. Now, when the code at 1394 is fixed, it would crash on line 1293!!! The code would be ping-ponged between the developer and the verification engineer, until the developer, verification engineer and the manager are fired for not releasing the product on time. The smart verification engineer will read the architecture specification and will have full knowledge of the product. He will understand the root cause of the problem, and provide as much details as possible to the developer. The developer will then fix many problems in a single iteration, thereby reducing his workload, as well as that of the verification engineer. I wish life were so easy!!!