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

71–80 of 218 posts

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

#71

Post by verall »

rumanator wrote: post #15

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…

Because UML is generally about defining processes, and it is easy to accidently try to poorly "code" parts of the system in UML, processes that might be easier represented in code. If there is distinct process that is complex/important enough to be architected, by all means use UML.

Normally, at a high level, where people are architecting, what is more important is flow of information and containment of responsibilities. UML is not really designed for describing these situations, and trying to wedge this type of information into a UML diagram can get confusing and can encourage architects to focus on the wrong things.

When people say "box and arrow diagrams", I think that to mean boxes=infomation+responsibilities arrows=information flow.

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

#72

Post by closeparen »

Hokusai wrote: post #49

> However, no one person owned the architecture or design. The experienced developers did drive this. The lack of formality does not mean a lack of the role. If "experienced developers" are the ones doing the design. They are de-facto architects. > No mentions of microservices, serverless architecture, application boundaries, event-driven architecture, and the lot. Some of these did come up during brainstormings. How…

Central, top-down architecture is extremely political. You have to fight with bigwigs who don't know your problem domain and don't live in your codebase to make it reasonable, or even possible, to solve the business problems on your plate when they inevitably don't fit the 10,000 foot 5-year plan.

Pushing down architecture responsibilities into the hands of senior engineers with specific problems to solve / features to build eliminates that form of politics. They are not disguised architects, because designing the architecture is only phase of the project. They also have to live with the architecture. This is a great thing.

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

#73

Post by liha »

It’s interesting how OP talks about the process as something unique and groundbreaking. Honestly that’s how 90% of the tech companies handle architecture and design - a bunch of people whiteboarding solutions and drawing box diagrams and writing down notes. In 12 years I haven’t worked at any company that uses the tools he mentions. Experience usually drives the output and the result of the mentioned “process”. An experienced engineer in the room is more likely to bring up non-functional characteristics and related concerns such as performance, security, high availability etc. You can choose not to have a formalized architecture process or review and you can also choose to just draw boxes which link to each other without completely making sense - like a class with an arrow pointing to a machine and another arrow pointing to a process (which is fine until a couple of years later, someone looks at a dangling process in the diagram and wonders which machine/container it’s running on). Obviously Ymmv because it’s not some “predictable” process and purely relies on drawing out the collective experience and intelligence of the room

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

#74

Post by mrpickels »

I read the comments and see there are two types of engineers - conservatives and liberals, those who work for big corporations, draw UML diagrams with factories, bridges and facades and throwing arguments that because of some regulations or privacy policies your architecture can change and you need to be prepared for it. Those guys are right.

More liberal engineers are saying that keeping code simple is the key and to keep it simple you need to be smart and creative. Those guys are right as well.

Now back to reality, the conservative developers will always work on the code that was written by liberal developers because the latter deliver sh*t in time that works and carry the business on their shoulders, where the first makes it work in another scale.

Conclusion - there are different types of engineers and our responsibility is to accept that humans are not machines and somebody likes to CREATE vision and value, others like to manage huge system that are complex.

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

#75

Post by vnorilo »

I think the underlying art is in striking the right balance between the specific and the general. In studying PLs for almost a decade now, I always ask PL designers I meet to try and distill their wisdom in one sentence. Andrew Sorensen said something along the lines of "Avoid all abstraction".

That shocked me, because my pet theory at the time was that abstraction was basically a force multiplier: good abstraction makes everything exponentially better, while bad abstraction makes everything exponentially worse.

Nevertheless that quote stuck, and later I've started to appreciate it in terms of the YAGNI arguments.

Regarding abstraction, I've come to believe that a common anti-pattern is deductive abstraction: working down from a general pattern towards a specific implementation. This resembles what a sibling comment called "applying all sorts of design patterns from books to my code" (and not getting great results).

The opposite, inductive abstraction, is starting from a specific task and introducing gradual abstraction. Abstraction in lambda calculus is a beautiful example of the concept. Now make that thing a lambda term!

There's a Bret Victor classic that touches these themes [1].

[1]: http://worrydream.com/LadderOfAbstraction/

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

#76

Post by saiya-jin »

galaxyLogic wrote: post #36
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…

>started getting cute with it and applied all kinds of design patterns Even though there are books about design patterns, taking such a book and trying to "apply" its patterns is a bit backwards I think. The idea of patterns is they describe commonly useful solutions, not designs you "should" use. Once you started to code in "pragmatic, minimalistic way" I assume you found you could apply the same solutions you had f…

I agree with you, but that's not how people usually progress. Its more in line with initial discovery of 'the best and battle-tested way to design code'. Immediately they try to apply patterns anytime they see an opportunity for it. They must be taken more seriously from now on, right?

I get it, I went through exactly same hoops. My guess is, we all desperately want to be those aged and wise devs that nail the implementation in first go, without hesitation, knowing exactly what to expect and avoid, covering all corner cases with some elegant snippet. And learning about patterns feels like the surest way to get there.

Of course as we know now that's far from truth, path to seniority can't be fast-tracked by reading a book or two and that's it. But inferiority complex is rife with junior devs, I mean you think you know a bit and then you encounter a codebase where you are completely lost. You see tiny piece of code that takes forever to decipher and fully understand. Who would feel great at that moment

KISS was a thing 20 years ago, any probably even 40 years ago, there is no need to think now its different

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

#77

Post by fnord123 »

stinos wrote: post #57
JMTQp8lwXL wrote: post #18

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 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 good primitives to make something robust. And if I have to return to it because it's so important, I can re-engineer it then.

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

#78

Post by Vinnl »

feketegy wrote: post #58
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…

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.

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

#79

Post by rgoulter »

mrpickels wrote: post #74

I read the comments and see there are two types of engineers - conservatives and liberals, those who work for big corporations, draw UML diagrams with factories, bridges and facades and throwing arguments that because of some regulations or privacy policies your architecture can change and you need to be prepared for it. Those guys are right. More liberal engineers are saying that keeping code simple is the key and t…

I like the interpretation of 'conservative'/'liberal' as applied to engineering practices which Steve Yegge wrote (in a lost Google+ post): "acceptability of breaking code in production".

'Conservative' developers really wants to 'conserve' what's there. I feel that description suits both the 'draw UML diagrams with enterprise patterns' as well as 'loves dependent types' kinds of people.

In this sense a liberal 'keep code simple' is more about things like "You Ain't Gonna Need It", and focussing on writing what code is needed now. (Since it doesn't matter if it needs to be broken later as requirements change).

Post reply on HN