I just spent a few minutes reading Harry Foster’s analysis of a functional verification study commissioned by Mentor Graphics and carried out by Wilson Research Group in 2010. There’s lots of good information in Harry’s analysis – there’s 9 posts in all – and I’d highly recommend people take a look if they haven’t already. It’ll be worth your time. The posts go back to June 26th, 2011… which, admittedly, makes me a little slow on the uptake :).
The absolute best piece of information in that series comes via my new favorite hardware development graphic. You’ll find it in part 5 of Harry’s analysis… or since I’ve pasted it below, you’ll also see it by scrolling down a touch.
Why do I like that graphic? Because it very clearly illustrates the near ridiculous amount of time we spend debugging code. In fact, if you compare the debug and testbench development slices of that pie, you see that we spend more time debugging code (33%) than we do writing it (28%).
If you’re interested in participating in a study that’s different-but-similar, I’d appreciated you completing this survey.
That should be an alarm bell for hardware developers – and I think it probably was for the people that saw it – but what do we do about it?
Seems we could handle this in a couple different ways. The first way would be to make more productive use of our time spent debugging. If we’re better at debugging, we spend less time debugging. Sounds great but I have a problem with that. The bugs have to come from somewhere. Just a guess, but they probably come from the people writing the code. Which means that what’s not immediately obvious in my new favorite graphic on (wasted) effort spent in verification is that a good portion of the 28% of the time verification engineers spend developing a testbench – and to be fair, the comparable amount of time designers spend creating a design – is dedicated to…
So how about this for a different direction… instead of finding faster ways to write then fix buggy code, how about writing more robust code in the first place? Better code… fewer bugs… less time spent debugging.
If you want to know how to prevent bugs from getting into your code in the first place, you’ll want to go back to our Test-Driven Development posts from November last year. Those start here.
Say no to debugging. Write better code.