Last week I stumbled across a verification post that used my favorite verification graphic from the Wilson Research Group Functional Verification Survey that Mentor sponsors every few years. Here it is again for anyone that hasn’t seen it posted here before (I’m sure this makes about a half-dozen times for me. It is, after all, my favorite verification graphic)…
I continue to think this data paints a very dim view of our development process and even after all this time I still cringe when I see it. It’s the time wasted on debug, at 36%, that really hurts… all of us. What also makes me cringe is that our industry’s response to this data is to create more effective debug tools and methods. I’ve always seen that as a knee jerk reaction that ignores root cause; the real reason we’re wasting 36% of a person’s time on debug is because we write buggy code, not because we have poor tools.
But I’ve obviously failed in getting that point across because I’ve been unable to spark the industry-wide outrage I think this data deserves . So instead of more serious discussion, I’m going to try a different approach.
First off, a variation of the original graphic…
I’ve taken the liberty of clumping all of ‘Test Planning’, ‘Testbench Development’, ‘Creating and Running Tests’ and ‘Other’ into 2 categories: Being productive and Creating defects. When it all comes down to it, regardless of the specific task, we’re either taking a step forward or a step back. Writing code that works is a step forward, writing code that doesn’t work (i.e. buggy code) is a step back. With 36% of our time lost to debug, I think I’ve given us the benefit of the doubt by suggesting that only about 20% or our time is used creating defects. The rest of the time, roughly 40-45% of our time is actually productive in that what we do doesn’t need to be fixed or redone at a later date.
So that’s 36% of our time debugging, ~20% creating defects and ~45% of our time doing productive work.
Now forget about the debug time and let’s focus on the creating defects, because that’s really what this is all about. Maybe examples from outside ASIC and FPGA development can help us understand the proper way forward…
Obviously these data represent serious circumstances that require even serious’er solutions. Luckily, I found these papers online as examples of how others are handling the problems they create for themselves:
- Improved Navigation Techniques for Off-course Marathon Running
- Efficient Teardown and Rebuild in New Home Construction
- Managing Concurrency in Hole Digging and Backfilling
- Eat Healthy and Lose Weight Fast on the Dorito Diet
- Honey… I’m Being Eaten by a Bear: 10 Need to Know Tips
Funny… I would have thought avoiding the honey in the first place would have been the best way to defend yourself against a bear.