Skip to main content

Hidden Figures - Application Programmers and Data Analysts

In 1928, Webster's Dictionary defined calculator/computer as:

CALCULATOR, noun One who computes or reckons; one who estimates or considers the force and effect of causes, with a view to form a correct estimate of the effects.

 COMPUTER, noun One who computes; a reckoner; a calculator

Today, it defines it as:

CALCULATOR, noun  one that calculates: such as 1)
a usually electronic device for performing mathematical calculations 2)
a person who operates a calculator
COMPUTER, noun  a programmable usually electronic device that can store, retrieve, and process data

I can't help but ponder the term "AI Programmer"

If I search for AI Programmer today; it links me to Programmers who specialize in artificial intelligence (AI). But, as we discuss the rise of the AI bots taking peoples jobs; it seems most obvious that the jobs they will take will be those of application programmers, not of doctors, or lawyers.

IBM pushes the idea that Watson went to medical school by ingesting all known information about medicine. Yet, they apparently didn't send Watson to school for computer science. Why not? 

Could I hire an AI Programmer? Not a person who programs computers to do AI but an AI being that writes application programs. No, I can not; I looked; none available for hire/purchase. Can't hire an AI Data Analyst either - at least not an AI bot that analyzes whatever I want them to analyze.

Before Y2K, application programming was dead because we were all going to be business analysts using CASE tools and 4GL languages/tools in the early 90s. Yet that died with the rise of languages based on C, a systems programming language at the time, not an applications programming language. So now we have a very large amount of code supported in languages like C++, java, and C#. So, we got more techie not less techie over the last three decades.

In fact, writing applications has become more difficult over the last 30 years, not less difficult. That is the primary reason organizations with application developers have more of them today than they did 30 years ago. This is despite a post-Y2K premonition by most IT pundits that application programming was dead. After all, everyone moved off of custom applications with competitive advantages and moved onto the same packaged software as everyone else. So why would you have application programmers? The same reason they had custom enterprise software prior; to gain a competitive advantage.

Why did Watson study Medicine and not Computer Science?

So now, do I believe application programming will not die but instead the job will go to an AI program that will follow my directions and cut out the application programmer as a middleman? Well, I have to come back to why didn't IBM have Watson go to school for computer science instead of medicine. Did they just want a doctor in the family?

I'm thinking that AI just isn't there yet. What people are calling artificial intelligence and machine learning (ML) are nothing more than the same old predictive analytics and decision trees we have had at our fingertips for decades. The tooling they put around it is just to compensate for the fact that we made everything harder when we moved off CASE tools, 4GL, and even business oriented 3GL languages and used systems programming syntax for application programs.

Watson is no JARVIS

The only way one can interpret this is that Computer Science is harder than Medicine. Watson went to medical school because all he has to do is provide guesses based on symptoms of what a diagnosis is likely to be. This has some value probably for real physicians in considering rare diseases - but it isn't putting anyone out of a job.

When it comes to jobs; why is Tony the only one with a JARVIS? If everyone has a JARVIS, and JARVIS has robots, what to people do? I look forward to a day when I can work alone in my mansion like Tony Stark and just tell JARVIS what I want and when I agree it looks like he did it, I say "deploy it" and it is now doing my bidding. However, the reality may look more like "Ready Player One" where everyone is poor except a very few and the masses just play games and collect welfare because apparently AI and robots do all the work. 


Competitive Advantage from Technology

Until JARVIS comes along, I am building the next generation of healthcare solutions with my team that enable providers and payers by automating the hard work of healthcare data analytics. But, it isn't AI or ML. It is just good analytics practices coupled with standard interfaces and an easy to use user interface, to ease a labor intensive job, of data acquisition & shaping in healthcare, that is outside the core competency of the user (a healthcare worker). Because that is how we minimize the writing application code (analytics code) inside healthcare organizations and rapidly produce the information needed by human managers to improve outcomes. Both of those result in reduced healthcare cost and improved outcomes for the price.

My role in life may be to replace IT/analytics labor at customer sites with apps developed by systems programmers at my company; but that is how technology has always created value. We replace what can be replaced with technology so that those resources can find new opportunities to create new processes. We call it retiring technical debt - replacing what had to be done as a one-off with a common appliance. But, no AI has yet to identify such opportunities and solve for them as application programmers have for decades.


Comments

Post a Comment

Popular posts from this blog

Game Changing Healthcare Information Exchange

Evolving HIE Beyond just replacing the fax machine   HIE can be more of a game changer for healthcare than just being a replacement for the fax machine. The route to being a game changer is to be an enabler of care management. That care management can come from a health plan (managed care organization), an Accountable Care Organization (ACO) like a Patient Centered Medical Home or Medicaid Health Home, or from the patient/consumer as care manager for themselves or as the caretaker of another.   To do this, I think the HIE needs to serve the following customers and their use cases. These are the healthcare providers for care coordination, the care manager in the role of managing care, the care management at a program management or quality improvement level, and the care management at a financial management level.     HIE must Support Provider-Patient Coordination Use Cases   Send patient data between providers This is the primary purpose of the HIE PUSH functionality
3 comments
Read more

eRegister and Get Rid of the Clipboard

The Real Use Case for Personal Health Records (PHR) I have been at this, HIE game, for a few years or so now. And when I go out and meet new people, I get the typical, "so, what do you do" question. Once I tell them and give a little explanation of what it means, about half of them have a follow-up question. There is only ever one follow-up question and it is always the same question "so, are you going to get rid of that clipboard of paperwork that I have to do over and over again every time I go to see a doctor". The fact that I only get one question from general consumers and it is always the same question tells me one thing. This is what matters to them. This is how they see their information making it from them to their provider today. This is what they want to eliminate by using HIE or a PHR. In essence, I see the HIE and PHR as one in the same. The HIE, in a fixed repository model, is a collection of "views" of the patient. We have a primary
8 comments
Read more

Why Direct makes sense for Data Delivery to an EHR Hub

Who precisely are you sending that message to? There is a little recognized problem in using legacy HL7 over VPNs to deliver data (lab results, image studies, reports, etc). The orderer is in the message regardless of whether you are trying to send to them or not. The CC list is in the message regardless as well. The attending, the primary, etc. all there but maybe not who you are routing to. Who are you routing it to? How is this a problem? In today's modern world of Software as a Service (SaaS), many of the EHRs get data delivery through a common gateway for many practices. If you route a message to a single practice with a locally installed EHR, then when the data source (e.g. hospital or an HIE as its proxy) sends a message to the practice, the practice endpoint and the EHR endpoint are one in the same. There is no confusion about who the message is for. When the EHR serves multiple practices is where we get the confusion. The endpoint of the practice is a spoke off of
2 comments
Read more