[neckardt]

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]

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

[BugsJustFindMe]

You'd think so, but often the blocking reviewer is an entire team, including people who just aren't careful at all or who don't understand the downstream consequences of their actions, and not just the one person who has strong vision and cares about the process, because the one person is also a bottleneck.

Requiring reviewers isn't sufficient. It needs to require a cohesive review strategy that adheres to a long term product vision for the software component in question. And my experience, though not at the two companies you mentioned, is that it doesn't happen and you instead get a lot of thoughtless "yup, looks like code" approvals.

[xmprt]

I think what you're referring to is the same as strong code ownership. Each repository/directory has an owners file which specifies who can accept changes. If someone makes a change in my repo, I still own that change because I accepted merging it.

[DanielHB]

> 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.

[Taikonerd]

Like cyclomatic complexity? https://en.wikipedia.org/wiki/Cyclomatic_complexity

My previous company had a step in the CI/CD that would fail if the nesting level of a function got too deep. (Like, "an if statement, which contains a foreach loop, which contains another if statement, which contains...")

[foobarian]

This is why microservices are great. It is impossible to reacharound by flipping a private function to public and call it. An API change is required, which is hard to hide, and it needs to be carefully deployed since it can have visible load/operational impact.

[aylmao]

What languages is their codebase developed in?

[epicdev]

MUMPS is the infamous one that pretty much everyone is at least trained in, but Epic is 99.9% done replacing old VB6 clients with C#.NET + Typescript/React. There's also developers working with iOS and Android development, and Python and SQL for data science and business intelligence.

[jacinda]

https://en.wikipedia.org/wiki/MUMPS

[epmatsw]

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.