4 ms·

Doctors hate their computers because the software they are forced to use sucks. And it sucks for the same reason that most enterprise software sucks: because t

by cs702 6y ago

Doctors hate their computers because the software they are forced to use sucks. And it sucks for the same reason that most enterprise software sucks: because the people who budget for it, choose it, and pay for it are not the people who use it. For more on this, see this now-classic Twitter thread by Princeton CS Prof Arvind Narayanan: "Why Enterprise Software Sucks" https://twitter.com/random_walker/status/1182635589604171776 https://twitter.com/random_walker/status/1182635589604171776

kube-system 6y ago
To be fair, the people who use enterprise software typically only understand a single-digit percentage of what the software needs to do, at best. If you asked them to design it, you wouldn't get a better result. To properly architect enterprise software, you need to capture the competing needs and goals of hundreds of different roles in different departments. You will uncover underlying political and organizational issues that you will need leadership to sort out before you can ever start to determine the business-logic. To be successful, you have to be an expert at playing politics, business analysis, and mediating conflict. I wouldn't say "enterprise software sucks"... more like, the lack of cooperation in many organizations sucks, and enterprise software puts a big spotlight on it.
- dragonwriter 6y ago
  > To be fair, the people who use enterprise software typically only understand a single-digit percentage of what the software needs to do, at best. If you asked them to design it, you wouldn't get a better result. Sure, users don't know what a system needs to do to meet their needs, but if you had modestly competent business analysts work with them to specify the system, you'd have good results.
  - tuatoru 6y ago
    Exactly. The role of systems analyst (nowadays confusingly called business analyst) seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs. Turns out neither of those beliefs was true, and systems analysts are needed. With the passage of time the role has largely been forgotten.
    - dragonwriter 6y ago
      > The role of systems analyst (nowadays confusingly called business analyst) Classical systems analysts were, as I understand it, usually the more experienced programmers on a project, and had a role that combined the more recent technical architect and business analyst roles, so they aren't interchangeable with BAs, who often are nonprogrammers, and in any case are viewed as less technical than developers. > seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs. In theory, the kind of requirement that is the role of a system or business analyst in other development methodologies seems to be largely shoveled into the responsibilities of the omnicompetent development team in Agile methodologies, though some of it also seems to fall into the product owner bucket in methodologies with that role. I do think that that the requirements elicitation and analysis skills that go with that role have become undervalued because there is an idea that incremental iteration means you never need to look at requirements in a structured way. I don't think this is even approximately correct, but it seems to be the thinking.
  - kube-system 6y ago
    That'll get you part way there -- but for a truly enterprise-wide deployment you also need analysts with deep cross-divisional understanding and some degree of cross-divisional political capital. Often, organizations that try to do this internally have their business analysts inherently shackled to a specific department or division by nature of the org chart. It is the interdepartmental conflicts that are the hardest to mitigate. This is one of the lesser-spoken reasons that higher-ups call in consultants -- they have a better ability to short-circuit the org chart and haven't been around long enough to piss off that one director, Karen.
ChrisMarshallNY 6y ago
I love that Twitter stream! Thanks so much for sharing it!
pavon 6y ago
To expand on that EMRs, much like SAP and other enterprise offerings aren't so much fixed pieces of software as ridiculously flexible frameworks for making software. And the people deciding how to configure Epic, and deciding how the doctors and nurses need to use it aren't practitioners, they are administrators who are making decisions for bureaucrats reasons, CYA being high on the list. Anytime an accident occurs, rather than understanding why it occurs, the solution is always to add more administrative controls, to record more details in the chart, more busy work to do that makes each step of the process take longer. As a result, the number of things that practitioners need to enter into EMRs keeps growing, and every year they spend more and more time charting. This in turn decreases the signal-to-noise ratio of the information in the charts, resulting in the practitioners getting less information out of them despite the fact that more information keeps getting put in. Which results in more accidents rather than less.
- nednar 6y ago
  Most people don't know that always writing tickets, even if they get refused and ignored, will have an impact. Your goal is not to convince level1 support to be your friend, but to turn the statistics into a way that forces administration to consider your concern. So always write tickets and encourage your colleagues to do the same. And if they get ignored make a screenshot and send it with the headline "lol, got refused again" to the watercooler mailing list and laugh about it together.
