4 ms·

Even 150 blows my mind. Years ago I worked for one of the top 10 EHR software makers (at the time - maybe even now, I haven't looked) and we had 1/3 the number

Even 150 blows my mind. Years ago I worked for one of the top 10 EHR software makers (at the time - maybe even now, I haven't looked) and we had 1/3 the number of engineers on that system.

supernova87a 7y ago
It's funny, as soon as you have a system that has to take into account human behavior and variety of possible inputs/states, it gets massively complicated if your goal is to try to have people not be dissatisfied with it. (and if you're trying to do it right -- or alternatively, NOT making the right decisions about that goal). People just don't behave like you think they will/should. As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple? No, it turns out that you have to also take into account people whose orders got delayed by the human-based shipment system, people who got coupons and they expired/want to extend the coupon, people who returned the merchandise and never got any confirmation that it was received back. Or what if someone modifies the meeting location after people accepted -- does a minor change to the meeting description trigger a re-invite or update, or not? Can meeting rooms be held by more than one person at a time? Or what if you want to tie it to the email marketing system that wasn't properly integrated or planned to be integrated -- that's another couple of engineers who have the thankless task of maintaining ETLs that constantly break whenever a change comes along. Or in the case of Yelp, I'm sure there's small teams who are responsible for the mundane tasks of how to keep track of when a business closes, or reopens, or temporarily shut down due to virus situation -- how are the entries for those businesses supposed to be updated? We never had a field for "closed by mandatory government order" -- that's gonna take a refactor of xyz to implement, etc. etc. We have users who review things, and then those users someday die/go idle/get banned. What happens to the ranking of their reviews? It goes on and on. (and usually, the people who take the time to think about these things in advance set themselves up for much less pain, and far fewer people needed to fix it, later)
- throwaway55554 7y ago
  > As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple? I am not sure people downvoting me understand what all goes into an EHR/practice management software. Calendar booking? Yep. Billing. Oh hell. Don't get me started on the byzantine mess that medical billing is! Then there's charts with icd-9/10 hell. And then everyone you sell it to wants their own charts a little different. Patient records, insurance, I mean, it goes on. The database had several thousand tables. It was insane.
starpilot 7y ago
The problem is edge cases take a shitload of work via pareto principle. And if your company is small, edge cases can be ignored because they affect 1-2 users. When you're serving millions, those are thousands of users. You might be the only entity in that industry at that scale and have to custom build everything.
- throwaway55554 7y ago
  Edge cases? Medical software is loaded with them.
- zentiggr 7y ago
  I remember hearing the variant that ran "The first 20% of the program takes 80% of the time, the remaining 80% takes the other 80%."
ahupp 7y ago
Often this comes down to how much money you're making. Any product has a long, long tail of work you could be doing to improve things. When you're a scrappy startup with few engineers you wouldn't even think of spending time on that stuff. But when you have substantial revenues, why not hire more engineers to work on it?
wgerard 7y ago
I don't mean to be flippant or unnecessarily mean, but my anecdotal experience is that many EHR systems are pretty widely derided by healthcare providers (i.e. end-users). Maybe it's not a good thing that only 50 engineers were working on that system.
- sjg007 7y ago
  The primary focus of most US EHRs is for billing.
- throwaway55554 6y ago
  Doesn't matter to me, I'm not in that industry any more. But yes, they're a mess. But, honestly, I don't know you would make it less of a mess. People just need to accept that some systems are complicated and the more you try and make it less complicated the further from that goal you get.
novok 7y ago
There is a whole bunch of stuff behind the scenes that you wouldn't be exposed to as a consumer, such as analytics data pipelines, ad sales interfaces, etc that in many ways are more complicated and do more than the consumer facing thing itself. An old EHR system from years ago does none of those things, doesn't do engineering heavy things like live updates with thousands of A/B/C/D tests running simultaneously with multiple clients for multiple operating systems and so on.

Even 150 blows my mind. Years ago I worked for one of the top 10 EHR software makers (at the time - maybe even now, I haven't looked) and we had 1/3 the number of engineers on that system.

supernova87a 7y ago

It's funny, as soon as you have a system that has to take into account human behavior and variety of possible inputs/states, it gets massively complicated if your goal is to try to have people not be dissatisfied with it. (and if you're trying to do it right -- or alternatively, NOT making the right decisions about that goal). People just don't behave like you think they will/should. As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple? No, it turns out that you have to also take into account people whose orders got delayed by the human-based shipment system, people who got coupons and they expired/want to extend the coupon, people who returned the merchandise and never got any confirmation that it was received back. Or what if someone modifies the meeting location after people accepted -- does a minor change to the meeting description trigger a re-invite or update, or not? Can meeting rooms be held by more than one person at a time? Or what if you want to tie it to the email marketing system that wasn't properly integrated or planned to be integrated -- that's another couple of engineers who have the thankless task of maintaining ETLs that constantly break whenever a change comes along. Or in the case of Yelp, I'm sure there's small teams who are responsible for the mundane tasks of how to keep track of when a business closes, or reopens, or temporarily shut down due to virus situation -- how are the entries for those businesses supposed to be updated? We never had a field for "closed by mandatory government order" -- that's gonna take a refactor of xyz to implement, etc. etc. We have users who review things, and then those users someday die/go idle/get banned. What happens to the ranking of their reviews? It goes on and on. (and usually, the people who take the time to think about these things in advance set themselves up for much less pain, and far fewer people needed to fix it, later)

throwaway55554 7y ago
> As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple? I am not sure people downvoting me understand what all goes into an EHR/practice management software. Calendar booking? Yep. Billing. Oh hell. Don't get me started on the byzantine mess that medical billing is! Then there's charts with icd-9/10 hell. And then everyone you sell it to wants their own charts a little different. Patient records, insurance, I mean, it goes on. The database had several thousand tables. It was insane.

starpilot 7y ago

The problem is edge cases take a shitload of work via pareto principle. And if your company is small, edge cases can be ignored because they affect 1-2 users. When you're serving millions, those are thousands of users. You might be the only entity in that industry at that scale and have to custom build everything.

throwaway55554 7y ago
Edge cases? Medical software is loaded with them.
zentiggr 7y ago
I remember hearing the variant that ran "The first 20% of the program takes 80% of the time, the remaining 80% takes the other 80%."

ahupp 7y ago

Often this comes down to how much money you're making. Any product has a long, long tail of work you could be doing to improve things. When you're a scrappy startup with few engineers you wouldn't even think of spending time on that stuff. But when you have substantial revenues, why not hire more engineers to work on it?

wgerard 7y ago

I don't mean to be flippant or unnecessarily mean, but my anecdotal experience is that many EHR systems are pretty widely derided by healthcare providers (i.e. end-users). Maybe it's not a good thing that only 50 engineers were working on that system.

sjg007 7y ago
The primary focus of most US EHRs is for billing.
throwaway55554 6y ago
Doesn't matter to me, I'm not in that industry any more. But yes, they're a mess. But, honestly, I don't know you would make it less of a mess. People just need to accept that some systems are complicated and the more you try and make it less complicated the further from that goal you get.

novok 7y ago

There is a whole bunch of stuff behind the scenes that you wouldn't be exposed to as a consumer, such as analytics data pipelines, ad sales interfaces, etc that in many ways are more complicated and do more than the consumer facing thing itself. An old EHR system from years ago does none of those things, doesn't do engineering heavy things like live updates with thousands of A/B/C/D tests running simultaneously with multiple clients for multiple operating systems and so on.