The one without a bug.
I just don’t seem to learn, do I?
Daddy, where do bugs come from?
My project manager wanted to know where all the bugs came from. Well, there’s this stork and… Yeah, the “Bug Stork”…
Well, no. We make mistakes and introduce errors into our programs. We had a lot of errors. We had so many, we needed a database to keep track of them.
Were some modules more error-prone than others? If so, why? That’s what the project manager wanted to know. He had written a script that counted the number of lines in each module and divided this by the number of bugs assigned to this module. He was going to make a graph of bug density. That would tell us where to concentrate our effort, because we couldn’t fix all the bugs.
He asked me to help him debug his script, because something was going wrong. His script always threw a “division by zero” error when calculating #lines/#bugs. We discovered that there was one module with zero bugs! Clearly, a requirements error: nobody expects a zero-defect module!
The perfect module
Which module had no bugs? Who was the super-programmer who had implemented this perfect module?
Turns out that this module was written by M., a programmer in my team. It was the first thing he ever wrote for the company, fresh out of school. His later work was riddled with errors, like everyone else’s. What had happened?
As M. was new and this was his first programming job, I was asked to mentor him and help him find his way around our code, so I had a pretty good idea how this module was written.
The recipe for a perfect module
I divided the project into small pieces. Before starting on each piece, M. and I would discuss how we could implement it. M. would then go off to implement a bit, asking me questions whenever something was unclear.
When M. had written a piece, we’d go over the code. M. would explain the code to me and I asked questions and gave feedback. Often, the fastest way to explain what I meant was to take over the keyboard and change a bit of code or write another bit. And then M. would change something. We would rework each bit of code until we were happy with it and it worked. And then on to the next small piece.
And what have we learned from this?
It took a lot of effort on my part, effort that wasn’t being put into productive work. But the goal was to teach M. how to code independently.
After that first project, M. didn’t need any more handholding. He could now implement modules on his own. I could go back to my real work: writing and (most of all) debugging modules. Now, we could each work on our own modules. That’s a lot more efficient than two people working on one module.
And things were back to normal: neither M. nor I ever wrote a (even remotely) defect-free module ever again… That’s how it’s supposed to be, isn’t it?
