Programming

Mostly agree.

But I think their advice falls prey to the “only a Sith deals in absolutes” problem, when they start contrasting “concrete advice” vs “generic advice”. They are offering “generic advice” with this post, aren’t they?

They hedge against that hypocrisy by offering some special carve-outs where generic advice is still “allowable”, but Idk. I think this post could’ve stuck to the 60% of the topic that was a slam-dunk instead of trying to take on the entire topic of design principles.

After all, I think you could argue that when experienced designers appear to contradict design principles, it’s because they understand the underlying logic of the principles and are recontextualizing them for this specific problem. That argument prioritizes concreteness but also doesn’t paint design principles as unimportant.

As Picasso or someone once said: first you must learn the rules, and then you must break them.

Large shared codebases never reflect a single design, but are always in some intermediate state between different software designs. How the codebase will hang together after an individual change is thus way more important than what ideal “north star” you’re driving towards.

Yeah, learned this the hard way. Came up with an architecture to strive for 1½ years ago. We shipped the last remaining refactorings two weeks ago. It has been a ride. Mostly a ride of perpetually being low-priority, because refactorings always are.

In retrospect, it would've likely been better to go for a half-assed architecture that requires less of a diff, while still enabling us to ship similar features. It's not like the new architecture is a flawless fit either, after 1½ years of evolving requirements.

And ultimately, architecture needs to serve the team. What does not serve the team is 1½ years of architectural limbo.

Sometimes you have to.

Sometimes the intended user of a piece of software is not going to be a software engineer. The user might be intelligent, but not necessarily technically minded. They have no idea what's possible - and importantly, what isn't - and the software engineer closest to the subject may still not have a deep understanding of the subject, the nuances, the criteria for which the system is being written.

This is often unavoidable.

Even within the scope of the article, which seems to be about software projects for software engineers by software engineers, no group of engineers, nay, no two engineers, will have the same understanding of the field for which the software is being written.

Worse, management (at both ends) may well ensure that the only method of communication between developers and users is through them, providing a game of "telephone" in the middle.

This is all about the phrase "if you want a job done properly, do it yourself" and what you do if you can't.

And also the tree-swing cartoons that have been around for decades at this point.

I don't like when someone from the outside the team try to dictate their design on my system. But, sometimes it is good the get new perspective and new ideas on the way things should be done. Especially if you encounter issues in your current design (scalability and security come to mind). If current design is working for you and your clients, there is no reason to change just because there are cooler toys these days. If you find yourself in too many problems and your current technology lags behind, consider starting from scratch having all the knowledge from the old system instead of trying to modify current code base (nice in theory, but most of the times no practical for time, money and resources available).

Acquiescing while reading this, having never contributed to a project of any size and thinking I'm hot shit for having climbed to 4 kyu in Python on Codewars.