Software architecture pitfalls and how to avoid them

Then they leave, and you find out the bits they rewrote were the carefully crafted and well documented protobuf APIs now replaced by ad hoc JSON where the parsing and spec are strewn across thirty places. The new projects you quickly realize make no sense whatsoever and don’t actually do the things they were supposed to do, but kind of look like it if you aren’t paying too close attention.

Now they’re a “senior engineer” at the next company.

very often development teams will value re-use and dry to the point that they'll conclude they need to stuff most things into a common library and share it amongst all their codebases.

Anyone who has seen this done long term has seen this accrete until everyone is afraid to change the common library for fear of breaking _everything_.

IOW, the risk profile of something like this grows over time. It starts out small but each time a project adds it as a dependency the risk grows.

and yes, I understand everyone is going to post about versioning and change management and all the myriad ways one can try and mitigate this.

the point here is that when using a common library like this you must be circumspect in what you put into it. The risk threshold for it being worth going into this common library is going to be much lower for someone who pushes for a common lib and then skips to the next job vs someone who was there over the next 3-5 years and personally experienced the pain and fear such approaches invoke longer term.

and to repeat myself since I know this is HN.

No one is saying you can never have common libraries like this, what's being said is that the long term risk is much more likely to be respected by someone who long term experience and therefore that person with long term experience is much more likely to be able to design a system that can be worked on productively over the long term.

a) Many people who have only ever worked at 1 or 2 companies have some really critical gaps in their technical breadth. Every time I've switched jobs, I've had multiple "I can't believe we didn't use this at my last job" moments.

b) I've seen many "lifers" in big companies who built some great big system at some point in the past and now do very little other than maintain this hairball. It's very rare that, for someone who has been in the same role for 10 years, their last 5 years were as productive as their first 5. Despite promos and all. You get older, the job gets easier, and you get lazier.

Software is not like this as there is no limit to the scope that can be built in to a single app. You don't have the constraints of physical space, materials and human use cases and locality. The "load-bearing" aspects of software are not just physical infrastructure with CPU/memory limits, but also fundamental choices in the data model, some things more than others, and what starts out as a casual choice can become load bearing if further construction builds on that assumption. Buildings don't have legacy data.

> When you create a coffee shop, you build it to have a specific, repeatable, singular user experience.

I can't tell if you're suggesting software should be built this way, but after 25 years in the consumer space in multiple startups, scaleups, and largish companies, I have never seen any software company succeed based on rigidly adhering to singular user experience in this way. Even when you can describe the experience simply, the details and tradeoffs are enormous, and companies that win are the ones that are able to iterate quickly without letting the quality degrade to the point that the wheels come off. Facebook vs Friendster vs MySpace is a pretty good example. In my own founding experience, I was able to bootstrap a streaming service to 6-figure subscribers over 8 years leaving behind a graveyard of failed competitors because they couldn't thread the needle between good UX, good engineering, and the right content investment.

I'm sure it's different in well established and standardized corners of B2B and industrial software where you are not subject to the fickle nature of consumers, but in B2C you are default-dead if you insist on some kind of fixed requirement and long-term vision that doesn't change.

Um. Okay. So, just so I am clear, the advice here can be rephrased as: "Save a matter of life or death, don't have hobbies"?

> shipping software means compromise, most of these points are basically "don't compromise on X".

as, you disagree with a lot of the article because it's telling you not to compromise on some things and compromises are necessary for software development. That only logically works if you're also saying that compromises are necessary everywhere, doesn't it? Otherwise what's to disagree on? If you're saying compromise may be required on any of items 1 through 10, and I'm telling you not to compromise on 1-5, well then 6-10 are your zones of flexibility.