Doctors We Ain't

Time for a little bit of a rant.

In a recent post, Jeffery Palermo paraphrases an analogy made by David Platt on a recent episode of the .NET Rocks podcast:

In software, we can't expect our clients to know what they need. Much like the depth of a patient may be "I need to get rid of this infection" or "Give me some pills. I'm in pain". Our clients know what is causing them pain, in the business sense, so the problem is from that experience perspective. Some clients might go so far as to ask for some "pills", that is, they might ask for a specific software system that is assumed to solve the problem.

I have to disagree.

There was a time where I would agree with this statement, but implementing practices such as a weekly demo, an acceptance testing environment, and user stories actually written by the user drives my issue with the notion that software developers and architects have all the answers.

Users Definitely Know What They Want

It's not like user's don't know what they want; they do. Damn straight stakeholders know what benefit they expect from a software engagement. When they don't we're practically cruising toward an unsuccessful outcome where the inmates (developers) are running the asylum. They know how their business works better than you do. They likely don't know how to get what they want. If the purport to, then you probably have a problem on your hands. In my experience, this is rare.

The Domain Expert

And what about the method Domain-Driven Design puts forward? A domain expert -- often a user of the software -- is the best resource for understanding complex business logic. They'll tell you the what and we figure out the how. Of course with a practices like model-driven development (where model == code), DSLs, and BDD we're bringing our code ever closer to the user.

If you don't have a domain expert or your expert is unwilling to spend time with you, that's a risk in your project. You'll see the doctor analog, but I'd caution bringing that template in as a norm. It's a risk and a sub-optimal situation. Fight for your right to talk to the domain expert! Build a relationship there.

The ToC Approach to Software

Eli Goldratt discusses the role of software initiatives in a lean organization in a presentation available on Audible. One of the processes in ToC is the 4x4 event. In short, the 4x4 is a meeting involving business leaders where constraints and conflicts are identified. It's a time used to identify problems with the system as a whole. One possible result of this meeting is to launch a development project that provides the minimum possible product to exploit and/or protect a capacity-constrained resource. Think the folks putting money down know what we want there? You betcha.

So What Are We?!

In one respect we're cartographers. We're there to take the business need and convert that to working code, ideally on a regular basis. In another light, especially in product development, we're stewards or politicians. It's our job to take multiple inputs from multiple customers and introduce features in a way that satisfies our constituencies. The big risk in this context is, of course, re-election.

A doctor-patient relationship is a very particular pattern of human behavior. How many of you have been rushed through a doctor's visit or had the "privilege" of a visit with a hot-shot specialist? I know last time I was in the hospital (for a wrist surgery, RSI) I spent about four hours waiting around.

I'd advocate a more collaborative approach. Users do know what they want. Developers need to raise their game to collaborate with them to show them how to pull product. We can start by taking some time and showing them how to write a user stories, for example. We want to establish a relationship with the users of the software we make (their software!), walk a mile in their shoes, and expend the effort to better communicate by forming a peer relationship.

Source Click Here.