Craig’s Linked List

Ted says: Clients don’t always say what they mean. This is 100% true. My experience is that the majority of all people in business can’t fully and clearly articulate their thoughts, either verbally or in writing. Compounding this are situations where the client isn’t 100% honest and forthcoming; these run the range from simple cautiousness to outright deceit. Thus, you typically can’t take a client’s statement at face value.

Furthermore, even if a client can say what they mean, they may not mean what they actually want. And, even if they mean what they want, they may not actually want what they need. It’s the need that should be fulfilled, but there’s a lot of obstacles in the way.

To make matters worse, these obstacles are often multiplied by the numerous layers of “clients” involved. Here’s an example based off a real-world situation (the one I was in until recently):

1. The implementor gets requirements from his immediate boss.
2. The boss gets the requirements from the business/marketing/client relations department.
3. The client relations department gets their requirements from a 3rd-party development company (who is subcontracting part of the work to the implementor’s company)
4. The contracting development company gets their requirements from the actual client.
5. The client gets their requirements from the users.

It’s easy to see how confusion and misinformation can affect the requirements when there’s this many stages between the producer and the consumer of a piece of software. That’s why it’s important to do a thorough review of a particular request to verify that the sights haven’t drifted too far off the target.

I like mining as metaphor. There’s a nugget of gold buried in a mountain of communication. You need to dig away all of the useless rock in order to find it. As you dig, you’d better be setting up struts of solid reasoning to keep it from collapsing on you… and you’d better be digging in the right direction, or else you might miss the prize entirely.

Bruce responds to my prior post on requirements:

…I think you also have misinterpreted the user’s statement of the requirement.

Ted’s discarded first sentence IS a problem statement, but only for the second sentence (password confirmation field).

I don’t think the last sentence is a goal for the two requirements, in fact it has got nothing to do with problem statement. Interpreting it as the goal causes your question 5 to yield a negative answer.

The last sentence is (I think) a statement of a second problem, which leads to the second (but already stated) requirement. I would interpret the paragraph (briefly) as…

I didn’t really put any interpretation into the validity of the first and fourth sentences, nor did I attempt to answer any of the questions I asked. I just used them to illustrate the questions & types of statements themselves.

However, Bruce’s disagreement shows exactly the kind of process I was looking for when assigning qualifiers and questions to the sentences in the first place. He brings up valid points which prompt further action:

1. acceptance (if everyone on the team is convinced he’s right)
2. counterargument (if someone on the team thinks he’s wrong and can explain why), or
3. clarification (go back to the requirement writers and ask for more information to confirm or deny the assumptions we’ve made

The last two actions restart the process until full agreement is achieved. If you have enough people with good reasoning skills and tenacity to see disagreements through until they’re resolved, then the results of your analysis will probably be very close to the hypothetical “most correct answer possible.”

Along the way, all of your requirements, problem statements, and goals stand a good chance of complete replacement. That’s a good thing — if you’re doing the wrong thing, it doesn’t matter how well you do it, you’ll still come out with a poor result.

Something happened to my WordPress install which caused the site to stall. A week of bickering with Dreamhost got me nowhere, but I reinstalled WordPress and now it seems to be working just fine. If you see any errors please let me know.

I’m signing up for Technorati. On one of the configuration pages I see this:

Quick Claim

What is it?

It’s quick! Just enter the username and password for your blog. This information will only be used to verify that you own the blog, and it won’t be shared or stored.

Dear lord, who are they kidding?

In any case, they do offer a sane alternative:

Technorati Profile

Wordpress is a pretty impressive piece of web software. It’s pretty easy to use and has a lot of nice AJAX-y features. The WYSIWYG post editor is nifty although a little troublesome where it comes to paragraph and headline formatting (it reminds me a lot of Microsoft Word in that regard).

By far the most impressive feature though is the post preview window. Click the image below for some Hofstadtery goodness:

It shows you how your post will appear on your site, using the theme you have installed. That’s a pretty piece of web programming.

I remember doing a “corporate preview” page for my previous company. Basically all we did was recursively call the rendering engine from the target page, regex the hyperlinks into dead underlines, and spit it out. It worked, but it was mighty ugly, and the HTML it generated would make your eyes bleed. Times have changed.