Plea for Mindful Development

Zen has the concept of mindfulness, embodied in part by paying attention to each breath. Good software development means paying attention to every single line of code.

• By Mike Gunderloy
• 04/01/2001

"Hmmm," I thought, "I don't see how there can be a type mismatch in this code." But then I remembered a problem with using Recordset variables in Visual Basic, and converted things to use late-bound Object variables instead. The problem continued, and I coded up a routine to dump the ADO Errors collection. I stuck that routine at the end of my error trap, and it never got called. Well, that's bad. Could I be doing something so obscure with ADO/MD that I was blowing up some internal variable in Visual Basic?

The answer to that question proved to be "no". After an hour of messing around, I found out that I wasn't doing anything sophisticated and obscure. I was doing something obvious and stupid. Here's the error-handling routine that was built into my Visual Basic code:

ExitHere:
Exit Sub

HandleErr:
MsgBox "Error " & Err.Number & ": " & _
Err.Description, "cmdBasicInformation"
Resume ExitHere
Resume

End Sub

If you're not a Visual Basic programmer, it may not be blindingly obvious what's wrong with this code. Here's what it should have been:

ExitHere:
Exit Sub

HandleErr:
MsgBox "Error " & Err.Number & ": " & _
Err.Description, , "cmdBasicInformation"
Resume ExitHere
Resume

End Sub

Yes, a single comma had cost me an hour's work and made me feel very stupid to boot. The bug wasn't in the code I was executing at all: It was in my error-handling routine, which was trying to send a string constant to an integer parameter. After 25 years of writing computer programs, I had inserted a bug into my code in one of the easiest ways to do so: by not paying attention to the code that I was writing. I've probably written ten thousand error-handling routines in Visual Basic by now. No doubt that lulled me into the false sense of confidence: "I'll never make a mistake in this code, so I don't need to test it." (Actually, the problem was even worse than that. I'd made the mistake the day before in another procedure, and had since copied the mistake into dozens of places in my program. But that's a lesson for another day.)

So, welcome to my new column for MCP Magazine Online. It takes a certain amount of chutzpah to start a series on improving software development by confessing to a boneheaded mistake. But you know what? Boneheaded mistakes are the norm in our field of writing software. Every developer I've ever worked with (and I've worked with some good developers indeed) has written code with bugs in it. What distinguishes the good developers is that they find the bugs and fix them. Sometimes they even do so quickly.

Overall, I'd say, the state of software development is not good. Let's look at Microsoft, for example. There are nearly 300,000 articles in the Microsoft KnowledgeBase these days. At least one third of these are reports of bugs — some with fixes, some with workarounds, and some that you just have to live with. That's a hundred thousand bugs. That's four thousand bugs in released software for every year that Microsoft has been in business. That's a lot of bugs. And that's only the ones that they confess to publicly. I'd guess there are at least ten times that many bugs in the internal bug-tracking databases at Microsoft.

Microsoft hires some of the best software developers around. I've worked with some of them, and their skills are amazing. These are people who can hold a myriad details in their minds at once, who can write code in their sleep, who are capable of blinding flashes of insight that result in brilliant new algorithms. They're supported by a company whose entire philosophy revolves around insulating developers from nonsense so that they can concentrate on writing code. And yet they still crank out code with bugs, year after year after year. If that's the best that Microsoft can do, is there hope for you and I?

In a word, yes. Software development has been around for more than 50 years now, and in that time we've learned a lot about what works and what doesn't work. There are resources out there, books and tools that will help you become a better developer (that is, one who releases code with fewer bugs in it). In this column, I'm going to try to introduce you to some of the resources, practices, and tools that have helped me over the years.

Let me start by making a somewhat arbitrary distinction: There are code mechanics, and there are mindful developers. My goal is to make you a more mindful developer. What does that mean? Step out of the software field for a moment to consider this quote from Buddhist monk Thich Nhat Hanh:

I remember a short conversation between the Buddha and a philosopher of his time.

"I have heard that Buddhism is a doctrine of enlightenment. What is your method? What do you practice every day?"
"We walk, we eat, we wash ourselves, we sit down."
"What is so special about that? Everyone walks, eats, washes, sits down ..."
"Sir, when we walk, we are aware that we are walking; when we eat, we are aware that we are eating ... When others walk, eat, wash, or sit down, they are generally not aware of what they are doing."

In Buddhism, mindfulness is the key. Mindfulness is the energy that sheds light on all things and all activites, producing the power of concentration, bringing forth deep insight and awakening. Mindfulness is at the base of all Buddhist practice.

No, I'm not suggesting that you need to become a Buddhist to write better code (though I wouldn't be at all surprised if it helped). What I am suggesting is that you need to become more mindful of the code that you write. A code mechanic knows all about the language he's working with and can crank out endless lines of code effortlessly, without thinking about it. And that's the problem! When the mindful developer is writing code, she is aware that she is writing code. She's thinking about what the code should do. She's writing each error handler for the first time, not writing the same error handler for the ten-thousandth time.

There may be a perfectly mindful developer out there somewhere who writes code correctly the first time and every time. For the rest of us, though, there's more to the process of software development. Look back at my original bug at the start of this column. Two things came together to waste an hour of my time:

1. I wrote a bad line of code.
2. I didn't test the line of code that I wrote.

The second point is subtle. Yes, in one sense I tested the bad line of code: I executed it, and Visual Basic obligingly returned an error. But my "testing" was at the crudest of levels. I ran the code, and something broke. Then I changed the code, ran it again, and something broke. Lather, rinse, repeat.

This is classic "black box" testing, and it's the way that Quality Assurance departments around the world test code. Throw some inputs at the code and see if it breaks. If it breaks, send it back to the developer with a bug report. But as developers, we have a better way to test. We can do white box testing.

The goal of white box testing is simple: It's to exercise every line of source code. We can do this because we have the source code and we have a powerful tool for exercising it. That's the debugger. Any modern computer language has some way to step through lines of code one at a time, watching their actions in human time instead of in computer time. Steve Maguire points out the power of this technique in his book, Writing Solid Code (Microsoft Press, 1993):

The best way to catch bugs is to look for them the moment you write or change code. And what's the best way programmers can test their code? It's by stepping through it and taking a microscopic look at the intermediate results. I don't know many programmers who consistently write bug-free code, but the few I do know habitually step through all of their code.

Sounds easy, doesn't it? But like any other bit of mindfulness, single-stepping through all of your code takes discipline. It's easy to get into a mindset of "Oh, that code is obvious. I don't need to test it." Beware! There is only a single comma between this mindset and an hour of wasted work. I know it will seem like you're wasting time when you first start this practice. But stick with it, and you'll save time in the long run — and you'll know your own source code better, and increase your confidence that it works correctly. And surely that is worth a little extra effort.