This morning I stumbled upon an old document which was meant to be a published article. It is more than a couple of years old, but has aged pretty much ok, even with the AI "revolution".
Here it is:
Let me tell you a story.
A long time ago I was called on a job interview. The company was small and unheard of, but size & popularity were never my criteria. First I talked to the CEO. He was a likeable guy and we were on the same page. Then I talked with the tech guys. There was an architect and two senior devs. We talked a bit. They all seemed an OK crowd to work with. Until I brought up the subject of tests. At that time I was beginning to warm up to the concept of automated software tests, written by developers. The company I worked for at the time had a healthy culture about them and they were seen as a useful tool. But these guys scoffed. The things we’re doing, they would be really hard to test - they said. Their software was embedded and it talked to other proprietary software which in turn talked directly with the hardware. I brought up the subject of simulators they could make to put in place of the lower-level software so they could get the tests to run on a regular computer (meaning - the computer they used to build the software on), but they dismissed the idea as too complex and not worth the effort. Oh, what did the hardware do? Light control in traffic systems. Tunnel lights, highway warning displays and so on.
A year or two later I was getting into Agile, reading and watching everything I could get my hands on which seemed to fit the “Agile mindset”. I came upon this blog article by Robert Martin. As I read the first few paragraphs I got goosebumps. I knew what he wrote was real. I sat at a table with the developers he was talking about. The tunnel lighting people. What could go wrong with bugs in software responsible for tunnel lights & highway warning signs?
I looked up from the blog. How prevalent is that “hacker” mindset? What proportion of developers don’t find it worthwhile to write tests, or indeed apply any other discipline to increase the quality of their code and process? Judging by the stuff I read & people I met through the years, that proportion is pretty high.
Fast-forward into today. I’m in a company which I picked for a number of reasons, one of which is that nobody questions your methods if they produce high-quality software. High-quality meaning tested, readable, well-structured, easy to reason about, easy to modify and build upon. Being a small startup we didn’t get to pick what projects we will work on. This is evident by the diversity of the business domains of our projects. We didn’t plan to get into healthcare-related software development, but somehow a couple of healthtech projects fell into our lap and we took them on.
What is the most important goal in healthtech? To make money? To have the coolest UI? No. The most important goal is to avoid hurting a patient by accident.
How can you hurt someone with healthtech? Oh, the list is long and it's very late, but let me roll a few off the top of my head: Presenting slightly wrong data, mixing up patient records, mismatching medication, miscalculating dates & times … each of which could lead to a doctor to reach a wrong diagnosis, a nurse applying a wrong treatment or a pharmacist giving the wrong drug. Software is dangerous, you know.
But why would you write software which does that? Don’t you know what you write?
Sure, in the beginning. The start of any project is ideal & rosy. That’s why developers love rewrites (or at least to wish for a chance at one). The cruel truth is that after a month or two things begin to smell like the stuff you wanted to rewrite. Software is hard. Keeping complexity out, or at least letting the smallest amount of it in requires a lot of practice & skill.
I mentioned testing above but in my experience automated tests written by developers don’t even begin to scratch the surface of the problem of software. To get well designed software you need test-driven development, continuous integration & delivery, merciless refactoring, code review or (better) pair & mob programming. Those are some of the technical practices, which won’t cover it. You also need an on-site customer (or at least continuous communication with one), proper vertical story slicing and more. It all sounds crazy & inefficient but it is actually going to save you a lot of time, money, nerves and well-being.
The stakes can be high in most software - keeping customers, getting costs down or profits up, etc. But in healthtech the stakes are even higher. Here we really can’t afford to muck about.
