Starting MyChart, Part 2
Welcome back, the MyChart story continues…
Interestingly, MyChart wasn’t the first “web” product at Epic.
EpicWeb (remember how great product names have been at Epic historically) had already been released and it used what I considered an unholy combination of VB6 and Microsoft Active Server Pages 3.0. It was remarkable how well it all worked on the surface, but the underlying architecture and demands of Microsoft ASP lead to some very hideous and necessary hacks. Honestly, I don’t believe Microsoft intended any company to sell a product that used the technology — instead believing it was for in-house “enterprise” developers. Worse though was that these technology stacks and combinations weren’t well documented, so a lot of the architecture of EpicWeb had been built based on experimenting and a lot of trials by fire. A lot.
It was cobbled, super-glued, and duct-taped together and made my head hurt when I tried to understand the system they’d built. I did not want to repeat that. One of the design challenges of EpicWeb was the team wanted to have an extensive set of customizability on the web front end …, and ASP 3.0 wasn’t entirely well-suited for that. Back in 1998, web development was still just a toddler at best.
While this wasn’t the start of the era of extreme customer customizations, the product was constructed to satisfy as many choices as possible. (MyChart later suffered for this same customization conviction). There’s probably a haiku for this … oh wait, Epic took that as a product name. 😳
EpicWeb, once installed, wasn’t used by many customer staff, so there was no need for “big scale” architecture. MyChart though — we didn’t know and wanted to design for large scale usage. So, we took some time to explore alternative architectures and technology stacks. For example … Java. I wrote a complete communication system back to M/MUMPS that mirrored the then current EpicComm communication stack written in VB6. While Java was better in many ways, the early web days of Java weren’t all local ice cream and Wisconsin cheese, there were plenty of cow-patties thrown into a web system. If MyChart had used Java, that would have charted likely a very different course for Epic in later years. (A story for a different day!).
And because I liked to push outside of comfort zones, I wrote a communication library and front-end in C/C++ as well. It performed well, but I admitted that Epic developers and TS wouldn’t have had the best developer and support experience that VB6 would allow.
It’s weird to ponder if I were starting MyChart today what technology I would select, given my technology experiences. Microsoft technologies have often been the default at Epic with good records of success, but I’ve rarely used C# since my Epic days. I haven’t liked the ASP.NET system for quite a while, so definitely not C#. If I was doing a max performance push, I could pick a Rust based system, but I’d definitely be concerned about the development and support experience and whether there was a long-term web foundation that would meet the needs of the team. I don’t believe MyChart would benefit from the performance improvements at runtime enough to make up for the development and compile performance issues that would likely occur with a large project like MyChart.
I wouldn’t pick Go, Python, Rails, NextJS as each comes with a baggage I wouldn’t want to entertain and deal with. There’s Elixir … nope. I can’t imagine a team of 100+ devs working together on an Elixir project. Send me examples of a company reselling an Elixir based product that has 100+ active software developers working on the product. Honestly, many programming languages and platforms fall apart with more than a small team working on them.
Even a TypeScript/Node based solution would give me pause as I’m not sure it would scale up and out reasonably (as I’m imagining using Mumps/M/Caché/Iris as the business logic tier still). Of course, modern compute is fast and makes up for the inefficiencies generally.
It’s interesting to ponder — what would you select?
More next time on this same channel! I’ll talk more about some customer interactions and some of the other decisions before I made a big decision.
A few things I’ve discovered or purchased recently that you might like…
IRIS USA Storage Bins with Lids |Made in USA| 6 Qt - (4-Pack) - Clear
I’ve bought these Storage Bins multiple times now and find them super useful in my office and hobby space. Not too big, not too small. Made in the USA (with imported blah blah). I’ve got all sorts of things stuffed into them but have really put them to best use storing various electronic parts and accessories. These clear bins are OK with my pile-oriented brain requirements.
I label each one with some gaffer tape and a white paint pen. I could use a label maker I suppose, but I like the look/style better as it seems less formal and rigid.
I’ve bought different sizes of the bin brand and been happy with them every time. Today I had some delivered that I’m using to store my now tamed and reduced collection of USB cables.
Send Spin
I’ve ordered a few parts to give Send Spin a try. It’s “whole home” audio without the taxes of a large company. I wanted to find a “Sonos” experience for some passive speakers I own without paying hundreds and hundreds to make that happen and this might be a decent compromise. I have 7 speakers from my movie theater that are definitely not new … (probably 10-12 years old now) and I’d like to find a few spots around the house to use them without spending a fortune.
The Sonos Amp which allows passive speakers to become amplified and part of the Sonos network is $800. 😂. For $800 I’d rather just donate these and buy new connected speakers. My wife and I are both tired of looking at the speaker boxes, so something needs to be done soon. There are less expensive options (generally the best reviewed stuff seems to be around $250-$500). However, I’m then thinking buying new speakers would just make more sense.