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

31–40 of 174 posts

Re: Behaviours to avoid in a software architecture role

#31

Post by pc86 »

Geminidog wrote: post #23
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 bein…

I'm biased, as an architect, but you can't be a good software architect if you don't know the domain very well - both the industry as a whole, and your company specifically.

Re: Behaviours to avoid in a software architecture role

#32

Post by hertzrat »

bjornsing wrote: post #3

You only need one maxim for software architecture work: “Implementation ruins architecture!” :P

Maybe what you mean is “everyone has a plan until they get punched in the face” ? All good architecture starts with that idea in mind, so you optimize for making things as decoupled and changeable as possible.

Re: Behaviours to avoid in a software architecture role

#33

Post by pc86 »

TameAntelope wrote: post #15
NDizzle wrote: post #10

Earlier quoted context omitted.

Even when they have indefensible positions? When the idea doesn't hold up to ~2 hours of research?

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.

Exactly.

If you're arguing with your boss's boss's boss, who has worked at the company for five years and the industry for two decades, and you think you've unraveled their entire argument by reading a few blog posts, you're wrong approaching 100% of the time. Best case scenario is that you've missed something specific to your company, or industry, or the current technical implementation, or some obscure contract the previous CTO signed that they're still trying to get out of.

Re: Behaviours to avoid in a software architecture role

#34

Post by shagie »

dominotw wrote: post #26
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 archi…

This reminds me of the discussions back on wiki.c2.com of https://wiki.c2.com/?ArchitectsDontCode and https://wiki.c2.com/?ArchitectsPlayGolf

There's also https://wiki.c2.com/?NonCodingArchitectsSuck for a rant.

Re: Behaviours to avoid in a software architecture role

#35

Post by LgWoodenBadger »

Geminidog wrote: post #8
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…

I share your disdain for "Software Architects." I'm curious on your reasoning though. Can you expand on why you hold disdain for "Software Architects"?

For me, regarding the ones who don't actively code, it's something along the lines of "everything compiles on a whiteboard."

Re: Behaviours to avoid in a software architecture role

#36

Post by bluefirebrand »

pc86 wrote: post #33
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.

Exactly. If you're arguing with your boss's boss's boss, who has worked at the company for five years and the industry for two decades, and you think you've unraveled their entire argument by reading a few blog posts, you're wrong approaching 100% of the time. Best case scenario is that you've missed something specific to your company, or industry, or the current technical implementation, or some obscure contract the…

Or possibly you're extremely in the right but they have an ego the size of the moon and they will punish you if you bruise it.

Either way you lose.

Re: Behaviours to avoid in a software architecture role

#37

Post by nitrogen »

dominotw wrote: post #26
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 archi…

Can you think of more concrete language that applies equally to all organizations? If so please do share.

Sure, there are the Dilbert PHB-esque abuses of trendy lingo through mindless cargo culting. But the bigger and broader your goals, the more abstractly you have to describe them lest you end up writing a full-on textbook.

Having said that, I have to disagree that your examples are buzzwords. Buzzwords are usually contextless, like saying "synergistic impact" without any hint of what that means.

As just one example, "Probe assumptions" is not a buzzword. It has a clear meaning within the context of software engineering. For example it is often assumed by new grads starting a company that a startup just has to use Kubernetes and microservices. But that is an assumption that is worth probing. Horizontal scaling only becomes a bottleneck long after the millions of users point. Microservices are meant to help giant engineering teams isolate the things different teams work on, but in a startup with only one team you don't have that bureaucratic overhead in your org, so you probably don't need it in your code.

Re: Behaviours to avoid in a software architecture role

#38

Post by taeric »

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.

Hard disagree. Thinking you can separate form from function is the evergreen mistake of our industry.

Re: Behaviours to avoid in a software architecture role

#39

Post by dominotw »

nitrogen wrote: post #37
dominotw wrote: post #26

Earlier quoted context omitted.

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

Can you think of more concrete language that applies equally to all organizations? If so please do share. Sure, there are the Dilbert PHB-esque abuses of trendy lingo through mindless cargo culting. But the bigger and broader your goals, the more abstractly you have to describe them lest you end up writing a full-on textbook. Having said that, I have to disagree that your examples are buzzwords. Buzzwords are usually…

> Microservices are meant to help giant engineering teams isolate the things different teams work on, but in a startup with only one team you don't have that bureaucratic overhead in your org, so you probably don't need it in your code.

We had these discussions many times on our team. Everyone understands that there are tradeoffs and "pitfalls" associated with any decision. Isn't this just normal rational thinking? Is your assumption that ppl that aren't principals don't consider pitfalls. Do non-principals employees really think that there are no pitfalls to using microservices.

Re: Behaviours to avoid in a software architecture role

#40

Post by digitalsushi »

dominotw wrote: post #26
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 archi…

It's corporate mythos. Something that worked for someone long long ago was so successful that it became the corporate form of a folk song.

When we down near the bottom hear "lead by example", it's facile to find the nearly useless obvious veneer to it, but if we could attach the original odyssey that led that engineer to tell their story ... we might agree with the lesson. But retellings upon retellings compress, simplify and gloss the original story into a cliche.

Each thing in this list sounds obvious, but if one can picture the opposite of the advice to be false, that reflection might actually lead an individual to growth.

Post reply on HN