neckardt
3 months ago
My first job out of college was working at Epic on MyChart. Great people, terrible code.
Epic’s main problem is a lack of clear internal code ownership. Everyone owns all the code. This means that even if you clean something up, someone on the other side of the company may come in and mess things up again.
This led to really defensive programming where developers would never refactor, they would simply add a new if case for their new functionality somewhere deep in the code, then prop drill the data down. This led to every core function having over a dozen parameters and hundreds of branches. It eventually became impossible to reason about. Cross team calls were just function calls rather than defined apis. This made it fast to develop code initially, but terrible to own long term. This mainly applies to their Mumps code.
While I was there I felt like Epic was beyond saving, but with a big push there may be something they can do:
1. Enforce some level of code complexity. Best practice is 40 lines per function and no more than 4 parameters per function. Epic probably shouldn’t shoot for that, but a 100 line limit and 6 parameters per function would already be a huge improvement.
2. Enforce strong code ownership. Epic has many people who are there for life, let them cook. Epic should segment off code to certain teams so those owners can fix it at their leisure. Cross team api calls should be clear API contracts. It would require some more discussions to get feature requests approved since not everyone can do anything anymore, but the code would gradually improve.
Epic is too important to fail. I hope things have started to improve since I left.
menzoic
3 months ago
Most places I’ve worked including Uber and Airbnb allow teams to contribute code to other teams services. Quality is protected by requiring “blocking reviewers” on pull requests. Blocking reviewers requires one person from the services team to approve the pull request.
I think this is better than requiring teams to make all changes themselves which slows things down significantly considering each team has their own roadmap and priorities
DanielHB
3 months ago
> 1. Enforce some level of code complexity. Best practice is 40 lines per function and no more than 4 parameters per function. Epic probably shouldn’t shoot for that, but a 100 line limit and 6 parameters per function would already be a huge improvement.
If I were to enforce some kind of arbitrary code complexity threshold for functions I would put a cap on the limit of possible of branching combinations based on parameters within the code. Like around 16 (branching combinations are exponential).
For example a function with 20 parameters but only one if statement is fine. A function with 5 parameters but several nested if statements is not.
aylmao
3 months ago
What languages is their codebase developed in?
epmatsw
3 months ago
Ha, we were pushing complexity metrics back in 2012. The Security team added it as a PQA step in 2013 when I was there, no idea if that stuck around.
user
3 months ago