Software Architecture Is Overrated, Clear and Simple Design Is Underrated • Hacker News Board

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#151

Post by enriquto » Wed, Sep 18, 2019, 1:07 PM UTC

jbn wrote: post #148

abtinf wrote: post #90

Earlier quoted context omitted.

In the spirit of being helpful: “ignored” implies you knew the meaning and intentionally did not address it. I think you meant “I was unaware of this meaning” or “I didn’t know that.”

not to nitpick any more than necessary, but I don't think that's entirely correct: "I have ignored" implies that GP knew the meaning and intentionally did not address it, while "I ignored" is correct and also means “I was unaware of this meaning” or “I didn’t know that.” ... at least that's how I see it.

according to wiktionary [1], this is indeed a possible meaning of the verb "to ignore", but it is marked as "obsolete".

This is a case of false friend when translating from french, where this meaning is the first one [2].

[1] https://en.wiktionary.org/wiki/ignore#Verb

[2] https://fr.wiktionary.org/wiki/ignorer#Verbe

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#152

Post by kdmccormick » Wed, Sep 18, 2019, 1:08 PM UTC

cryptica wrote: post #110

This article has some contradictions: >> Third, we had practically no references to the common architecture patterns and other jargon referenced in common software architecture literature, such as Martin Fowler's architecture guide. No mentions of microservices, serverless architecture Then a few paragraphs later: >> Is your architecture split into different microservices? Mention why you decided against going with a…

Good observations. I think a more accurate portrayal of the author's experience would be "Clear and simple Architecture is underrated".

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#153

Post by gerbilly » Wed, Sep 18, 2019, 1:14 PM UTC

d--b wrote: post #63

Let’s see how the OP’s system looks in 20 years. Then we’ll see how clear and simple it has remained. The OP is railing against a culture that never existed. Banks software architects are not in their offices smoking cigars and making UML diagrams that they send to coders, only to realize later that they made the wrong trade off. What happens is: You design a system for what it’s supposed to do. You do it the way the…

> But if the toilet is already dirty, you’re not going to be the one cleaning other people’s pee, so you just add your own and leave.

Good analogy, but in code it's more than just disgusting to clean up after others. Changing code that was poorly written by someone else may cause bugs, bugs that now become your problem.

The goal of every programmer faced with such a codebase—as in the dirty bathroom analogy—is to get in, do his business as quickly as possible, and get out. Iterate this over time and the problem just keeps getting worse.

It's like the tragedy of the commons, where each programmer pollutes a common resource because the incentives are set up to reward that kind of behaviour.

This leads the codebase to become a 'Big Ball of Mud', the most popular architectural pattern in the world: http://laputan.org/mud/

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#154

Post by ajuc » Wed, Sep 18, 2019, 1:15 PM UTC

moksly wrote: post #32

The value of Enterprise Architecture doesn’t come in to play until you’re an actual Enterprise. We operate more than 300 IT systems, from a myriad of different and switching (courtesy of procurement) suppliers. These systems are operated by 5000-7000 employees, and range from making sure employees get paid and patients get the right medicine to simple time booking apps. Most of these systems need to work together, an…

That's not architecture, just standarization.

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#155

Post by growlist » Wed, Sep 18, 2019, 1:19 PM UTC

james_s_tayler wrote: post #108

growlist wrote: post #83

In my experience the further away from fierce commercial factors, the greater the tendency towards cargo-cultism. Hiring for roles in government related work in the UK is awash with acronyms and buzzwords, as if it's the case that with enough methodology and certifications we can regulate failure away. Problem is: things still seem go wrong in all the same old ways despite all the latest greatest fancy new techniques…

For some reason I read "methodology" as "mythodology" and I thought "That's genius! That's the perfect portmanteau to describe the phenomenon of people trying to learn and adhere to 'methodology' but then really just adhering to the lore and the myth! I'm stealing that!" Then I read it again and it didn't say that. But I think that should become a new word. Mythodology.

Nice. Even better, use it as the name of a company hawking snake-oil methodology consulting.

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#156

Post by afpx » Wed, Sep 18, 2019, 1:34 PM UTC

jaequery wrote: post #5

First 1-3 years of coding, I just coded to get sht done. I got a lot of sht done. Next 4-8 years, I started getting cute with it and applied all kinds of design patterns, Factory, Abstractions, DI, Facade, Singleton you name it. It looked cute and felt good when it all worked but it was a juggling act. There was usually like 2-3 files to touch just to do one thing. UserFactory, UserService, UserModel, User, you get t…

