Talk About Quality

Tom Harris

Posts Tagged ‘tools

Don’t Do It Yourself

leave a comment »

"Do It Yourself" or "DIY" for short is a popular way to save money and get things done quicker at home. While few people remodel entire kitchens by DIY, I know I'm not the only one who regularly repairs faucets, or even assembles simple furniture.

But at work, DIY can turn out to be equivalent to another well-known "D" expression: Don't Reinvent the Wheel.

I recently returned to a bit of C programming, in order to familiarize myself with the daily challenges of developers I want to help and support. Developers who remain in C due to embedded platform constraints. I figured that if I wanted to offer this or that tool as a solution to some problem, I'd better try it myself first.

Getting back to C programming meant I needed two things: some source code and a compiler. I found some code I'd written a while back in C++, and decided to rewrite it in C. As for a compiler, why not cl – the command-line compiler from Visual Studio 2005? Not the key part of that comprehensive Microsoft product, but I figured it would do. And of course the Visual Studio editor looked fine too — I could use it to browse my code even if I didn't bother to remember how to set up an entire Visual Studio project.

Merrily I started on my way. Review my old C++ program. Relearn what isn't in C as opposed to C++. Redesign. Write function prototypes in an .h file with some stubs in the .c file. And … compile!

Lots of errors!

No big deal I thought. Just stare at the code, change something, go back to DOS, compile, pipe the error results into a text file, review them, try again. Tiring, and it didn't work.

Rule #1 is hard to follow, but usually helps: leave it 'til tomorrow when you're better rested. All that switching back and forth between windows was tiring. And frustrating when the errors refused to go away.

Next day, by coincidence, a co-worker gave me a copy of a professional source code browser called Source Insight, which he had shown me several months ago. I returned to my task, and was faced with a choice. Go back to looking for the cause of my errors, or take time out to install this new "toy". (Actually, I had known from the first time I had seen it that it was much more than a "toy", but I had never really tried it.)

I installed it. I learned that one could define one's own "compile" command and install it on the menus. Even that it could be told to parse the compiler output and hyperlink between it and the source code. It took me a good hour, especially without documentation for Microsoft's environment variables batch file required for cl to work. But I slowly remembered DOS batch file language, and got it working.

I compiled again, this time with a professional tool. The errors came up, each hyperlinked to the source code. I looked at the first error message, flipping back and forth between it and the source code. I looked up the error C2143 via Google, and got to Microsoft's succinct explanation. Didn't help much.

I stared at the line of code again. This time, though, each element in the line was marked in a different color according to its role in the statement. (Yes, Visual Studio does some color-coding, but Source Insight does much more.) After about two seconds I saw that what I had written was ridiculous: I had used const in place of a #define but had forgotten to use an equals sign to make the assignment.

I fixed it and the error went away.

I had known that Source Insight existed. I had known where to get a copy: from someone who had invested time in identifying an excellent source code browser and editor. But I had tried the wrong kind of DIY — reinventing the wheel — instead of just going and asking for one.

In such cases, don't do it yourself.


Written by Tom Harris

May 29, 2006 at 3:15 pm

Posted in Agile, Learning

Tagged with