Taking a Prism to Software Development

A magnifying glass brings us closer to the subject — allows us to examine the details. A prism, on the other hand, separates the rainbow of colors that are otherwise hidden in white light.

What if testing were separated from coding?

While there’s a popular trend these days towards combining them again in a new way — Test-Driven Development — many software organizations still have separate testing groups at the product or system level. We can ask if that’s good or bad, and why? But that’s an ongoing argument.

I’d like to ask a less familiar “what if” question.

What if debugging were separated from coding?

Imagine a software development organization where developers write code, another group tests it (that’s QC), and then the developers fix what QC has found. But that a separate group does all the debugging. All the figuring out what’s wrong, setting breakpoints, reading logs, doing traces etc. In short, the troubleshooting. Developers are not allowed to do that. The debugging team are experts in the codebase, and narrow down the problems, all the way to identifying where to fix the code and how. Then they return their results to the original coders for use.

No, I’m not suggesting such a process. Rather, I’ve been surprised to see so many books about professional programming say that debugging is an essential skill for a programmer. If it’s such an important activity, maybe it should have its own professional team to do it.

On the other hand, what does the need for such an activity say about the code?

Just the other day I saw my own coding project get stuck in debugging. The irony is that I was working on error-handling, and I was debugging an assert statement that didn’t seem to be working. I felt several degrees off from forward motion in coding.

Maybe we have to go back to history.

The First Bug

James S. Huggins has done us a great favor by giving some background on the exhibit that’s now in the National Museum of American History.

Many people are familiar with the story. The first computer “bug” actually walked into the machine and caused a failure. A hardware failure.

But do bugs walk into code? So that we should spend so much time, tools, and energy on searching for them, capturing them, and getting rid of them?

Advertisement