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

71–80 of 174 posts

Re: Behaviours to avoid in a software architecture role

#71

Post by zippergz »

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, not be fully empowered and expected to make these decisions. And no matter how experienced and smart the architects are, if they aren't working hands-on with the systems and code on a regular basis, they can't make the best decisions. Software architecture as a separate job from software engineer is bad for everyone involved.

Re: Behaviours to avoid in a software architecture role

#72

Post by spookthesunset »

Geminidog wrote: post #69
perlgeek wrote: post #66

Earlier quoted context omitted.

I would argue that naming very high-level things (like your top-level services) is very much an architectural decision.

Agreed. Only Software Architects have the special ability of naming things. Engineers and managers don't have this special knowledge. When I went to Standford to get my PhD is Software Architecture I was required to take at least 2 semesters of classes on the theory of naming things in software. The biggest point the class made was proving mathematically how one should never name anything after a plant, Greek/Roman g…

I hate with a passion services that have cute clever names. It makes it impossible guess what they do. It makes it easy to overload the service with things that don’t belong.... if the service was named “OrderService”, if somebody wanted to add a “spell check” endpoint people would start asking questions if that service was the right place. But since the service was named “CaptainCrunch”, who knows if spell check belongs...

Same goes for team names too... clever team names are obfuscation.

Re: Behaviours to avoid in a software architecture role

#73

Post by Geminidog »

taeric wrote: post #70
Geminidog wrote: post #61

Earlier quoted context omitted.

My remark is based on what you said. You called the separation of form and function a "mistake" and I said this is categorically wrong. My statement still stands, you have not addressed it. I neither agree or disagree with your remark about "Wholistic" designs but your example is extremely inapt. The entire MacOS is programmed using a an interface separate from function. If they didn't program the Operating system in…

My address of it is that things don't separate to distinct things, often. They, instead, made new forms that have their functions. Or vice versa, if you want. This is true for content as much as services. In simplistic cases, you can point at something and say "there is the content." Often, though, you cannot. The distinction between the two is a huge blur. You are bringing up, essentially, that abstractions can be l…

No. I am bringing up the fact that form and function are always separated in our industry and that this is fundamental to the entire industry making your initial statement categorically wrong.

It's obvious that abstractions have costs and it's obvious that sometimes things are designed holistically. But these obvious things are off topic. The point here is that your initial statement is completely and utterly wrong wrong wrong.

Please stay on topic. Are you still claiming your initial statement is right? or are you now claiming it's wrong? Don't change the topic into the industry "passing the buck to UI and UX" this is not your initial statement.

Re: Behaviours to avoid in a software architecture role

#74

Post by Geminidog »

spookthesunset wrote: post #72
Geminidog wrote: post #69

Earlier quoted context omitted.

Agreed. Only Software Architects have the special ability of naming things. Engineers and managers don't have this special knowledge. When I went to Standford to get my PhD is Software Architecture I was required to take at least 2 semesters of classes on the theory of naming things in software. The biggest point the class made was proving mathematically how one should never name anything after a plant, Greek/Roman g…

I hate with a passion services that have cute clever names. It makes it impossible guess what they do. It makes it easy to overload the service with things that don’t belong.... if the service was named “OrderService”, if somebody wanted to add a “spell check” endpoint people would start asking questions if that service was the right place. But since the service was named “CaptainCrunch”, who knows if spell check bel…

Agreed, the post you replied to had a sort of different point though. I took two semesters of naming things as part of my PhD in software architecture. Do you know anyone with such a PhD? Do you know of any course in any university that teaches people how to name stuff? Did you need to take such courses to arrive at your philosophy on naming things?

Re: Behaviours to avoid in a software architecture role

#75

Post by rmah »

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…

Back when I was starting out, what your describing was called an "systems analyst".

Re: Behaviours to avoid in a software architecture role

#76

Post by taeric »

Geminidog wrote: post #73
taeric wrote: post #70

Earlier quoted context omitted.

My address of it is that things don't separate to distinct things, often. They, instead, made new forms that have their functions. Or vice versa, if you want. This is true for content as much as services. In simplistic cases, you can point at something and say "there is the content." Often, though, you cannot. The distinction between the two is a huge blur. You are bringing up, essentially, that abstractions can be l…

No. I am bringing up the fact that form and function are always separated in our industry and that this is fundamental to the entire industry making your initial statement categorically wrong. It's obvious that abstractions have costs and it's obvious that sometimes things are designed holistically. But these obvious things are off topic. The point here is that your initial statement is completely and utterly wrong w…

My opening statement is short, so I'm assuming some charity in reading it. My complaint is the idea that you can make a hard distinction between function and pass that to another layer is a huge mistake in our industry. As noted by us conversing in a web browser. :)

Are they separate things? I mean, yeah. But they interplay with each other such that near every attempt to force them apart is full of ugly edge cases such that I assert we would benefit from people seeing that form and function typically work together in building things that work.

Re: Behaviours to avoid in a software architecture role

