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
- April 01, 2001
I was writing some code to retrieve information from SQL Server 2000 Analysis
Services via the query retrieval objects in the ADO/MD library. Things
were going along fine, until suddenly Visual Basic told me "Error 13:
Let Us Know What You Think!
|If you're a current or former MCSD or an MCSD wannabe
who thought MCP Magazine conspicuously ignored your needs (yep,
we heard it all, including "Why don't you just call it MCSE
Magazine?"), let us know what you think of our new MCSD-related
coverage online. Write to Michael Domingo, Web Editor, at firstname.lastname@example.org;
put "MCSD Feedback" on the Subject line of your message.
if you have an interesting technique or developer time-saver you
want to share with fellow MCPs, we'd love to hear about it at that
same e-mail address.
"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?
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:
MsgBox "Error " & Err.Number & ": " & _
not a Visual Basic programmer, it may not be blindingly obvious what's
wrong with this code. Here's what it should have been:
MsgBox "Error " & Err.Number & ": " & _
Err.Description, , "cmdBasicInformation"
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
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.
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.
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:
a short conversation between the Buddha and a philosopher of his time.
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."
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.
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
- I wrote a bad line of code.
- I didn't test the line of code that I wrote.
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.
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
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.
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.