The Death of Analysis

Analysis, as defined by the wikipedia is breaking things apart and then describing how they fit together. I guess that's a serviceable definition. Too many times when we go to solve a problem, we spend too little time simply thinking about what we're trying to accomplish. Sure, there's an immediate goal: make the web site scale to ten million users, or get the bank accounts so they download to the customers automatically. But how much of the time do we just launch into the solution without really trying to understand the problem?

I'm not talking about gathering requirements. Most in the corporate world are getting better about requirement-gathering, if for no other reason than self-preservation. I'm talking about taking the requirements and making something new out of them, performing a synthesis. To me, this is the real work of the beginning of a project (In RUP-ish, we call the beginning of a project Inception)

Most requirements gathering I've seen is just glorified order-taking. We sit with a notebook computer or pad and take down all sorts of notes about what the customer wants the program to do. How can we go wrong there? People tell you what they want, you write it down.

But that provides little value to the customer, in my opinion. To really provide value, you need to join in a partnership with your customer to discover features and needs that neither of you knew was there. It's a "journey of discovery" (as much I hate that phrase, sounds like a Discovery Channel show, "Jouney with us now into the darkest of African use-case jungles...")

(Climbs down from soapbox) I'm sure we'll hit this again later.