Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

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 4×4 event. In short, the 4×4 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.

This entry was posted in Agile, DDD, management, opinion, user stories. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

14 Responses to Doctors We Ain’t

  1. Phil says:

    Analogies aren’t meant to be exact comparisons down to auxiliary and edge cases, and doing so is really unfair to the person who first made the analogy — it’s like quoting someone out of context. You acknowledged something along these lines in the comments above so I’ll drop it there.

    I think most here are in “violent agreement” but dealing with semantics. There’s a difference between “want” and “need” and it’s our jobs as consultants to take the “wants” and extract the “needs”. In my personal experience, 90+% of the time you get what the client “wants” rather than “needs”. A few of the comments above allude to this fact as well.

    If you leave the original analogy as simple as it was originally stated — “I’m in pain, I need pills”, then the analogy is valid. Surely when a client walks up to you and says “I need a widget right here in the middle of this screen” you don’t just walk away and assume the client knows the *need* it there, do you? I would hope that you ask why and try to determine what the need behind the want is.

  2. @Dave, I understand your point. And as “technical” people, we do as a group tend to have a bit too much of a paternalistic attitude all to often, toward those less technical.

    However, I also agree with Steve Smith here, and I think he expresses what I was attempting to say much better than I did.

  3. Steve Smith says:

    @Dave,
    I think you’re correct that the in-the-trenches developer should be thinking tactically. I think Palermo and David Platt really are talking more about the higher level developer/analyst, the one with the most interaction with the customer and/or domain expert, or the project lead. Not to put words in their mouth, I’ll use my own. If you’re a consultant and you’re going into a client and they say “we need you to build us a sharepoint application so we can do X” one of the first things you should be thinking about is “what they really want is something to do X and they seem to think sharepoint is the way to get there, but I should learn more so I know if that’s the best solution.” That sounds an awful lot like the doctor with the patient coming in saying “Doc I feel like X and I heard on the internet that Y drug fixes that, can you get me some?” and the doctor’s job absolutely should be to think “The patient presents with X so let’s ask a few more questions to make a good diagnosis and then see if drug Y is a good fit or perhaps something else altogether”.

  4. Dave Laribee says:

    @Chris – Maybe it’s not so much the doctor analogy as it is “clients don’t know what they need.” I’m sorry, but that attitude strikes me as paternal or obtuse.

    Customers should/do, in fact, know what they need done. If they don’t and we’re developing software for software’s sake, well, I feel taking that work would be ethically objectionable. Now if we’re hired to analyze their business for them, another story, but that certainly isn’t a developer’s role other than on a very tactical and per-feature scale.

    It might be the role of a product owner or analyst who has the background of a developer, but to say that developers are doctors and that doctors as depicted in the context of the referenced post? Again, I disagree.

  5. I have to say… I’m not entirely sure that what you’re saying, Dave, is much different than what David Platt is saying.

    Certainly a patient knows what he wants to get out of a visit to the doctor. He wants his pain to be relieved, or he wants his rash to go away, or he wants his vision saved, or he wants his broken arm mended. And while some think they may know what medication or surgery will resolve their health concern, they very rarely, in reality, know what the precise solution truly should be.

    This sounds very much like what you’ve described in your business software scenario.

    > 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.

    This is a bad counter-example, because it’s a bad example of the medical sector… Or rather it’s an example of an instance in which the doctor/hospital is failing in its purpose.

    On the contrary, a team of _good_ doctors is no less attentive and collaborative with their patient than we should be to our clients. A good doctor listens to the patient’s symptoms, needs, and fears, additionally considering factors that the patient has not vocalized or may not even be aware of. They then includes the patient in the process of choosing a solution, explaining why the treatment the patient may have originally asked for is not satisfactory, or not appropriate, or even dangerous, as well as what the different benefits and risks of the doctor’s proposed solutions are.

    So again, I’m not certain how this _good_ doctor example is much different than your description of how a _good_ software team operates.

  6. Paul,

    Building a complex application that’s expensive to develop and never really works right in the end is the only real cause of ending up with a complex application that’s expensive to develop and never really works right in the end.

    A fuzzy understanding of the model of the domain is one input, albeit a significant input. Any number of imprecisions can make things come out less than than optimal. A project where everybody has a good understanding of the model of the domain can still fail.

    A client doesn’t need to have an understanding that is good enough to develop good data structures and operations. Programmers are biased to seeing the world through programming idioms – a fish in water. It’s not entirely relevant for a customer to see the world this way.

    The end result of knowledge crunching doesn’t have to be code. In fact, the best result of analysis and design is to find a way to avoid building software.

    I understand that you’re saying that architects and developers have a hand in ideation, but we do a much better job of this when we move our awareness up and out of architectural and development predispositions.

  7. Dave,

    Yes, that’s my conclusion as well. It points to the need for proficiencies beyond the manila agile analysis stuff, but not exclusive of it.

  8. Paul Houle says:

    @Max,

    Maybe I’m more like a dentist.

    I’ve found that a lot of clients strongly resist the formalization of their process to the point where it can be turned into simple and reliable code. It’s kind of like pulling teeth.

    When it’s done right, clients will be delighted with the results, but it isn’t always easy to get there. Most clients understand their domain well, but they understand it in a “fuzzy” way — not good enough to develop good data structures and operations on them.

    Trying to build an application based on a fuzzy model of the domain often results in a complex application that’s expensive to develop and never really works right in the end.

  9. Dave Laribee says:

    @Scott – So let’s get collaborative, all on the same team, all working to pull, etc.

  10. Jimmy,

    The perspective of architects and developers extracting the need is still a perspective influenced by the biases of an architect or developer’s experience and mind. It’s a fish in water not realizing that he’s in water because it’s all he’s ever encountered. You will see what you do as extracting the need if that’s what you perpetually do.

    There’s a need, and customers often jump to conclusions about the solution, and architects and developers are just as good at jumping to conclusions about the need as they perceive it.

    There’s an even greater need to break out of the confines of our own sense of reality and see if there’s more to the world than water. It’s from outside the confines of either a customer or an architect where we find the right solution. Everything in between is merely a stop-gap, and in the worse cases (and most cases) neither the customer nor the architect are aware of this.

  11. Dave Laribee says:

    @Jimmy – I agree with part of what you’re saying. Ideally a customer knows what they need. What’s the opportunity or problem? In real life I think the five whys is a good approach, but it certainly isn’t the approach of the medical system (at least in the U.S.). I’d say, too, we need to be a little more humble in how we collaborate with customers and a little deeper in our analysis. This would lead us to 5 whys over something like, say, Socratic method.

  12. Jimmy Bogard says:

    Users know what they want, but not necessarily what they need. Giving users what they want is sometimes the quickest path to failure. Often, we as consultants have to extract the actual business need, which the customer doesn’t always know.

    Often, the customer jumps to solutions, without fully exploring the problem themselves. Often they don’t even know what the problem is. We guide them through the “five whys”, so that everyone is on the same page what the root business need is.

    It’s not that Architects or Consultants have the answers, but it’s often their job to extract the answers from the customer.

  13. We need to evaluate and analysis what our stake-holders ask for.

    Many stakeholders are used to providing design-level details in what they ask for. Sometimes what they ask for will work, sometimes it won’t.

    Coming at it from a more Agile approach, where you are constantly (or frequently periodically) communicating with the stakeholders you can circumvent these requests and not notice as much that sometimes what stakeholders ask for isn’t what they really want. Coaching them through writing user stories is an excellent way to avoid issues like this.

    I don’t agree with Jeffery’s comment that “…we can’t expect our clients to know what they need”. You’re right, clients know exactly what they want to do with the software you’re going to build for them. But, I do believe clients don’t know how to communicate what they want that software to do by themeslves

    It’s our job to coach them through the process. Initially this is done through conversation, documented as user stores. Further into the process this communication will include demos, frequent usable software, etc. If someone is finding after doing all this they’re still of the opinion that user’s don’t know what they need then they’re not approaching Agile properly.

  14. Max Pool says:

    I whole heartily agree that the Doctor analogy is a poor one.

    One of Steve McConnell’s developer sins was assuming you know more about the domain than the client.

    I view us more like psychologists. We can never fully understand exactly what we are dealing with, but we can however facilitate communication which will eventually allow the client to “self-diagnose” themselves.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>