Live data from Hacker News

Software Architecture Is Overrated, Clear and Simple Design Is Underrated

blog.pragmaticengineer.com

101–110 of 218 posts

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

#101
post #89
post #57

Earlier quoted context omitted.

In my own experience, it's really a must to go through both over- and under-engineering phase yourself: only then I found I got a really clear view on what's good and bad in approach, allowing me to default to somewhere in between (with outliers when useful) and in any case with focus on simplicity (but again, if needed for e.g. performance that can be violated). All of this is the basic 'learn from your mistakes' pr…

I never went through the over-engineer phase personally. I am a very very lazy person, which leads to me to correct balance most of times: Not enough abstraction, I suffer because of too much change to the code base, too much abstraction, and I feel pissed about my risk management. Since I suffer greatly when I suffer, I avoid suffering in my own code as much as possible. What also helps is that I plan most of my alg…

too much abstraction, and I feel pissed about my risk management

Interesting, so it's not a phase for you, but for the rest it sounds exactly like my point, i.e. learning that over-engineering (too much abstraction) is a mistake and as such trying to avoid it.

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

#102

Earlier quoted context omitted.

Even OOP has its place. I once wrote a simulation of a physical system with a lot of moving parts and OOP made the problem tractable and the code readable and maintainable. I don't think any other style of coding would have had such an enlightening effect on that particular problem.

Totally. For me just AbstractUserGeneratorFactory does not make sense. You can have a look here to get examples: https://docs.spring.io/spring/docs/3.0.x/javadoc-api/allclas...

It's actually a pretty incredible framework.

While it might just look like word soup from that particular vantage point I'd venture to say that Spring Framework is one of the most successful examples of OOP in history. It has massive adoption because of its sheer flexibility which all of those abstract generator factories give it.

Granted, I think Ruby on Rails is also an amazing project. For slightly different reasons, but then again, they're different use cases serving different paradigms and different groups of people.

It isn't the paradigm that makes something good or bad or better or worse. It's the quality of the implementation.

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

#103
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…

[deleted]

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

#104
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…

It's pretty rare these days that systems are maintained for that long. More than likely there'll be a rewrite every few years anyway to keep up to date with $EXCITING_NEW_TECH.

Hmm maybe in the Bay Area?

Everywhere else I've seen software that is on average a decade old.

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

#105

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…

I feel being an "Architect" is trying to do half of the job that's atomic, unseparable, because the "architecture" half informs and is informed by the other half, "writing and running code", both of them working best in a tight feedback loop. An architect not writing code has to rely on engineers in their team to communicate to them all the insights gained by implementing the architecture - which is a really bad idea, because it's already hard to precisely articulate your feelings about the code to yourself, and now you have to explain that to another person and hope they understand.

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

#106

I have a hard time understanding the author's point of not using UML but somehow boasting that they used "plain old boxes and arrows" to create "plenty of diagrams". UML is nothing more than a bunch of "plain old boxes and diagrams", but which have concrete, objective meaning that has been specified and thus help share ideas as objectively as possible. UML is a language, and languages are tools to communicate and sha…

The difference is that you can't really use proper UML to quickly explain something on a whiteboard, unless you were fluent in it. I personally get mental inhibitions when I have to quickly decide if the arrowhead needs to be hollow or filled, or if the arrow itself needs to be a line or dotted, or if the box needs to have rounded corners or not... Especially if it doesn't matter for the idea that I'm trying to explain (maybe even just to myself).

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

#107
Overcomplicated designs is like the rocket equation for software engineering. Adding unnecessary abstractions, caching layers, abstract business logic, etc isn't an additive effect, it's a multiplicative one. This is how you take something that could have been a million dollar project and turn it into a billion dollar project that is completely broken on launch like healthcare.gov was.

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

#108

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.

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

#109
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…

It reminds me of the broken window theory https://en.wikipedia.org/wiki/Broken_windows_theory : same as the toilet analogy, but more classy

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

#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 monolith, that might have some other benefits

Another contradiction (which mostly contradicts the general premise of the article):

>> We created plenty of diagrams, but none of them followed any strict rules. Just plain old boxes and arrows, similar [this one describing information flow] or [this one outlining class structure and relationships between components]

In the last link ([this one outlining class structure and relationships between components]), the article says:

>> If you have previously worked with the [VIPER] architecture, then the class breakdown of a RIB will look familiar to you. RIBs are usually composed of the following elements, with every element implemented in its own class:

... and then it shows some kind of class diagram which looks vaguely like UML in which the classes have highly architected names like 'Interactor', 'Presenter', 'View', 'Builder'... Nothing to do with the underlying business domain. Doesn't look like simple design to me. The recommended approach looks more like complex VIPER architecture.

Post reply on HN