Follow

©2018 BY ERIK ON MEDICAL INFORMATICS.

Deterministic and Non-Deterministic Software Developers

July 15, 2018

Long Ago

 

I worked on a project to track and characterize bio-samples. My development team was in Pakistan and the time difference presented the usual challenges. This was slightly before the Scrum/Agile fetish had achieved full pscho-penetration and, as is still my preference, the team lead and I negotiated our own development process. This process involved a detailed functional specification which I wrote up front and (hat tip Spolsky) acted as a contract between me and the dev team. The tech lead, who was competent, chose several of the Rational Unified Process artifacts and one of the several overly complex java stacks that were fighting for hegemony at the time.

 

For any of my zero readers who are familiar with off-shore development, let me assert- in that context that things went surprisingly well… for the most part. The spec described fields in which users could enter data and those fields appeared in the UI and faithfully recorded the contents of those fields to the database. Later, those fields could be repopulated with the data from the database and displayed to the user. Bio-samples could be created, child samples created, and their storage slots saved. The performance and reliability of the system was good.

 

But there was one critical feature of the system they could never implement. I needed the ability for users to create custom data entry fields and insert them wherever they wanted within the otherwise static UI. These had to be configurable (i.e. not require java coding) and changeable over time. Users might want different fields available depending on the sample type and disease the patient had. The data structure had to remain the same for every customer.

 

In my spec I wrote a good description of the most primitive way of meeting these requirements. The data structure would essentially be key value pairs with some some additions for lab value/units and places for standard terminology codes. This was the simpleton’s first version so I was surprised that my otherwise quite impressive tech lead could not grok it. I think this was a source of embarrassment to him so he kept punting. He would negotiate to delay it to the next release and then we would discuss it again, he would fail to understand and kick the can get kicked down the road a little further.

 

We never added this feature.

 

Punchline: There are two kinds of people

 

Software gurus, loudmouths and other opinionators are forever dividing programmers into groups to help you select the good ones. Actually a lot of it is just them explaining who the good group is so you and they can smugly believe you are in that group. “Good software developer” is a slippery concept, and though I would not want to be cursed with the overwhelming majority of people who call themselves developers, I do believe that different kinds of competent-to-good developers are appropriate for different kinds of projects.

 

A distinction that has been on my mind recently is illustrated above. Some developers are great at developing to a very exact spec. That spec needs one to one correlations and traceability from static elements in the UI to static elements in the database. These developers actually can work agile, but the product must be static in this way. Its the kind of system that one could be confident he has thoroughly tested because all the potentiall states are understandable and predictable.

 

Other projects are more dynamic and chaotic. You cannot write a spec that anticipates all future states of the system because the system itself changes as people use it. You can only give examples of things it should be able to do.

 

To create an exaggerated example: pretend no one ever thought to create a word processor and today in 2018 you have a billion dollar idea…the software that eliminates the need for a typewriter. It’s a typewriter on your computer only much better because it takes advantage of the unique capabilities of the computer. Imagine the power!

 

You take your idea to development team A and they ask what you want to be able to type in this software. You say “anything you can imagine!”. “Can you be more specific? Give us some examples”. So you hand them a New York Times from earlier in the week, and your kid’s latest book report, and this week’s “The Economist”, and a movie script you started and never finished called “Happy Valentines Slay”. A year later they return with the finished product and it can type the text and formatting of all of those! Flawlessly! Beautifully! Rapidly! Magically!

 

Then you try to write a letter to your mom. “Dear mom,” you type on the keyboard. Because you are a hunt and peck typist you don’t look at the screen until you finish the comma. You find that none of this text is on the screen. You try again. Failure. Hmmm. You pick up the NYT and start typing the headline. It works flawlessly. You grab today’s NYT and start typing a headline. Nothing. WTF?

 

Those developers wrote software that could be used to type the examples you gave and only the examples you gave. You look at the database and find a table called “NYT” and another called “Carl’s child’s Book report” and…you freak the fuck out.

 

You hire team B and tell them what you want. They have all used typewriters and have a good starting point to understanding. Their questions about your spec have more to do with features and characteristics and scope. What is the max and min for margins? How long can your writing be? Which fonts do you want? Do you want the user to be able to use any available fonts? Should we allow color? Should we allow pictures? Should we automatically format paragraphs? Should we have cut and paste? And on and on. At the end of two years this team produces a decent first version slightly more sophisticated than Mac Write.

 

You think I am exaggerating? Both kinds of developers absolutely exist and I have worked with them. Many times. Many, many, times. Team A is not bad, you just put them on a project they were not appropriate for. Team B is good but if you put them on a project in which they had to mindlessly follow a detailed unchanging spec, they would rebel.

 

I’ve been trying to come up with terms to distinguish these two kinds of developers. Once you have words for a concept it becomes easier (or faster) to discuss it and make choices based on it.

 

Spoilers in the title

 

Here is my proposal. Team A are “deterministic developers” and Team B are “Non-deterministic developers”. For any significant software project you need to know which kind you need and hire appropriately. Each will succeed or fail on projects that fit them or don’t.

 

Oh and the reason I think about this so much is because almost all innovation in medical informatics requires non-deterministic developers. And, they are rarer…

Please reload

Our Recent Posts

Please reload

Archive

Please reload

Tags

Please reload