Comment by gregdoesit | Hacker News Reader

Comment by gregdoesit | Hacker News Reader

I have been building large scale/distributed systems myself and reviewing designs of systems like these being built around me, for years now. I have never come across any of the type of ivory tower architecture that this post and other sofware architects write about. We're talking about real-world systems that are high-load and somewhat novel, with battle-scarred engineers building them.

I find it ironic that that many of the people who write about architecture are consultants or writers. Consultants usually come into a project, make some decisions and write some code in a few months. Then they leave, without having to maintain the application. Of course they bring in fancy-named architecture patterns as one-size-fits-all solutions, leaving before the cracks on the approach show. Ever notice how little writing there is about iterative software design?

For writers, it seems they build a simple proof-of-concept solution, that is never deployed in production, documenting this process and showing it off as an example.

Yet, when it comes to writing about software architecture, this is 90% of the materials. Engineers who build this day in, day out, design systems from inception, iterate on them, code and deploy, then maintain and operate them for years - they barely share what approach they took. And it's none of this fancy-talk in articles like this one. It's not UML or other formal methods. It's simple documents, simple diagrams, lots of discussion about tradeoffs and tons of back-and-forth comments over Google Docs/O365 and in real life.

I'm at the point where I'm serioulsly debating writing something more substantial on how actual software design works at tech companies, when you're not a consultant or a writer, but an engineer who does this full-time, end-to-end, living with all the consequences of decisions and fixing mistakes after.

On the importance of prototyping, extensible MVPs, whiteboarding, documenting an initial design and getting feedback, iterating on it, architecture jams, design war rooms - and when starting again when the world/business changes substantially, keeping things running and migrating things over to the new system.

I've worked in both a big IT orgs and consulting and the Ivory Tower Architecture people are 10X more prevalent in IT orgs. They're the ones who establish architecture review boards and request extensive documentation and rounds of approval before allowing a project to proceed. On the consulting side, we typically define an approach which might as simple as saying "We're going to write microservices, mostly in Python and our main data store will be Redis until we pick something better" and then start iterating.

When consulting I love those guys. So many billable hours and project delays with pay.

> I'm at the point where I'm serioulsly debating writing something more substantial on how actual software design works at tech companies

If you need a little push to do so... I dare you

I've been doing exactly the same for the past 16 years, and my experience has been exactly the same as yours. Never seen any of these proposed models work in reality, and never seen these models come from industry or academic veterans.

I work at a fairly large company you've heard of and there is definitely a lot of application of the practices that he preaches. It never works perfectly because nothing ever does, but the effect of his teachings is noticeable. They are ideals to strive for. The failure at implementations tends to be more a people and process problem than a technical problem.

"I'm at the point where I'm serioulsly debating writing something more substantial on how actual software design works"

It's probably already been written; see the "Big Ball of Mud": http://www.laputan.org/mud/mud.html

> While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

>These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

Interesting!

Would you expect your writing to be received any differently?

Reply on news.ycombinator.com