Elisabeth Hendrickson

Hi! I'm a software quality and testing consultant based in Pleasanton, CA. I founded my company, Quality Tree Software, Inc. (http://www.qualitytree.com), in 1997, though I took a 2-year hiatus to play what I refer to as "The Silicon Valley Lottery." In other words, I went to work for a hot startup. It eventually melted down, but I wasn't there to see the tragic end since I'd left to return to consulting a few months before.

Before starting my own company I worked for various high tech companies (STAC, Sybase, PC DOCS) and played a variety of roles (tech writer, programmer, technical trainer, tester, manager). I never tire of the process of building software. I'm fascinated by all aspects of it: requirements gathering and management, design, architecture, programming, configuration management, testing, project management, and even (gasp) marketing and sales.

For several years I was puzzled by what seemed to be a fundamental division within the software development field. On the one hand, there were formal methodologists pushing for the CMM and related heavy weight processes. Formal methodologists took great umbrage at the suggestion that we skimp on documentation. They were personally offended at the idea that we wouldn't know all the requirements before we started building the system. The wanted things done "right."

On the other hand, there were the pragmatists talking about "good enough quality" and the importance of lightweight processes. The pragmatists wanted to do "the simplest thing that could possibly work"--and their idea of "possibly work" tended to be very lightweight indeed.

I noticed that wherever the two camps met, mud flew. The formal methodologists called the pragmatists irresponsible while the pragmatists called the formal methodologists out-of-touch dinosaurs and worse.

I was baffled. How could smart people come to such different conclusions about what was right? And which group was right anyway? Then it hit me. They were trying to solve different problems.

OH!

The more I read, the more I realized that much of the formal methodologies came out of the world of government contracts and huge projects. By contrast the pragmatic approaches largely came out of the commercial software world. Which viewpoint was right depended on the context. I lived in the commercial software world most of the time, so it was no surprise that I tended toward pragmatic approaches myself. But I realized that my ideas of what was right wouldn't work if I were building missiles.

I've been context driven ever since. I've done a little more work with formal environments in the last few years and can appreciate the problems they're trying to solve. Further, I've realized that there are many more than two contexts. Even in seat-of-the-pants environments there's a big difference between the first release targeted to innovators and later releases targeted to the early majority. (If you don't know what I mean by "innovators" and "early majority," I strongly recommend Geoffrey Moore's _Crossing_the_Chasm_, ISBN 0060517123 .)

CategoryHomePage

Elisabeth Hendrickson