> A CTO friend uses the metaphor of clearing two paths up a mountain. The left-hand path is quick and dirty, cleared with a machete and brute force—you do not expect anyone to follow you, you just hack your way through—but you make progress quickly. The right-hand path is a wider, clearer, paved path, and more substantial, but takes time to build as you go along.

This is a good metaphor and is more effective than the neologisms and acronyms of the rest of the article. The author claims a "middle path" but doesn't even connect it to this real world metaphor.

It seems the author is really advocating for the "left path", but only if you are a experienced programmer and with a sprinkle of QC. In the real world metaphor, this would be like hacking through the jungle, but making a little effort to ensure your path is visible to someone else, not unnecessarily dangerous, and makes pragmatic compromises (we will go around this cliff instead of bringing climbing gear or other heavy dependencies).

If you polled 100 SWEs on the example of 'skipping the JSON library and implementing de/serialization for a few objects ' and asked whether they thought it was a "left path" or "right path" solution I'm certain you would have a strong leaning to the left, and not a 50-50 that suggests a secret middle path.

I think it's a bit nuanced, and maybe poorly explained by the original author, but to me, "left-pathers" are always "move fast and break things" to the point that whatever they build really only works as a throw-away prototype, and the effort to architect sensibly is minimal.

"We don't really need to use REST, we can just create some endpoints that have undocumented side-effects. We don't need to abstract vendor calls into a separate class, we can just implement that functionality directly in our endpoint code."

These sorts of decisions aren't actually materially faster, they're just lazier. And maybe that's "a sprinkle of QC"? But it's a lot of unforced errors that don't really save time to implement, and also create a lot of problems later on.

On the other end, with the "right-pathers", you can have people that really try to over-engineer at any opportunity. This is sort of typical of people who have worked in much larger teams. This can mean building out a k8s cluster when you're still a team of 2-3 people, splitting into 10+ microservices, deciding to use Kafka when a simple queue system would work, building out in-house load balancing for dubious reasons, etc.

The middle path is really something that resembles the "Best Simple System for Now" — when I've done this, I think about how I can solve a problem and not have to rebuild it entirely within 12-18 months.

I think it's less a middle path than a third option. I see the type of thinking the author is commenting on whenever there is a tight requirement on a feature. Especially when you know you have to add some custom magic to meet the requirement. People tend to psychologically buy into a fully custom solution early on. So they either hack in a custom solution using abnormal data paths or known bad solutions or they fundamentally rearchitect the system around it. The third path is sketching out the feature so that it's modular and can be replaced. That way you can start out with a standard solution which gets you 90% of the way there then replace it as development progresses.