Month: March 2005

I think everyone's experienced difficult conversations in which you have to drag information out of someone. If you've ever had any training or experience in requirements gathering, sales, or other interviewing, you've also learned about open questions vs. closed questions. In my experience, this is almost always focused on drawing additional conversation out of someone who doesn't want to be conversational. There's another side to this phenomenon, though - the person who takes a yes-no question and fires back a wilting soliloquy.Some people call this doubletalk. Some people call it rambling. Many people don't even realize it's happening -- it's the long answer to a short question.

I've begun to pick up on this more quickly than I have in the past because I'm seeing it in a few people on a regular basis. I can now spot the "long answer" almost immediately, just by paying attention to the nature of the question. There are some questions, of course, that should be able to be answered in one or two words ("Yes", or "This week."). When your answer doesn't fit in that sort of box, it stands out vividly.

I've seen two forms of the long answer, and these can be difficult to tell apart. The first is just rambling. This detracts from effective communication, but it's not really too harmful. You can identify this answer because there is actual information in the answer -- it's just spread out across a whole lot of useless dialog. Watch for this from engineers who provide exhaustive detail when it's not necessary (if you're an engineer, pay attention to your own answers - it's easy to do this).

Thei second form of "long answer" is true doubletalk or evasion. This is best detected by remembering the question that was asked and trying to match the answer to the question. If someone manages to change the subject of the conversation in the first three words of their answer, they're deflecting attention from the original question. You can sometimes spot these in advance of the actual answer, because the question will demand a commitment in the answer:

• When will you be done?
• How much will it cost?
• Have you documented the requirements?

The classic form of doubletalk is the political debate. Politicians are well known for their ability to talk on and on without saying a thing. Though it's less commonly recognized, this sort of thing happens all the time in business. When it's excessive, it's easy to spot, but very often, it escapes just under the radar. Again, keep the question in mind as you're listening to the answer, and see if the question is satisfied.

In order to become attuned to the "long answer", try watching for it in other people's conversations, and then watch for it in your own answers. Here are some occasions that may yeild examples:

• Staff meetings.
• Sales calls.
• Job interviews.
• Design reviews.

Armed with a little knowledge, you can make a lot of sense out of the context of some of these conversations, and the results can be enlightening!

I've been working through some interesting process issues with my employer's CTO and head of Product Management. The thrust of these discussions is that we've revised our Product Planning and Product Development processes, and I'm currently working on documenting what we've agreed upon. No sooner had we come up with a plan, however, than a "highly important" project sprung up, prompting discussions about suspending parts of our process because this project was so important. I've managed to stop my head from spinning long enough to gather some thoughts....

Origin of Process Changes

I've grown my current development team from nothing, and grown our process along the way to fit the organization. Our informal process guide has always been "just the right amount of process for our needs... and nothing more." In our most recent revisitation of process, I worked with our CTO and Product Manager to address schedule variations due to requirements problems.

In short, we were entering a release with only the most vague sense for requirements for features in that release. In the past, this had resulted in schedules not being met because we didn't really understand what we were supposed to build until we moved a portion of the way through the release. I'd suggested better requirements a number of times (citing Joel Spolsky's excellent guielines), but this was written off as too much work.

Prototyping, it was agreed, would be the best compromise for our situation, allowing us to build out more detailed requirements iteratively. We tried this in a mini-release, and though we had some minor problems, it was deemed to be generally workable. A side effect of this process is that our release date couldn't really be known until we moved through about 1/2 of the release. Prior to that, we had a target and a +/- range for our date, but nothing one could take to the bank.

Screeeechhh!!!

It was about this time, of course, that the Important Release reared its head. We needed to figure out a date for the release *right away*, which was the first violation of our process. Nevertheless, I came up with a date based on similar work and similar releases we'd done in the past.

The date wasn't good enough.

Thus began the further erosion of process: "why can't we skip parts of the process and speed up the release?" "I know this isn't our normal process, but this isn't a normal release -- this one's *IMPORTANT*".

There was clearly a whole raft of concepts that just never managed to lodge securely in the nooks and crannies of these executives' minds. These are a couple of pretty smart people, so I can't chalk this up to lack of cognitive ability. There's something here that these guys really don't get, and I can't account for it.

The Missing Link

In the spirit of "we hold these truths to be self-evident", I'm adding here the rationale I've used to establish process. It seems to make sense to me, but as my recent experience has shown, it can't be taken as a given that this makes sense to everyone. I've seen this widely chalked up to "some people don't get it", and I have to echo that sentiment at this point.

Our software development process, like most, is designed to move us through a release as expediently as possible. It's not my habit to put process in place to make us go more slowly. Unfortuneately, this is a nuance that's frequently lost on the casual observer. Process, it's felt, is overhead. Cut the process, and you'll go faster.

Steve McConnell's Rapid Development has a great passage about a software team from Ernst and Young who attended a programming contest and used process to great effect. They appeared to get out of the gates more slowly than everyone else, but their process made their progress so reliable and relentless that they quickly overtook everyone else. They ended up finishing second because of a breakdown caused by skipping part of their process! (They ended up using the whole process at the next event, and won it).

If process didn't help us, we wouldn't use it. Therefore, any process we've got is here because it makes us go faster. Simple idea, but frustratingly elusive when it comes to getting non-developers to internalize it.

I tried another example with seemingly little effect. Imagine someone who spends lots of valuable time coming up with a disaster recovery plan, and then when a disaster hit, the first thing they do is reach for the disaster recovery plan and chuck it in the trash. "I don't have time for a plan," they'd say -- "We have an emergency on our hands." Most people, I think, would say that they deserve whatever fate befalls them.

Not so with a software development process, though.

I'd like to hear your impressions and ideas. Register and post your comments if you've dealt with this.