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

Behaviours to avoid in a software architecture role

danielwatts.info

Post reply on HN
Print view View original

21–30 of 174 posts

Re: Behaviours to avoid in a software architecture role

#21

Post by Geminidog »

sjburt wrote: post #13
cek wrote: post #7

21 years at Microsoft led me to have great disdain for "Software Architects". 5 years at Amazon led me to fall in love with the concept of a community of Principal Engineers. The Amazon Principle Engineering tenets are amazeballs. Exemplary Practitioner - Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implement…

These seem like totally different roles. And the hours I've spent staring at the AWS console trying to figure whether I need "Elastic Beanball3" says to me that Amazon could use maybe just a little architecture. But I'm sure the Beanball Principal Engineer is quite proud of their resounding impact.

The console is a UX/UI issue, not a "architectural" one. Most "architects" nowadays are just mere users of what was built by the engineers and principal engineers of amazon.

Re: Behaviours to avoid in a software architecture role

#22

Post by mateo411 »

willvarfar wrote: post #14
theptip wrote: post #6

Earlier quoted context omitted.

The article explicitly covers that one: > 2. Don’t ignore the domain It’s part of the role to become a domain expert. This knowledge can be used to act as an effective translator between business and engineering.

-shrugs- I don’t get that from that paragraph, but I guess it depends on how one thinks the author means “domain”. I’m used to meeting “domain experts” who know all about the corner cases in the current implementation. Often they are the people who argue with the suits and it never ends well for them.

That doesn't sound like a domain expert. This sounds like somebody who is pretty familiar with the current implementation.

A domain expert understands the business use case and the market. I would say they can act as a good Product Manager.

Re: Behaviours to avoid in a software architecture role

#23

Post by Geminidog »

sjg007 wrote: post #12

People downplay software architects but I've found it's a critical role. You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality. A lot of business logic ends up encoded in the software so you really want to isolate it as much as possible so that when change is needed you know where to look. That and you have to c…

> You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality

This is the Technical product managers job. The architects role is suppose to be an extreme high level view of purely the technical side of the business.

From my own anecdotal experience "architects" who try to fulfill the role to the definition end up being mostly useless.

Re: Behaviours to avoid in a software architecture role

#24

Post by TameAntelope »

vmh1928 wrote: post #19
TameAntelope wrote: post #15

Earlier quoted context omitted.

Especially then, because if that's the case then you know there's more to this story than just what you're experiencing in that moment.

2+2 = 5 situations.

In my experience it's rarely (read: never) that clear, is my point. When it's that "obviously" wrong, there's almost certainly something you don't understand.

Re: Behaviours to avoid in a software architecture role

#25

Post by theptip »

willvarfar wrote: post #14
theptip wrote: post #6

Earlier quoted context omitted.

The article explicitly covers that one: > 2. Don’t ignore the domain It’s part of the role to become a domain expert. This knowledge can be used to act as an effective translator between business and engineering.

-shrugs- I don’t get that from that paragraph, but I guess it depends on how one thinks the author means “domain”. I’m used to meeting “domain experts” who know all about the corner cases in the current implementation. Often they are the people who argue with the suits and it never ends well for them.

It's specific jargon in the Domain Driven Design community; "domain" == "business domain". Some of the links in that section of the OP give more detail.

I recommend DDD in particular, it's a great architectural framework, though it's a bit dense and hard to approach.

A good starting point: https://martinfowler.com/bliki/DomainDrivenDesign.html

Re: Behaviours to avoid in a software architecture role

#26

Post by dominotw »

cek wrote: post #7

21 years at Microsoft led me to have great disdain for "Software Architects". 5 years at Amazon led me to fall in love with the concept of a community of Principal Engineers. The Amazon Principle Engineering tenets are amazeballs. Exemplary Practitioner - Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implement…

This is a bit too buzzwordy for me.

> Resounding Impact

> game-changing technology choices.

> aligning teams toward coherent architectural strategies.

> lead by example

> pioneer new spaces

> inspire others as to what’s possible.

> pragmatic problem solvers

> bring clarity to complexity

> illuminate pitfalls

> probe assumptions and foster shared understanding.

This perfectly illustrates why ppl dismiss software architects that they hide behind silly buzzwords without delivering anything tangible.

Re: Behaviours to avoid in a software architecture role

#27

Post by craftinator »

TameAntelope wrote: post #18
steve_adams_86 wrote: post #11

Earlier quoted context omitted.

I agree. This is the classic “you don’t understand it if you can’t explain it” problem. If you don’t have the domain nailed down in plain speak, there are risks to productivity - especially if an entire team is involved. Business logic becomes open to interpretation at implementation time. That means a different solution for any developer who happens to implement it, and each one potentially incorrect and unable to i…

It's why "naming things" is one of the hardest problems in CS! It's hard to work with someone who doesn't get that.

I consistently have to argue with my brother about this, who started developing in the 90s and has a perfect memory for mapping terms to abstract objects.

He argues that at some level, every construct is just assembly that shuffles bits around, so nomenclature doesn't matter (he also grew up with Perl as a first language...). My argument is that it makes his code unreadable without a graph unraveler.

Re: Behaviours to avoid in a software architecture role

#28

Post by joncrane »

swirepe wrote: post #16
offtop5 wrote: post #9

I'll add another one, don't openly confront the CTO. Basic things what you should learn at your first job somehow get lost upon experienced software engineers.

>I'll add another one, don't openly confront the CTO. Looks like we found the CTO :)

Nope, we found someone who, shortly before a low point in their career, openly confronted a CTO.

Re: Behaviours to avoid in a software architecture role

#30

Post by otabdeveloper4 »

Geminidog wrote: post #21
sjburt wrote: post #13

Earlier quoted context omitted.

These seem like totally different roles. And the hours I've spent staring at the AWS console trying to figure whether I need "Elastic Beanball3" says to me that Amazon could use maybe just a little architecture. But I'm sure the Beanball Principal Engineer is quite proud of their resounding impact.

The console is a UX/UI issue, not a "architectural" one. Most "architects" nowadays are just mere users of what was built by the engineers and principal engineers of amazon.

AWS services don't mesh nice with each other, and the reason "software architecture" exists in the first place is so that disparate teams and technologies play nice with each other.
Post reply on HN