The only problem is that it takes at least 10 years to get to that point. No one has found a shortcut, yet.

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#157

Post by nine_k » Wed, Sep 18, 2019, 1:38 PM UTC

afpx wrote: post #156

jaequery wrote: post #5

First 1-3 years of coding, I just coded to get sht done. I got a lot of sht done. Next 4-8 years, I started getting cute with it and applied all kinds of design patterns, Factory, Abstractions, DI, Facade, Singleton you name it. It looked cute and felt good when it all worked but it was a juggling act. There was usually like 2-3 files to touch just to do one thing. UserFactory, UserService, UserModel, User, you get t…

The only problem is that it takes at least 10 years to get to that point. No one has found a shortcut, yet.

"Simplicity does not precede complexity, but follows it."

This is why it's often worth it to come up with a complicated design, work on it without implementing it as much as possible, think it through, understand where the core functionality lies, and make a new, much simpler design.

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#158

Post by wonderwonder » Wed, Sep 18, 2019, 1:41 PM UTC

jaequery wrote: post #5

First 1-3 years of coding, I just coded to get sht done. I got a lot of sht done. Next 4-8 years, I started getting cute with it and applied all kinds of design patterns, Factory, Abstractions, DI, Facade, Singleton you name it. It looked cute and felt good when it all worked but it was a juggling act. There was usually like 2-3 files to touch just to do one thing. UserFactory, UserService, UserModel, User, you get t…

I've always been happy with just OOP and dependency injection. Anything more and things start to get difficult to follow. Currently working on a a legacy system that uses micro services and it takes hours just to figure out where the code is that needs to be changed and to trace how those changes will be propagated through the system.

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#159

Post by agentultra » Wed, Sep 18, 2019, 1:42 PM UTC

This is great... but one thing I think we _do_ need to change a bit is around specification. Knowing when to use blueprints as opposed to a sketch on the back of a napkin (or on a whiteboard). UML diagrams are not helpful to a lot of projects. But if you're dealing with concurrency or hard problems involving liveness or safety -- having a model one can verify and check goes a long way.

My litmus test for knowing when to bust out a TLA+ or Alloy model is: what's the worst that could happen if we get this wrong? and are there behaviors we cannot allow the system to have?

I find many developers, especially senior ones, develop a misplaced confidence in their knowledge and skill. And usually this is justified. We can generally get the majority of the system correct enough to be useful within a couple of iterations. Once that system is in production however it can become too difficult for even the most genius among us to find that one behavior of billions of possible ones that keeps triggering our SLOs.

That's because once we break down our behaviors into discrete steps and variables we find that many systems have behaviors that are 50 or more steps long involving several variables. The bad behavior that we didn't account for is there and we didn't know it existed until it went into production and started frustrating our customers.

I don't suggest we specify entire systems using formal methods like this, but for the important parts, I find it's worth avoiding the trouble than it is tolerating the risk and frustrating users.

Nice article though -- consensus building among peers is one of the least-taught skills and one of the most important.

Re: Software Architecture Is Overrated, Clear and Simple Design Is Underrated

#160

Post by Timberwolf » Wed, Sep 18, 2019, 1:50 PM UTC

bamboozled wrote: post #98

In my career thus far, I can honestly say I've never, ever, ever seen an "Architect" who actually provided valuable inputs. Not trying to say they don't exist, but I've just never witnessed someone with that title actually have a positive impact on any project I've worked on. The only semi-positive value I've seen an architect have is when they counter another architect to allow the engineers get on with their work w…

In my experience, architects who are valuable to their teams tend to be the ones who rarely do any "architecture" themselves; instead they work their arse off trying to smash apart every last blocker to the engineers in a team being able to own architectural responsibilities themselves. (This may include asking smart questions to help a team who don't really do systems thinking start engaging with it). This inevitably ends up off in the EA realm grappling with Conway-type questions: not so much "how should we structure our software to make it good?" as "how should we structure our organisation so it naturally produces good software?"

Sadly these people are also rare as it requires a combination of sufficient technical skill and the ability to effectively navigate the people side of the equation.

The "white paper" style of architect is very frustrating in comparison, not least because they are too removed from the context and impact of their decisions. This results in a situation where a team views their architect as merely a source of additional work, much of which is frustrating and pointless if not outright damaging to the system being built.