Live data from Hacker News

Software Architecture Is Overrated, Clear and Simple Design Is Underrated

blog.pragmaticengineer.com

111–120 of 218 posts

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

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

overengineering comes from not having a deadline

This really resonates: at the height of the phase I spent about 2 years once, half-time developing something new for which there was essentally no deadline. I went totally berserk doing insane stuff like implementing design patterns using templated 'reusable' classes in C++ so whenever something even remotely looked like a pattern I had a class for, I would use that class. Which then needed small fixes of course. And extra logging. Pluggabble. Etc, you get the point :) In the end everything was dropped because I found a much better, much simpler, existing way to do everything though.

But didn't happen to me again afterwards, or at least not to that extent: it was really like having had a severe electric shock; once, but never again, before even coming close to any hot wire my brain is already subconsciously screaming to get away from the thing a.s.a.p.

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

#112

Earlier quoted context omitted.

This reminds me of the framework va libraries argument or ORM vs raw SQL. Yes frameworks and ORMs can be constraining and limit clever solutions. But when you need to add complex features to a complex project you are always glad that every other programmer that came before you was constrained and that things use a familiar pattern.

I've encountered spring/hibernate projects in the with lots of performance and integrity issues that were easy to straighten out by just cutting out the orm layer and replacing it with non magical, simple SQL. Magic is nice when it works but when it stops working and you lack the skills on the team to make sense of it, things get ugly quickly. This happens exactly when you are adding complex features that stretch the…

I actually love magic, but boy oh boy are you right when it comes to hitting a wall and getting absolutely stuck when magic happens.

I've spent a bunch of time thinking it through and I've come to the conclusion that it isn't actually the magic that is the bad part. It's the lack of the discoverability that is bad. I guess that's why it's called magic right? Because you don't know what the trick is, yet it appears to work...somehow.

I call it dark magic. Magic that is not discoverable and makes no attempt to help you discover it. On the other hand, if you put magic into a solution because you are a wizard and you want to leverage the stunning super powers that magic gives you, if you can also tell everyone how the tricks are being done... it's actually possible to get the best of all worlds.

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

#113

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…

We have a great architect right now, but he's really just an engineer designated as the "architect". He also codes sometimes.

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

#114
I agree with the post, and this works at companies like Facebook and Uber, which have very high hiring bars, impact-oriented internal cultures and can afford to pay a bonus if you help the company be successful.

The interesting question is, what should all the other companies do? They cannot hire the best people, that aren't cash-rich, so cannot incentivize people. If you rank companies, what about the ones hiring the bottom 25%? They also want to write software to help run their business.

I'm not saying software architecture is the answer, but the [hidden] assumptions in the post break down and don't apply.

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

#115
Hm... good software architecture is always clear and usually simple. So I think the title here is self-contradictory.

I do agree with usually using custom diagrams rather than, e.g., UML ones. Diagrams need to communicate. The problem with the formally defined ones is that they communicate what they are specified to communicate, not what you need to communicate. As a result you end up with perhaps multiple diagrams to cover the concept, or you need to add text or an ill-fitting custom overlay or custom exceptions, etc. Also, people who don’t create these diagrams regularly (a large part of your intended audience) have trouble remembering all the intricacies of the diagram language, so important concepts are made obscure rather than clear.

Anyway, you want to be focused on communicating certain concepts, not building a correct diagram.

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

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

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…

>Out of curiosity what kind of projects are that small?

A lot of open source projects with a tight focus which solve a specific problem very well.

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

Most of my enterprise work could be broken up into loosely coupled subprojects of that size similar to open source. IME that doesn't tend to happen, but it could.

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

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

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…

I find the benefits of abstracting away database, isn't so you can swap.

It's that' the high-level business logic does not have any low-level unrelated persistence code in it.

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

#119

Services at Uber are pretty much all stateless Go or Java executables, running on a central shared Mesos cluster per zone, exposing and consuming Thrift interfaces. There is one service mesh, one IDL registry, one way to do routing. There is one managed Kafka infrastructure with opinionated client libraries. There are a handful of managed storage solutions. There is one big Hive where all the Kafka topics and datasto…

What you describe is an architecture, of course, and it didn't happen by accident.

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

#120

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"…

I think you can under engineer and still use a pragmatic functional style. Also yes when it’s under engineered you usually have to touch multiple parts to make a change, but in the end it usually take less time (testing for bugs included since the code is simpler). Edit: I don’t say under engineering is perfect, but compared to an over engineered code base I prefer the first for maintainability.

> I think you can under engineer and still use a pragmatic functional style.

I actually believe this, and tried in some occasions for my personal projects.

When you develop the code further, you need to touch everywhere. It starts very neat and being extremely tidy at first, but when you need to add some significant features, the design breaks down pretty badly.

Then, to save the architecture, some significant refactoring runs are required, and boy, these refactorizations are expensive both time and design-wise.

If your project will not add new features over time and relatively compact, under-engineering can deliver pretty nice results. Otherwise, designing with some headroom and flexibility goes a long way.

Post reply on HN