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

81–90 of 174 posts

Re: Behaviours to avoid in a software architecture role

#81

Post by btilly »

zippergz wrote: post #71
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…

After many years at big tech companies, I am now working at my first that has "Architect" as a separate role. While many of my colleagues in that role are great people and very smart, after a few years of living with it, I strongly believe that it's an "org smell" and I will seek out companies without it in the future. It creates completely the wrong dynamic to have the hands-on engineers, no matter their seniority,…

It gets worse. The transition from "programmer" to "architect" results after a few years with the architect losing track of where the rubber meets the road. This results in worse architecture decisions that are made by a similarly experienced programmer.

This effect is so strong that if you're interviewing someone who became an architect, make them write code in the interview. If they don't do it really well, you don't want them in ANY role. Because now they can't program, they can't architect. All that they can do is sound smart while they make bad decisions.

Re: Behaviours to avoid in a software architecture role

#82

Post by humbleMouse »

btilly wrote: post #81
zippergz wrote: post #71

Earlier quoted context omitted.

After many years at big tech companies, I am now working at my first that has "Architect" as a separate role. While many of my colleagues in that role are great people and very smart, after a few years of living with it, I strongly believe that it's an "org smell" and I will seek out companies without it in the future. It creates completely the wrong dynamic to have the hands-on engineers, no matter their seniority,…

It gets worse. The transition from "programmer" to "architect" results after a few years with the architect losing track of where the rubber meets the road. This results in worse architecture decisions that are made by a similarly experienced programmer. This effect is so strong that if you're interviewing someone who became an architect, make them write code in the interview. If they don't do it really well, you don…

I don’t buy this analysis. The principles of architecting code and system design are timeless. There are definitely people out there who don’t “code really well on command”, but can ask the right questions to design a solid system.

Re: Behaviours to avoid in a software architecture role

#83

Post by zug_zug »

>> 4. Don’t just seek architectural consistency

I don't know what the author has in mind, but I plainly disagree when stated as a general rule like this.

Examples: Try to get every server on the same OS by default, same packages, standardized networks, health check at the same path, prefer the same port, deployed with standard jenkins jobs, use a standard versioning scheme, use the standard branching model, standardize logging, standardize error-handling, standardize datastores, use standard login/security.

Re: Behaviours to avoid in a software architecture role

#84

Post by bob1029 »

arethuza wrote: post #4
bob1029 wrote: post #2

#2 is probably the most important. How you model the domain is the most foundational part of any software system. If everyone on your team looks at your domain model and thinks "yep that makes total sense", then it is very likely the rest of the project can be made to go smoothly. If the meaning of a Customer or User in your system is ambiguous, or has certain nuances privy only to the architecture team... this is wh…

I once spent a long time trying to work through all of the complexities just for what "Customer" meant in one fairly large organisation. Pretty much all followed from one chap asking "if a customer consolidates it finance team from being at each of their 40 sites in one country to 1 shared service centre, do we lose 39 customers"?

Identifying bounded contexts is a critical part of organizing extremely complex systems. You might have a Customer model that supports all contexts of usage, but in a certain bounded context you could know that only certain things from that type are applicable. There are a lot of ways to model this explicitly, but sometimes just having a clear document that expresses what these contexts are and what is involved in each is sufficient.

This also alludes to the benefits around separating your functions from your data. If your domain model is just data and the functions live elsewhere (i.e. within a separate abstraction representing each bounded context), then you have tremendous amounts of flexibility with how the system is composed on top of the model.

Re: Behaviours to avoid in a software architecture role

#85

Post by nitrogen »

dominotw wrote: post #39
nitrogen wrote: post #37

Earlier quoted context omitted.

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? I…

Is your assumption that ppl that aren't principals don't consider pitfalls.

No such assumption on my part. But it might be safe to assume that the better you are at questioning assumptions, avoiding pitfalls, and thinking of the big picture (think breadth-first vs depth-first traversal of the problem space), the more likely you are to advance to higher levels of responsibility.

Another example. Suppose you are adding a new field to your payment processing system. You have considered engineering pitfalls. How will that change affect other teams? What about other departments? Will Accounts Receivable suddenly have a 10x workload of invoices to chase because that field change wasn't considered in their workflow in all cases?

There's nothing magical about what senior vs staff vs principal vs whatever engineers do, it's the same skills amplified and applied to the benefit of many people across an org, rather than limited in scope and awareness to a single project.

Re: Behaviours to avoid in a software architecture role

#86

Post by nelsondev »

zug_zug wrote: post #83

>> 4. Don’t just seek architectural consistency I don't know what the author has in mind, but I plainly disagree when stated as a general rule like this. Examples: Try to get every server on the same OS by default, same packages, standardized networks, health check at the same path, prefer the same port, deployed with standard jenkins jobs, use a standard versioning scheme, use the standard branching model, standardi…

That’s “Dev Ops” consistency, not architectural consistency.

Insisting on architectural consistency might mean every service needs to use a relational database, and have an exposed API. But a pub/sub or map reduce, may not fit neatly into that architectural model.

Re: Behaviours to avoid in a software architecture role

#87

Post by AnimalMuppet »

bluefirebrand wrote: post #36
pc86 wrote: post #33

Earlier quoted context omitted.

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.

In pc86's scenario, though, it's much more likely that you're the one with the ego, thinking that reading a few blog posts makes you more informed than a 20-year industry vet.

Re: Behaviours to avoid in a software architecture role

#88

Post by commandlinefan »

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.

> trying to figure whether I need "Elastic Beanball3"

Just wait until you have to try to figure out how much that's going to cost you...

Re: Behaviours to avoid in a software architecture role

#89

Post by ClumsyPilot »

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…

Just one question - 'elastic beanstalk' - who the fuck came up with that name?

Re: Behaviours to avoid in a software architecture role

#90

Post by [deleted] »

jayceedenton wrote: post #68
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…

It's typical of engineering organisations to come up with this kind of list, the main reason being that as an industry we're uncomfortable with experience, seniority and progression. We're collectively suspicious of it. We want to codify and clarify it, endlessly. We demand the right to define it but when given the chance we always set the bar unrealistically high. To recognise someone as a Principal Engineer, they s…

[deleted]
Post reply on HN