alt Hacker News> 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.
Replies
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.
Maybe it's different in other languages, but if I ever see hand-rolled serialization in a C# project I'm putting replacing it at the top of my to-do list. There is pretty much no reason to do that ever, serialization is a solved problem. It's flat out stupid to spend extra time hand-rolling a solution that most likely ends up buggy and requires even more work in the future etc. I also often see people waste hours or days writing custom serialization logic for a serialization library, when they could have just written a new class in the shape of the data and been done in 5 minutes.
I did work on such a project once. There was a CMS web app which needed to sync data from a third party api to rebuild some pages every night. To do this they had a client library that pulled the data twice daily and stored it in a db, then the CMS app pulled the data through the client library. The API used XML and significant parts of this library were a hand-rolled xml serializer. It worked so I didn't touch it, then it stopped working. Spent days trying to fix it but the more I studied it the more I realized it was entirely pointless. Spent about 1 day replacing the whole thing with a simple little function that just calls the api, deserializes the data using a library and builds the pages. Remove the pointless DB, remove the giant legacy quagmire integration library, this project probably took months to write and I replaced it in a day, making it orders of magnitude smaller and faster.
In the end my solution wasn't used because of office politics, apparently they'd paid a significant amount of money to use this pile of trash and replacing it that easily would make someone look bad or something. So I ended up fixing the pile of crap in the end, even though I had a replacement ready to go.
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.