Live data from Hacker News

Software Architecture Is Overrated, Clear and Simple Design Is Underrated

blog.pragmaticengineer.com

81–90 of 218 posts

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

#81
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.

Architecture for something that is only actively developed for say 5 years is pretty uninteresting. You can make better or worse architectural/design choices, but you never really test whether the choices were sound if you don't maintain it for a longer time.

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

#82
I went to a course by Udi Dahan once, about CQRS. One of the people asked him a question about CRUD. Something along the lines of how would you use CQRS for simple CRUD operations. And Udi was like "just go to the database".

The guy kept asking the same question different ways like Udi didn't understand the question. The response was always the same. Then Udi said, if you need to go to the database, go to the database, don't over complicate things.

It was like a lightbulb for me, having spend ages always trying to fix everything into an abstraction of some sort instead of just getting stuff done.

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

#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. But hey, all our developers are TOGAF certified these days, so that's something!

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

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

When I couldn't program I almost achieved more! I saved time by picking stuff up and glueing it together. Then later spent ages learning specific softwares, plugins and their wiring only for them to fall out of favour. Later frameworks etc.

A web outfit I worked at should have concentrated on a few small plugins/components that would have handled most of their sites. Instead other behemoths emerged, that added pain and complexity to what should have been very simple sites. Only the author understood the ins and outs of a half finished product, that ended up bastardised for each project, resulting in multiple version hell. But hey this was before good 'Git'ing. Oh for hindsight.

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

#85
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 don't even think it's a phase. From what I see in my own experience, overengineering comes from not having a deadline to deliver an actual working piece of software. Unclear requirements. Fear that the code must be perfect against change without knowing what the changes might be. Underengineering comes from confidence that the issues are too small to worry about. Or the time constraints mean I can't try to find goo…

I have been writing software professionally for almost 30 years now and yes, this is exactly what I see too. I find the underengineering far more productive though; because of time constraints I hack something together which works but is brittle (decades experience do help fight the brittleness even in a hurry though) and I do revisit to fix and refactor if the software survives.

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

#86
post #78

Earlier quoted context omitted.

Most devs prepare for the abstraction nirvana. I see a lot of fellow devs creating complicated code, because "in case we need to switch out the database down the road" or "what if we want to run the web app in CLI" In 20 years of programming I maybe seen one or two times a large application switched database engines and I've never seen a client want to run his/her web application in CLI... The art in programming is t…

It's not just programming, though. A large part of it is defining the product roadmap: code can get a lot better if a product team has the guts to unequivocally say that some features are not going to be part of the product, ever, such as running the web app in CLI. That's not just a programming decision - though I guess influencing the product roadmap could be seen as part of the art in programming as well.

Yeah I had a manager that was quite good at throwing out functionality. Didn't like it at the time, but they were mostly right - of course they were just trying to save money.

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

#87
post #61

Earlier quoted context omitted.

Out of curiosity what kind of projects are that small? I guess I have hobby projects that are that small, but all my professional work is large, enterprise systems that wouldn't fit in 10 files if they tried. Makes sense when things are so small to only use what you need. Sounds like you made a reasonable decision for the kinds of things you work on. But when you get past a certain size actual architecture becomes ve…

I find 90% of the complication in large enterprise projects come from the developers trying to write too much architecture and not enough simple, boring, imperative code. At the moment I'm staring at a validation framework and 6 layers of validator inheritance who's job it is to verify that one number is bigger than another one. That's just for one tiny part of the overall system, nearly everything has to be in some…

I currently have the opposite problem. Staring a system with zero frameworks where every time the developer wanted to do something they didn't reuse an existing solution, they simply wrote a new one. So there's 10 different ways to create a customer and now there is a requirement to change some validation. It's a major high-risk overhaul of the system to change the validation on a single field of a single entity.

I've seen big enterprise systems that had solid architecture and I quite enjoyed working with them and I've seen the trash-fire variety too.

Abstraction can be wonderful. Abstraction can be ghastly. It's how you wield it. Well designed systems are just that. Well designed. They have solutions that fit their current problems well and make just enough room for the problems of tomorrow, but not for the unanticipatable problems beyond that.

Poorly designed systems don't have solutions that fit their current problems well (or at all), and/or don't have solutions that are amenable to tomorrows problems or have solutions well suited to tomorrows problems, but not todays, or have solutions that fit imaginary problems they will never have.

I think that's what the article fundamentally hints at. Taking the time to look at the problem and taking the time to derive and refine a well fitting solution. If you can do that, you've won.

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

#88

Earlier quoted context omitted.

Out of curiosity what kind of projects are that small? I guess I have hobby projects that are that small, but all my professional work is large, enterprise systems that wouldn't fit in 10 files if they tried. Makes sense when things are so small to only use what you need. Sounds like you made a reasonable decision for the kinds of things you work on. But when you get past a certain size actual architecture becomes ve…

Not OP but couldn't you split up you project to smaller projects? >> But when you get past a certain size actual architecture becomes very beneficial. This article and only rejects the convoluted architecture approach with design patterns and suggests that you can come up with your own design without using these. It is not arguing that there is no need for architecture at all.

>Not OP but couldn't you split up you project to smaller projects?

My own personal stuff I can do whatever I like with, work stuff I don't have much say over. Could they be split up? Oh, yes. Does it need to be 1 million lines of code? No... I think it could probably be about 1/5th to maybe even 1/10th of that.

But still, even if it's split into microservices or just smaller modules, the aggregate lines of code required to solve the entire business problem is still a great deal larger than will fit into 10 well crafted files. Was just curious the nature of the work that naturally fits into that size.

>This article and only rejects the convoluted architecture approach with design patterns and suggests that you can come up with your own design without using these. It is not arguing that there is no need for architecture at all.

I think this article is great. I took this article to be advocating for taking a good hard look at the problem at hand and really nutting out a solution that fits it well. It doesn't reject design patters, per se, it rejects not properly thinking things through.

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

#89
post #57

Earlier quoted context omitted.

Over my career, I've worked with engineers that like to over-engineer and under-engineer. The over-engineered code looked like russian dolls: had many layers to it, and some of the abstractions offered no value. That can make onboarding to such code unnecessarily complex. On the other hand, under-engineered code made very little of use of even simple data structures or algorithms. I like to call it "chicken scratch"…

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 algorithms and program designs on paper, actually touching a computer is the last step in that process.

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

#90
post #62

Earlier quoted context omitted.

It's an English idiom. See [1], point 3. [1] https://en.wiktionary.org/wiki/cute#Adjective

Thanks! I ignored this meaning (not a native speaker). Feeling a bit ridiculous now...

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.”
Post reply on HN