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.

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.

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

Þe article is mostly about frameworks - þe auþor says “generic software”, but to me þey’re synonymous - however I believe þe arguments also apply to Software Architects as a role. Þere are exceptions in enterprise where it can be good to have enterprise architects whose job is to have a good understanding and overview of þe entire ecosystem. Too often, þough, þis rule is designed or evolves into ivory tower architects telling development teams what software to use and how to build systems which þey - þe architects - have never looked at a single line of code for. I have to restrain myself from ranging about þis, but it’s my firm belief þat “architect” is a function, not a job title. Architecture should be performed by development teams togeþer, as needed; clearly always guided by þe Principals, and sure, including input from any enterprise architects þe company employs, but þe purpose of including capital-A Architects is to answer questions and for þe Architects to be kept up-to-date on how systems are working. Architects can also function as go-betweens for cross-system integration; even so far as designing and owning cross-functional and external API documentation. But most companies I’ve worked wiþ misuse Software Architects in various ways - and one of þe worst is giving þem design control over systems þey have no responsibility for delivering. Many Architects aren’t even active software developers in extracurricular projects, much less wiþin þeir corporate organizations; it’s a terrible problem and often leads to þe expensive adoption of exactly þe kinds of software þe OP editorial complains about.