Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Architecture Is Overrated, Clear and Simple Design Is Underrated

blog.pragmaticengineer.com

Post reply on HN
Print view View original

161–170 of 218 posts

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

#161

Post by tootie »

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…

I was an enterprise architect for about a year and it was dullest most soul-sucking job I ever had. In a sense, it was incredibly cushy. I had zero responsibility. I could easily just drop technical decisions on teams and not have to deal with the repercussions. But it really just drove me nuts. And I hated the other architects because they had set this system up and seemed perfectly content.

My role before and after as a director was always to give my tech leads a really long leash. I try to never force decisions on them, but rather let them work their own way and my job is just to make sure they've considered the project goals correctly and their solution is going to fit.

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

#162

Post by mac01021 »

jacquesm wrote: post #28
StreamBright wrote: post #24

Earlier quoted context omitted.

Exactly. I never got into OOP design patterns and my co-workers could not convince me this is a good idea. I thought for a while that I am crazy but then I got to know Erlang and Clojure. Joe and Rich set me straight on software design. >> Keeping code simple is not easy. It takes a lot of trials and errors to know what works and what doesn’t. Refactoring helps. I usually achieve 20-40% reduction with the first refac…

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.

Are you able to provide any more detail about what the simulation had to do, and how OOP helped?

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

#163

Post by GuiA »

userbinator wrote: post #134
GuiA wrote: post #12

Earlier quoted context omitted.

Well yes. It all sounds all so easy when you put it like that. The problem is that, in my experience at least, you can’t just teach junior engineers how to go straight to phase 3. You have to go through phase 1 and 2 to really develop a sense for what makes a solid, streamlined design. Some never get there - either because they become set in their ways early, or because they work in organizations where the wrong kind…

I think the state of CS education is actually responsible for a lot of overabstraction; students are taught early to worship abstraction (because of all the buzzwordy benefits it allegedly brings) and apply it liberally, and not taught when not to do it. A good way to counter that might be to get them to read early opensource code (e.g. first few versions of UNIX, some BSD stuff, etc.), which I think is mostly an exa…

Yes, curricula tend to focus on writing code over reading code, which is a shame. Looking at existing code, extending it, refactoring it, etc would ideally be something that students do as much as writing things from scratch.

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

#164

Post by Michielvv »

I personally feel that software architecture isn't so much overrated as too much focused on abstract patterns instead of how to best solve common problems.

e.g. last year I needed to model an invoicing system, although this has been implemented hundredths thousands of times, there is very little generalized information on how to best do that so that it doesn't fall apart next year.

The areas that currently are better at this are mostly related to security and operations.

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

#165

Post by bradenb »

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…

I feel like an "Architect" should not be a standalone role. The architect for a project should be an engineer working on the project that can make decisions about the underlying architecture when a decision is needed.

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

#166

Post by jacquesm »

mac01021 wrote: post #162
jacquesm wrote: post #28

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.

Are you able to provide any more detail about what the simulation had to do, and how OOP helped?

Lots of mechanical linkages interacting with each other. Move one and everything else moves as well. Gears, shafts, levers, chains (modeled as independent links), that sort of thing.

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

#168

Post by goto_self »

stinos wrote: post #147
obstacle1 wrote: post #124

A big problem IME is people tend to define "simple" as "written in a style I prefer". For example you can extract a series of 10 obviously-related methods from some 2000-line God class into their own class, but have others who are used to a more procedural coding style complain that the indirection is "hard to read" because they need to open a new file. This despite the facts that others find the God class "harder to…

2000-line God class ... "hard to read" because they need to open a new file Might be me, but I've always found this a rather strange argument: either they aren't using 'go to definition' which means that to be able to read the other code they have to scroll through the file manually, leaving where they are, and then go back. That's not really convenient? Or they are using 'go to / peek definition' and then it doesn't…

I have counterpoints on both ends here.

It's not always possible for a "goto definition" function to work in dynamic languages.

If you're in a large file, it's quite easy to jump around with line marks (a la vim), searching, etc.

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

#169

Post by yodsanklai »

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…

You can't beat simplicity, but software aren't planned entities. They evolve from the collaboration of multiple persons with a variety of skills and personalities, working together to meet deadlines.

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

#170

Post by EGreg »

JMTQp8lwXL wrote: post #18
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…

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 general I have found — over 20 years of experience architecting software - the following:

1. Platforms and reusable frameworks should be architected as well as possible. Apps can be whatever.

2. A developer who writes clean code and documents it is far better than a “10x” developer, unless you have budget for only one developer.

3. Functions should have extensibility, put the required parameters as parameters and always include an “options” at the end. Each function can have defaults that you can extend, which means you need a deep-extend method:

https://qbix.com/platform/guide/javascript#functions

4. When in doubt whether to do convention A or B, take a bit more time to do C which can handle both, and add the convention in a config. You never know when someone may need something else!

5. Similar to 4, if you can have an extra indirection, add it. So you can let others hook into “before” and “after” hooks at any point. Use events instead of functions.

6. In fact try to have event driven architecture rather than futzing around with mutating data. The easiest way to sync is to maintain a linear total order for events.

7. Think about how lookups will proceed and partition everything by those keys. Sometimes you need to have duplicate tables and keep a sync from a “primary” table to a “secodary” one in the app layer. Doing this allows you to do sharding or even go serverless peer-to-peer later!

8. Security: more checks are better than less. Pile on private keys, bearer tokens (api or cookie), and so on. Use a device keychain:

https://qbix.com/blog/2018/01/17/modern-security-practices-f...

Post reply on HN