Is debugging a necessary part of all programming or is it just a symptom of an immature industry? Most other professionals don't spend half their time fixing mistakes — why do we?
This month's issue includes two useful articles on debugging embedded softwarea topic our regular columnists also typically cover. If debugging is the act of removing bugs then programming must be the act of inserting them, so the old saying goes. Jack Ganssle and others estimate that 50% of all software-development time goes into writing code and the other 50% goes into debugging it. I suspect many of us might treat that 50/50 split as optimistic.
What is it about programming that requires so much adjustment and correction? I'm as guilty as the next guy, but I can't think of many other professions where so much tweaking is normal. Architects don't throw up a building and then stand back and poke at it for six months to see if it stands. Shipbuilders, aircraft manufacturers, civil engineersthey all build things more or less right the first time. Artists don't (as far as I am aware) paint, erase, and redraw their pictures. Sculptors certainly don't have that luxury; one wrong move and your bust is a bust.
Hardware engineers, the programmers' brethren in the trenches, certainly do their share of debugging, too. They build, test, build again, and so on. (For chip design, that's not economically feasible; chip designers have to get it substantially right the first time.)
Is debugging an intrinsic and inherent part of the art and science of software engineering? Or is it just a legacy of the way we've done things in the past? Perhaps this 50/50 rule is a symptom of an immature industry, something that will go away in 100 years' time. We know that pioneering automobile makers tinkered and tweaked in the early 1900s; thankfully today's cars aren't built the same way. The science of medicine has improved dramatically over the centuries yet doctors, mercifully, don't iteratively debug much on their patients.
My head tells me that software development will become more formal and disciplined in the coming decades, more like mechanical engineering or chemistry. My heart, though, will mourn the loss of programming's “softer side.” Writing code is fun, in exactly the way that rebuilding a transmission isn't. If embedded software is to become an integral part of everyday life and the world economyand obviously, it isthen the process of creating it will have to become more regimented and deterministic, more formal and correct. Then programmers can have that other 50% of their time back.