How I test software
In my last column, I talked about the way I write software. I began by saying, "I've always known that the way I write software is different from virtually everyone else on the planet."
Boy, was I wrong. Many of you readers sent me e-mails saying, in effect, "Me too."
In retrospect, I was arrogant to suppose that I'm "unique on the planet," except in the sense that each of us is. It's nice to know I have some kindred spirits. (Not everyone shared my views. See the very thoughtful letter from Jim Berry in this month's Parity Bit section.) Yet, if I have so many kindred spirits, how come I never noticed?
Here's what I think. Faced with a certain development environment, complete with management directives and guidelines, and impossible schedules, different people respond differently. Some folks salute smartly, say "Yes, sir," and make do. I, on the other hand--the model of soft-spoken tact--give my opinions, which range from "That's unacceptable," to the ever popular, "That's the dumbest idea I ever heard!" Such comments have justly earned me, over the years, the title Jack "not-a-team-player" Crenshaw.
Having blurted out my opinion on a given environment, I try to change it to one where I can be productive.
Sometimes I succeed, sometimes not. One in-house project with the potential for making the company millions of dollars, involved real-time software for a microprocessor. When the "software development environment" arrived, it turned out to be a single-board evaluation kit, complete with line-by-line assembler (no labels, just addresses), and an old 110-baud, thermal-paper terminal. When I said, "Hey, wait a minute! Where's my hard drive? Where's my bulk storage device?" the project manager calmly pointed to the terminal's 110-baud cassette drives.
Fortunately, my campaign to change that environment succeeded: we got a far more acceptable one and delivered a great product.
More often, I'm unable to change the development environment. On such occasions, I try to carve out a mini-environment where I can still be effective. In my last column, I mentioned an embedded system project where we were promised new builds every two weeks, whether we needed them or not. In my inimitable fashion, I blurted "That's unacceptable! I'm used to turnarounds of two seconds" and set out to find a better solution. We found one: an interactive development environment (IDE) on the company's time-share mainframe. The IDE came complete with assembler, debugger, and instruction-level CPU emulator.
It wasn't perfect. The terminal was yet another 110-baud, thermal printing beauty that we used over the company's voice lines to the time-share system 1,500 miles away. But we got edit-compile-test cycles down to the 10-minute level, a whole lot better than two weeks.
Were there kindred spirits on that project, doing things the same way I do? Sadly, not. But in looking back, I suspect I had many kindred spirits on other projects and just didn't know it. It wasn't that they were all corporate sheep shuffling to the slaughter. It's just that they were a lot more successful than I, in seeming to be. Like me, they (you) would carve out mini-environments and practices where they could be more effective. They just did it under the radar. They didn't blab about it and left out the "That's unacceptable" and "dumbest idea" parts.
Dang! I wish I'd thought of that.