#77

Post by otabdeveloper4 »

Geminidog wrote: post #67
otabdeveloper4 wrote: post #30

Earlier quoted context omitted.

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.

The disparity within AWS is the result of common inevitability that arises with managing technology built on over a decade of scaffolding. For sure there is a central planner within the company trying his best to put everything together into a cohesive whole. Technical debt is the most common name for this issue. An "Architect" can't solve this problem anymore than an "Engineer" can fix the problem of technical debt…

Technical debt isn't the root or even the most common cause of software components not playing nice with each other.

In fact, this problem is probably more prevalent in greenfield over-engineered solutions than old legacy-ridden ones.

(And really much of what we call "technical debt" is just the scaffolding we put together over the years to make stuff be compatible.)

Re: Behaviours to avoid in a software architecture role

#78

Post by Geminidog »

taeric wrote: post #76
Geminidog wrote: post #73

Earlier quoted context omitted.

No. I am bringing up the fact that form and function are always separated in our industry and that this is fundamental to the entire industry making your initial statement categorically wrong. It's obvious that abstractions have costs and it's obvious that sometimes things are designed holistically. But these obvious things are off topic. The point here is that your initial statement is completely and utterly wrong w…

My opening statement is short, so I'm assuming some charity in reading it. My complaint is the idea that you can make a hard distinction between function and pass that to another layer is a huge mistake in our industry. As noted by us conversing in a web browser. :) Are they separate things? I mean, yeah. But they interplay with each other such that near every attempt to force them apart is full of ugly edge cases su…

>My opening statement is short, so I'm assuming some charity in reading it. My complaint is the idea that you can make a hard distinction between function and pass that to another layer is a huge mistake in our industry. As noted by us conversing in a web browser. :)

Ok, so you are basically implying that your opening statement is wrong and what you meant to say is that abstractions do not have zero costs and that the industry is unaware of this. Just admit you're wrong instead of relying on the political stratagems used by "architects" to stay relevant.

I would argue that everyone is fully aware of this concept. It's a necessary evil done to reduce complexity otherwise we would all be programming in assembly language. As for AWS specifically, isn't it proof of what you say? The technical details are leaking into the interface showing that function and form can't be fully separated.

If you're saying the architecture of AWS should have been holistically designed to support a more intuitive interface, I would say you're describing another problem all together. A holistic design is a synonym for "waterfall," and there's a good reason why it's avoided in the industry.

The problem with waterfall is that the current needs of the market is always a moving target. No architect or even UI/UX designer can predict the needs of the market in the future thus things are continuously put together agile style (aka ad hoc). This produces technical debt which is something neither Architect nor the UX/UI designer can solve. AWS definitely suffers from some debt and the UI reflects this, but again, this is NOT because they lack "architects" as every company has this problem whether or not the company has "architects."

Re: Behaviours to avoid in a software architecture role

#79

Post by taeric »

Geminidog wrote: post #78
taeric wrote: post #76

Earlier quoted context omitted.

My opening statement is short, so I'm assuming some charity in reading it. My complaint is the idea that you can make a hard distinction between function and pass that to another layer is a huge mistake in our industry. As noted by us conversing in a web browser. :) Are they separate things? I mean, yeah. But they interplay with each other such that near every attempt to force them apart is full of ugly edge cases su…

>My opening statement is short, so I'm assuming some charity in reading it. My complaint is the idea that you can make a hard distinction between function and pass that to another layer is a huge mistake in our industry. As noted by us conversing in a web browser. :) Ok, so you are basically implying that your opening statement is wrong and what you meant to say is that abstractions do not have zero costs and that th…

With my statement following the claim that UI/UX is not an architectural issue, I'm not sure how you are getting this reading.

I maintain that separating the ui/ux from the architecture is a fools' errand. Any other reading of my statements, while almost certainly my fault, don't make sense here.

Re: Behaviours to avoid in a software architecture role

#80

Post by Geminidog »

otabdeveloper4 wrote: post #77
Geminidog wrote: post #67

Earlier quoted context omitted.

The disparity within AWS is the result of common inevitability that arises with managing technology built on over a decade of scaffolding. For sure there is a central planner within the company trying his best to put everything together into a cohesive whole. Technical debt is the most common name for this issue. An "Architect" can't solve this problem anymore than an "Engineer" can fix the problem of technical debt…

Technical debt isn't the root or even the most common cause of software components not playing nice with each other. In fact, this problem is probably more prevalent in greenfield over-engineered solutions than old legacy-ridden ones. (And really much of what we call "technical debt" is just the scaffolding we put together over the years to make stuff be compatible.)

I think if you ask, most anecdotal evidence from people who have worked with architects shows that companies with "software architects" don't necessarily have less "technical debt" then companies without.

Theoretically, those "software architects" would put a stop to "over-engineered" solutions, but why do these companies still have technical debt?

Most likely because technical debt is not solely just "over engineered" solutions.

Post reply on HN