Well, You've Just Got an Answer for Everything, Don't Ya?

July 27, 2018

“Well, you just got an answer for everything, don’t you?!?!?!?!”


This was the ultimate response from a gym teacher, drill sergeant, or any other stereotypical knucklehead authority figure. He asks you questions, and instead of knowing your place and falling in line, you make the mistake of thinking you are engaged in a lively debate. Ah the give and take! The thrust and parry! The glory of a point well argued and two reasonable men agreeing to ... of course you aren’t, but a smart kid is too stupid to know that.


It used to strike me as unfair. I mean, what kind of response is that? I have cogent reasoned counterpoints to any of your arguments about doing shuttle runs, and you say, in essence, the fact that I have good points you can’t refute, is a fundamental weakness to my my argument? WTF?


But, as an adult working in medical informatics with the average developer I…it pains me…I kinda get it.


See,  smart kid can refute each of gym teacher’s points in isolation. Any objection can be met with a reasonable compromise or solution. But smart kid is missing the big picture which is: this is gym class, do the fucking shuttle run!!! Is there a reason behind it? Am I better off for having learned some physical skills as a teen? Probably? If we ask “why” too many times in a row eventually we have to admit that life is pointless and there is no Vulcan logic to explain why you should ever get out of bed. That got dark. Why did Mr. Spock get out of bed?


Better lighten the mood and get back to ragging on software developers who think they know informatics.


This comes up when I try to convince the developers that we need to create a domain model of the parts of medicine upon which we are softwaring so hard. They cannot create such a model, and react with suspicion, but when I volunteer, it turns out that it's their job and me doing the data modeling would be a blow to their  self esteem. I guess.


“Why should we do a data model of everything up front? What can we not do with the transactional screen reflecting model we are making, that we could do if we had your fancy domain model?” (“smart guy”, in the vocative, is implied)


This is a trap. Every example, in isolation, can be answered. 


“Travis needs the the receptor status to check against guidelines.”


“We have lab results in our model.”


“We need an easy way to query for a positive result and your model has no way to standardize the different scales and ways that they are reported.”


“Then that should have been a requirement. That’s product management’s fault. ”


Ah-ha! The problem was the improper requirements statement. Inadequate requirements! The ultimate developer pushback to the product manager to explain why he can’t do something reasonable with the software! "It’s your fault. How would we know that it should do that? We are not domain experts."


Well, I guess you just have an answer for everything.


They do. Developers say “Tell me what the software has to do; don’t tell me how to do it”. Later they say “you never told me it had to do that”. Check mate. And, in addition, bull-fucking-shit.


In ancient times, before the fetishization of agile development, we used to write detailed (I mean excruciating) requirements up front. The product manager (who was called something else back then) had to think through very thoroughly everything this software might need to do someday and put it in the document. If he failed to mention that a user needed to log in, a developer was within his rights to fail to include a login screen.


Agile blows this away. No detailed up front spec means that the product manager and developers both have responsibility to make sure the software is complete and behaves reasonably. Developers demanded the extra responsibility. They hated being mindless requirements/specification implementers. They had creative minds, and if we set them free to innovate they would surprise us with something better than we specified.


This is true…for a small percentage of developers. It doesn’t matter. My thinking is- once you refuse the detailed requirements and spec, you can’t use “it wasn’t in the requirements” as an excuse anymore.


That’s a rant. Developers will never agree, so let’s proceed as if that is a fair response to my desire to have a data model that can be reused for other purposes in the future.


If we follow the inevitable argument, the agiling would go something like this:


“We need a domain model so we can reuse data in the future”


“Re-use, how?”


“You know, like for analytics and stuff”


“what kind of analytics?”


“I dunno, any kind. I want to be able to do anything


“that’s not a requirement; Too non-specific. How would I test that? Give me some examples”


“Uh, I want to be able to analyze the record to see how close a patient is to being on a guideline”


“How would that work?” 


Here follows several days of showing the developer a wide variety of guidelines and step by step analyzing the data we would need to compare a patient record to them.


“That was a lot work. So what else would you like to reuse it for?”


“Well, maybe some machine learning?”


“That’s not very specific. What kind of machine learning?”


“How about if I want to predict whether a heart failure patient was going to need to go to the emergency room?”


“How would you do that? Which data would you need?”


“Well, it’s tough to say. That’s kind of the point of machine learning. You don’t know what the patterns will be in advance...”


“Can you at least give me examples?”


If anyone is actually reading this post, feel free to pause to gouge your eyes out with the nearest spoon.


My point is, once I agree that the developer deserves every possible data re-use scenario up front, I have already lost. This enumeration of distinct examples could go on forever. And if we had forever, we still have the limitation in my ability to predict what other people might want to do with it. 


That’s the point; I want a system such that: if users think they are collecting a kind of data, like lab results, and they later want to do some kind of analytics that a reasonable person would think he could do based on his belief that he had been faithfully entering such data well….




In an agile development environment that is a legitimate requirement, just not in all-caps. No developer I have worked with can handle that alone.


What becomes apparent, when you get far enough down the rabbit hole you decide you’d better turn around, is this: 


It is far easier to create a domain model which reflects the real world of medicine, than to state in advance every specific data reuse scenario anyone would ever want to do.


In fact, creating such a domain model is an absolute pre-requisite for such a software system so you might as well jump right to it and quit your belly aching. Of course the average developer can’t do that. Nor should (s)he be expected to. That’s why you hire someone who can.


Please reload

Our Recent Posts

Please reload


Please reload


Please reload