If doctors would work like software engineers, no-one would consult them

When I woke up this morning, in the vague state of my barely booted mind a thought popped up: we software developers bicker and debate almost solely about procedure, never about diagnostics and which solution to apply to a given problem. It looks like what's really important about what we do is how we create solutions to problems, not about finding out what's wrong in the first place. For doctors things are precisely the opposite: they first and foremost try to get a diagnose what the problem is, what causes it and with that information they pick a solution which is known to fix / cure the problem found with the patient. No diagnose, no cure.

As a software developer you might hate this, but your job is to write software which sole purpose is to fix a problem. You might think: "yeah right, I write frameworks, pal, I don't deal with our clients directly, nor their petty problems". But there's a reason you write these frameworks: someone has a problem and your framework solves it. For this article, however, I want to focus on the majority of developers who write software for clients, non-developers, not the small group who write software for other developers, although the idea is the same.

Let's do something radical, let's see the client you're writing software for as a patient who has some sort of medical problem and let's see you as a doctor. If you have never been to a doctor for anything, this might be a little problematic at first, but I hope it will still be a valuable read. Ok, so as a doctor, you're a person who can potentially cure the patient or if you don't know what's wrong exactly, point the patient to a specialist who might. The patient makes an appointment with you and when the patient sits down into your office, what is the first thing you'll ask? Think twice before you answer, because the reason you ask the question is what's really important.

Likely, you'll ask, as a doctor, "What I can do to help?" or similar question. The exact phrasing isn't that important, the reason why it's been asked is very important: the doctor knows that there are a tremendous amount of possible procedures to follow for a very long list of problems so to be able to choose which procedure, which pill, which surgery for the patient, the doctor has to know what's wrong with the patient.

The first step therefore is to get a good diagnose, and test the diagnose with ... tests, e.g. get an MRI scan. What are the real symptoms of what causes the problems for the patient so the real cause can be taken away with a solution. For example, if the patient tells you that his leg feels numb at times or prickles... you should first look at his lower back, not his leg. This is a difficult process, but very important: a wrong diagnose might result in unnecessary pain or even death for the patient. It's therefore one of the most important things in the whole process towards a cured patient.

Once the diagnose is pretty solid (it's not an exact science, but neither is software engineering) and you are pretty confident what might be the real problem, you can look at what is available for curing the problem(s) you found: give the patient some pills? Some salve maybe? Some therapy of some sort? Or in case you're not entirely sure, you might tell the patient to go to a specialist in the field you diagnosed the problem who can help the patient better than you can.

If you decide to take the problem at hand and try to cure the patient yourself, e.g. by prescribing pills or other medication, you'll do that only if you know that if a patient has that particular problem ABC the medication XYZ works. You don't simply prescribe medication FGH, because, what the heck, it's sunny outside.

To bring it down to simple baby steps, it looks like this:

1. Investigate what the real problem is by interviewing the patient, and/or if necessary the patient's family
2. The results of 1) lead to one or more conclusions. If there's a logical explanation, a firm conclusion, directly proceed with that, otherwise prescribe more tests for further research (i.e. goto 1)
3. Once there's a solid diagnose, look into what procedures are known to lead to curing the problem described by the diagnose and based on what the patient wants / can deal with (or in some countries: can afford), pick a procedure and apply it.
4. If treatment was successful, or the patient died, we're done. If not everything is solved, or it turned out to be a wrong diagnose, we might want to go back to 2 or maybe pick another procedure in 3.

Unless you've never been to a doctor, this might not surprise you: diagnose, pick procedure, apply. Things are more complicated than that in practice, but the idea behind all this isn't: to be able to even pick a procedure for curing the problem, you first have to know the problem, and after you know the problem, it's best to pick the procedure which has the highest success rate for the problem at hand.

"Ok, but what has all this to do with me? I write code, man, not prescriptions."

That's exactly the point: you do write prescriptions, as your client is the patient. You see, the client came to you because he has a problem, whatever that might be. Do we, as software engineers, apply the same care as doctors do, when it comes to finding a solution to the problem of our patient? No. To stay in the metaphor, we'll likely offer some insight in a group of medicine up-front, talk about procedures for a while, especially new ones without any reason at all, as we haven't made a diagnose of the real problem yet, so we can't possibly pick a procedure.

The one thing that's the basis of all the rest of the work that follows, the diagnose what's wrong, is ignored the most. The client, like a patient, doesn't know what's wrong: the client, like a patient, isn't skilled in your line of work, you are. Therefore the client, like the patient, might think he knows what's wrong ("My leg feels numb sometimes") but as he's a complete moron when it comes to medicine (and your client when it comes to software) he has no clue what the real diagnose might be, left alone what the cure might be!

While 'diagnostics' are very important, namely the most important first step you can take in a software project, it's also very important what to do with the diagnose: the diagnose tells us what's wrong, and from the list of known procedures which lead to a cure, we can pick one or a couple and work towards a cure with those procedures. Here it goes wrong in the every-day reality of software development, two-fold:

1. Our diagnoses for the problems we have to solve for our clients are sub-par
2. We don't have a well known list of solutions for known problems (some problems have known solutions, but even those are often ignored)

Most of the time, what we do is simply what the client asks us to do. "I need some piece of software to do ABC", and a piece of software that does ABCD is written (no typo). We don't try to diagnose what the real problem is of the client, we simply do what we're asked to do. If you as a doctor would react like that on the patient's claim that his leg feels numb sometimes, you'd never be able to cure the patient: the cause is likely elsewhere, not in his leg.

The second point, that there's no known list of solutions for known problems, is first a result of bad diagnostics and also caused by the fact that software developers think they're dealing with problems no-one else has ever dealt with. If you as a doctor would act like that, you'd perhaps cut open the leg of the patient to see why it would feel numb, thinking about how to cure this numbness along the way, as you're the first human who's trying to cure this, ever. I hope you have insurance.

Instead, software engineers debate about procedures for problems unknown, about tools without knowing whether the client needs those in the first place. I hardly, if ever, see or overhear a conversation between software engineers about how to diagnose properly, and which procedures to follow if the diagnose shows signs of A, B and D ("use C!" ;)). Which is strange, if you think of it, as we ignore what's most important: diagnosing what's really wrong and picking a known solution to the problem we properly diagnosed.

After all, every day, software engineers try to solve problems for clients which are might look unique but in fact aren't that unique that they're totally unique problems. Like with patients: every human is unique and the range of things that can fail or get infected or otherwise cause problems is so wide, combined it would make every illness a unique case, but they're not that unique.

My wish is that we, as software engineers, focus more on diagnostics and collect more 'problem -> range of solutions' kind of knowledge, so the overall result of what we do will be of higher quality.