Software Architecture Is Overrated, Clear and Simple Design Is Underrated • Hacker News Board

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

#201

Post by cestith » Wed, Sep 18, 2019, 8:46 PM UTC

As a developer I find I'm paid very little for lines of code. I'm paid primarily for making decisions and for recording those decisions clearly.

Application source code is one way those decisions are recorded. Call graphs, data flow graphs, help text, application documentation, API documents, troubleshooting guides, monitoring code around production applications, tests, configuration and build management files, and commit messages are others.

Given that point of view, here's my advice.: Make the source and the other artifacts as simple as possible, but no simpler. Cross-reference where it helps most, but not excessively. Compose things from modular pieces rather than building monoliths when you can. Document the parts and the whole.

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

#202

Post by naikrovek » Wed, Sep 18, 2019, 9:34 PM UTC

amelius wrote: post #121

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…

It looks like you were applying design patterns "just because". Obviously this is not a good thing. A better approach is to take some time and think about all the requirements of your project, and to take into account what requirements might be added later. With that in mind, you can choose the abstractions that you need, and from there start coding. That way, your design patterns start working for you instead of aga…

yes, and the problem is that carefully engineering your solutions is not what's taught; applying design patterns is what's taught, both in college and at most/all large employers (certainly all of the ones I've worked for.)

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

#203

Post by barrkel » Wed, Sep 18, 2019, 10:59 PM UTC

uber99953 wrote: post #176

barrkel wrote: post #119

Earlier quoted context omitted.

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

It's an architecture that's almost completely mute on how business-level functionality should be organized.

Generally software architecture solves for non-functional requirements, rather than functionality. Product managers organize business-level functionality.

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

#204

Post by jamesb93 » Wed, Sep 18, 2019, 11:05 PM UTC

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

You should clarify that your experience us pretty much exclusive to web development which is bot indicative of a lot of work that goes on in software creation and computer science research. Just a weird nit pick of mine that most people here seem to be web devs who assume everyone else is - it creates a weird environment for discussion.

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

#205

Post by xcubic » Wed, Sep 18, 2019, 11:29 PM UTC

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

From someone doing webdev but without studies, is there a small list of simple data structures or algorithms that you would recomend?

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

#206

Post by pvorb » Thu, Sep 19, 2019, 5:59 AM UTC

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…

In my company, every software engineer also has the software architect role. This way everybody is aware that they are welcome to think about the architecture of software. There are no dedicated architects. This works quite well in my experience.

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

#207

Post by woolcap » Thu, Sep 19, 2019, 6:44 AM UTC

jbn wrote: post #148

abtinf wrote: post #90

Earlier quoted context omitted.

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

not to nitpick any more than necessary, but I don't think that's entirely correct: "I have ignored" implies that GP knew the meaning and intentionally did not address it, while "I ignored" is correct and also means “I was unaware of this meaning” or “I didn’t know that.” ... at least that's how I see it.

"I ignored..." = I was aware, but consciously chose not to address it, but perhaps softer than, "I consciously chose not to address it. "I ignored the fact that the sun was out, and returned from the beach sunburned." (I knew the sun would burn me, but went out anyways, with perhaps a shade of not realizing how much I would get burned.)

"I was ignorant of..." = I was unaware. "I was ignorant of the fact that the sun causes sunburn, and returned from the beach sunburned." (I didn't realize the sun would burn me.

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

#208

Post by PeterStuer » Thu, Sep 19, 2019, 7:08 AM UTC

"I know of banks and automotive companies where developers are actively discouraged from making any architecture decisions without going up the chain" ... "So these architects create more formal documents, in hopes of making the system more clear, using much more of the tools the common literature describes."

Having consulted in such environments you have to remember that most of the large projects there are implicitly expected to fail, so CYA has become ingrained very deeply into the culture.

I stopped taking these jobs once it fully dawned on me that getting results in terms of on budget, on time, delivery while delighting users was never the prime objective, but using each project as a battleground in a perpetual internal jousting match for power grabs was.

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

#209

Post by fnord123 » Thu, Sep 19, 2019, 7:22 AM UTC

tluyben2 wrote: post #85

fnord123 wrote: post #77

Earlier quoted context omitted.

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.

Underengineering is far more productive but not always possible when you're defining the overarching architecture of a multi team project.

Then you have to rely on experience to do things like definelibg interfaces that can be extended later on instead of overspecifying types. It's hard to balance it just right.

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

#210

Post by moksly » Thu, Sep 19, 2019, 7:32 AM UTC

blub wrote: post #133

moksly wrote: post #32

The value of Enterprise Architecture doesn’t come in to play until you’re an actual Enterprise. We operate more than 300 IT systems, from a myriad of different and switching (courtesy of procurement) suppliers. These systems are operated by 5000-7000 employees, and range from making sure employees get paid and patients get the right medicine to simple time booking apps. Most of these systems need to work together, an…

I've seen you mention your organization and the challenges you're facing few times and I'm curious what kind of architecture books or principles you'd vouch for based on your experience.

It’s build around our own version of TOGAF, but I’m not sure I’d really recommend that to anyone. It’s also more political than technical and suffers from a lot of “not invented here” even in competition between different government agencies and changing bosses.

A good example is the OIO standard we use to model most our abstract data design. It’s basically a local standard, which means it’s different from the EU standards that do the same. Which again means, that we had to work with Microsoft to get OIOSAML working with ADFS and are still working with them for Azure AD, and it may all be in vain when we eventually swap to EU standards as the rest of Europe catches up.

The thing is though, we started the journey before there were EU standards, and a lot of the decisions that seem bad today were right at the time. Over all, it’s still a pretty huge benefit to what was before.

To get back to your question. The thing I’ve done that has been the most useful in EA hasn’t been TOGAF or any of the other EA focused frameworks. It’s been the year of political science I took at the university, I think it equals to part of the American MBA but more focused on Enterprise Admin and HR. Because Enterprise Architecture is mainly about understanding the business on its terms and finding the compromises to make your tech sector understand it. I think being able to communicate and understand your business is a lot more important than whether you map things in X framework. I mean, your developers are probably going to understand your PowerPoint drawing just as well as your UML/ArchiMate anyway, and the less tech details you define, the better because the article is actually right about developers knowing better how to build things. If you tell them how the data is mean to be understood by any system that receives a User object, then you won’t have to tell them how to handle it beyond that.