smabie 6y ago
Also the devs who write the software never actually need to use it. Developer tools such as editors and compilers are of high quality (relatively, of course) because developers use these tools while working on said tools. Many developers doing enterprise software don't even have a rudimentary idea of the work flow around the app that they're developing. Consequently, they are unable to design an effective and efficient app.
conanbatt 6y ago
That's not really true. There are open-sourced EHMR's, consumer-facing emrs and in-house built EMRs. They all suck, and there are many reasons for it which are not this one.
nednar 6y ago
Yes and no. People can force software on your office computer but not on your private laptop, tablet and raspis. And even on windows computers you will find ways to install software without admin rights (e.g. Putty doesn't need any admin rights). Therefore I would argue the main thing missing is a desire to conquer the computer as a tool, a tool that might save hours of work time, that might help analyse problems more efficiently than a human brain can, that can help outperform one's colleagues. With a desire to conquer the computer, open source, and exchanging knowledge online, actually many private enthusiasts who can't afford medical care or won't get the right one can already help themselves. And they have not studied as long or hard as most medical people do. I.e. a doctor with the right spirit should be able to achieve a lot more than such hobby enthusiasts. And with that passion and knowledge the medical community as a whole would slowly also force better software into their work environments. They know how to hold conferences and argue with facts. It's hard to blame others if you belong to one of the smartest tribes on the planet.

by cs702 6y ago

kube-system 6y ago

To be fair, the people who use enterprise software typically only understand a single-digit percentage of what the software needs to do, at best. If you asked them to design it, you wouldn't get a better result. To properly architect enterprise software, you need to capture the competing needs and goals of hundreds of different roles in different departments. You will uncover underlying political and organizational issues that you will need leadership to sort out before you can ever start to determine the business-logic. To be successful, you have to be an expert at playing politics, business analysis, and mediating conflict. I wouldn't say "enterprise software sucks"... more like, the lack of cooperation in many organizations sucks, and enterprise software puts a big spotlight on it.

dragonwriter 6y ago
> To be fair, the people who use enterprise software typically only understand a single-digit percentage of what the software needs to do, at best. If you asked them to design it, you wouldn't get a better result. Sure, users don't know what a system needs to do to meet their needs, but if you had modestly competent business analysts work with them to specify the system, you'd have good results.
- tuatoru 6y ago
  Exactly. The role of systems analyst (nowadays confusingly called business analyst) seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs. Turns out neither of those beliefs was true, and systems analysts are needed. With the passage of time the role has largely been forgotten.
  - dragonwriter 6y ago
    > The role of systems analyst (nowadays confusingly called business analyst) Classical systems analysts were, as I understand it, usually the more experienced programmers on a project, and had a role that combined the more recent technical architect and business analyst roles, so they aren't interchangeable with BAs, who often are nonprogrammers, and in any case are viewed as less technical than developers. > seesm to have largely vanished in the beliefs that either COTS enterprise software would be used as it came, or that users know what they need (as opposed to what they want) and can rationally set priorities and tradeoffs. In theory, the kind of requirement that is the role of a system or business analyst in other development methodologies seems to be largely shoveled into the responsibilities of the omnicompetent development team in Agile methodologies, though some of it also seems to fall into the product owner bucket in methodologies with that role. I do think that that the requirements elicitation and analysis skills that go with that role have become undervalued because there is an idea that incremental iteration means you never need to look at requirements in a structured way. I don't think this is even approximately correct, but it seems to be the thinking.
- kube-system 6y ago
  That'll get you part way there -- but for a truly enterprise-wide deployment you also need analysts with deep cross-divisional understanding and some degree of cross-divisional political capital. Often, organizations that try to do this internally have their business analysts inherently shackled to a specific department or division by nature of the org chart. It is the interdepartmental conflicts that are the hardest to mitigate. This is one of the lesser-spoken reasons that higher-ups call in consultants -- they have a better ability to short-circuit the org chart and haven't been around long enough to piss off that one director, Karen.

ChrisMarshallNY 6y ago

I love that Twitter stream! Thanks so much for sharing it!

pavon 6y ago

To expand on that EMRs, much like SAP and other enterprise offerings aren't so much fixed pieces of software as ridiculously flexible frameworks for making software. And the people deciding how to configure Epic, and deciding how the doctors and nurses need to use it aren't practitioners, they are administrators who are making decisions for bureaucrats reasons, CYA being high on the list. Anytime an accident occurs, rather than understanding why it occurs, the solution is always to add more administrative controls, to record more details in the chart, more busy work to do that makes each step of the process take longer. As a result, the number of things that practitioners need to enter into EMRs keeps growing, and every year they spend more and more time charting. This in turn decreases the signal-to-noise ratio of the information in the charts, resulting in the practitioners getting less information out of them despite the fact that more information keeps getting put in. Which results in more accidents rather than less.

nednar 6y ago
Most people don't know that always writing tickets, even if they get refused and ignored, will have an impact. Your goal is not to convince level1 support to be your friend, but to turn the statistics into a way that forces administration to consider your concern. So always write tickets and encourage your colleagues to do the same. And if they get ignored make a screenshot and send it with the headline "lol, got refused again" to the watercooler mailing list and laugh about it together.

smabie 6y ago

Also the devs who write the software never actually need to use it. Developer tools such as editors and compilers are of high quality (relatively, of course) because developers use these tools while working on said tools. Many developers doing enterprise software don't even have a rudimentary idea of the work flow around the app that they're developing. Consequently, they are unable to design an effective and efficient app.

conanbatt 6y ago

That's not really true. There are open-sourced EHMR's, consumer-facing emrs and in-house built EMRs. They all suck, and there are many reasons for it which are not this one.

nednar 6y ago

Yes and no. People can force software on your office computer but not on your private laptop, tablet and raspis. And even on windows computers you will find ways to install software without admin rights (e.g. Putty doesn't need any admin rights). Therefore I would argue the main thing missing is a desire to conquer the computer as a tool, a tool that might save hours of work time, that might help analyse problems more efficiently than a human brain can, that can help outperform one's colleagues. With a desire to conquer the computer, open source, and exchanging knowledge online, actually many private enthusiasts who can't afford medical care or won't get the right one can already help themselves. And they have not studied as long or hard as most medical people do. I.e. a doctor with the right spirit should be able to achieve a lot more than such hobby enthusiasts. And with that passion and knowledge the medical community as a whole would slowly also force better software into their work environments. They know how to hold conferences and argue with facts. It's hard to blame others if you belong to one of the smartest tribes on the planet.