Software Architecture Is Overrated, Clear and Simple Design Is Underrated (2019)

Actually, our approach is not that different in principle, to most architecture guides.

This whole article is basically clickbait. The author appears to be arguing against some ill-defined strawman, but in the end even concedes that that isn't true. They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there.

The important thing to realize is that all software has an architecture. The difference is, some software has a good architecture that makes it easy for it to meet its requirements, and some of it has shit architecture that makes it brittle, failure prone, impossible to maintain, and generally scary to look at. And also that some software has an architecture that is clearly defined and well understood and (gasp) documented in some way, where other architectures can only be understood by a massive reverse engineering effort.

You can choose either approach, and all of that is orthogonal to whether or not you use UML, 4+1, Design Patterns, DDD, event sourcing, microservices, or whatever buzzword you want to rail against.

When I started out, I thought the way to become a senior engineer was to increase the number of patterns I knew off the top of my head. It was by speaking with more senior folks that I learned that wasn't how to grow, but that was far from obvious.

The key word here is “over-architected”. The author is nitpicking academic and bureaucratic architecture design that happens at large (arguably inefficient) companies. But they evolved that way to protect themselves, probably before testing was widely understood or implemented.

Regardless, it tries to make a sensationalist topic when in fact it’s trying to say “architecture is common sense” + don’t prematurely optimize.

Overall not the worst article but its incendiary nature rubs me the wrong way.

- Let's first start with the false dichotomy. Software Architecture is not orthogonal to clear and simple design, and clear and simple design is not orthogonal to software architecture.

- Let's assume the dichotomy exists. I used to think this way too, as well. I was vehemently against the architecture astronauts. As I got older, and worked on more projects, and gained more experience, I learned that I was simply in a position where my architecture decisions didn't have a drastic negative impact, at least certainly not in the near term, nor mid term in most cases, only in the long run. I could get by with, well pretty much anything, so long as it "just worked" (TM), and we had the ability to debug and diagnose quickly when issues came up.

- Apps, Web development and the such can afford to get by with some questionable architecture, because they are mostly standing on the shoulders of giants, starting with the architecture of the internet itself all the way to most databases, libraries, frameworks and tools, and even some languages, that make common web-based development tasks like parsing JSON, performing RPCs, or working with DateTimes pieces of cake compared to yesteryear. If you work with distributed systems, you use some sort of well architected consensus solution, with likely a well architected software package or library to use it with, that likely will cover up a lot of your mistakes and misuses.

- Working at a major bank now, with friends at other major banks, there are some outright fallacies described in the article. Maybe that was the case when this person worked there, but it isn't the case today.

> All of these systems were large at scale: hundreds of developers build them - or on top of them - and they power systems used by millions of people per day.

But it's still likely that you simply leveraged existing libraries and tools built on solid architecture. In fact, I have a little inside baseball at Uber to know as much.

Bottom line is, you can't get to "clean and simple design" without being good at writing software and having a wide, diverse array of experience. I would say that is almost the essence of software architecture.

But most companies do not have a lot of experienced architects building products. A lot of companies can barely keep a handle on their dev teams, and worry a lot more about regulation and herding cats than building a decent product, so their Architecture Teams are actually Cover-Your-Ass Teams. Dev teams often don't even know that other teams exist, much less have any way to circulate a single diagram to them all, or talk about what the hell it's even for.

If all you've ever worked in is a tech company in San Francisco/Seattle, let me tell you... It's ugly out here in the land of normal businesses.

So software architecture is really for the average people working in average companies who could use a hand figuring out how to design and implement their product. They have never even heard of C4 or ADR. But those simple models and processes would absolutely transform their work from barely-functioning balls of shit, into the gloriously robust design the author's company came up with. Nobody else is helping them figure out how to do it; best practice is what they've got to work with. If they even know about it.

It's just normal gateway with a bunch of `if then else` for business logic to decide at the edge.

The benefit, is i can turn on/off easily, and it allows me to add new features without breaking existing features easily.

>No IT architects or enterprise architects. True, neither Uber nor Skype/Microsoft have hands-off software architect positions. Engineers at higher levels, like staff engineers, are expected to still regularly code.

That statement says that EA is not commonly coding. Is that true? I don't know that I've met many architects that aren't engineers by another name (possibly cross departmental/enterprise).

It feels like a straw-man.