While in Sanibel, in between sessions, I was pacing with my portable phone, handling a client crisis back home. Much of the crisis had to do with mismatched expectations. They'd say, "Why doesn't it do {that}? I need it to do {that}" I'd say, "I mentioned {that} in the design talks. You said you didn't want {that}." They'd say, "But of course we need {that}. This isn't what I wanted at all."

Same old story. Software is a difficult thing to make, particularly when you're making it with people who aren't used to thinking about their needs abstractly. Seems like the less technically comfortable the client, the bigger the problems I have with them. When I'm dealing with someone who understands software, they're able to listen to my questions and concerns and respond appropriately. When I'm dealing with someone who asks, "Which one is the web browser?", I'm in trouble, especially when the budget isn't big enough for a thorough requirements analysis.

In my hotel room, fuming over the crisis up north, I wrote out a few "rules of engagement" about what kind of clients to accept in the future. The first one makes people laugh, but there's really something to it:

1. Never work for someone unless they know the difference between a branch and a loop.

This is basically saying, "Work only for other software companies." Just this one criteria would have eliminated every unpleasant client experience from the last two years. Of course, I may not have enjoyed the work as much, but that's another matter.

The next one has to do with our development lifecycle:

2. Clients must understand and appreciate our iterative timeboxed approach. They need to understand the tradeoffs.

One of our biggest assets as a company is our flexible project lifecycle. Clients that understand can make changes easily as things progress. Clients that don't understand fall into the "I didn't ask for this" trap. As much as we explain to the client how we schedule, as often as we say, "You're the gas and the brakes", there are some who just never understand the approach, and so use our firm less effectively.

The last cuts to the heart of the matter:

3. Don't do work for someone unless they really know why we're worth our rate.

The client has to know why they're hiring a professional software team that knows object-orientation, refactoring, design patterns, iterative development, business modeling, usability, etc. If they can't tell the difference between us and a twenty-something doing Visual Basic scripting as a web front-end for an Access database, we're in for some real trouble.

But what of all my talk about "grannies" in this blog? Aren't I trying to champion disenfranchised non-technical users? Well, the difference is between selling a product and providing a service. At least with in-house product development, we can control the budget and feature set. We need to consult with non-technical users, of course, but they can't yell at us. :)

Later that week, when I re-read my rules, it became clear: I don't want to do contract work for clients anymore. After almost six years of doing the "hired gun" thing, I'd lost my taste for it. This is when we decided to switch Immuexa from being a service-based company to a product-based one. This is when we committed to bringing our own products to market.