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

61–70 of 174 posts

Re: Behaviours to avoid in a software architecture role

#61

Post by Geminidog »

taeric wrote: post #55
Geminidog wrote: post #45

Earlier quoted context omitted.

But you can. The separation is critical to the entire computing industry. The entire reason why higher level programming languages exist is to separate the form (assembly) from function. Usually there are "costs" to doing this and much engineering work is done to reduce this cost as much as possible. Either way, what you say is categorically wrong. Separating form and function is not a "mistake" given that it is so f…

Ah, but I would argue those are better described as form and function being part of the designs. Done wholistic, it is why the new apple hardware is able to take some very impressive gains. You can argue that some interfaces are separate products from the services. I agree with that. But each has its design and each is targeted on form and function to something. That is, you don't separate them. You make a new produc…

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 a higher level language that can be compiled into separate architectures then the move to ARM would be an even more complex engineering maneuver. The entire reason why Apple was able to move to new hardware without completely rewriting the software is because Form and Function are separated.

Re: Behaviours to avoid in a software architecture role

#62

Post by treis »

hellohello1 wrote: post #47
swirepe wrote: post #16

Earlier quoted context omitted.

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

Nah sounds like a seasoned architect. The first thing I had to unlearn was that I had any say over my architecture. Maybe the problem with software architects is that they only exist in bureaucratically hellish companies, and exist as a scapegoat for bad management decisions? Or maybe I'm just jaded.

Your experience matches mine. I can think of twice where I stood my ground and argued with a more senior person. Both times I was shown to be right technically but that came at a big cost to my career. I would have been much better off letting the project crash and burn.

I think there are senior people that are different. Hell, there might be companies full of them. But I'd need to see first hand proof of it before doing anything harder than gentle pushback.

Re: Behaviours to avoid in a software architecture role

#63

Post by hinkley »

sharadov wrote: post #54
christiansakai wrote: post #46

Earlier quoted context omitted.

with the housing cost I think it is impossible to do FIRE even with SWE salary.

You can, just don't FIRE in a western country.

I would say that something you need to know about yourself by the time you reach your FIRE goals is what you want to do with the extra 10 hours a day once it's not working for a boss. Even if that means adding a couple years onto your plan.

Because if you know the answer to that question, many of those answers don't require a tier 1 market. And since you're doing it late in life, it might occur to you that if you move to the mecca of beer making or kayak building, you'll be competing with people who are way, way more experienced than you are. Maybe you want to live in a 'rising star' city of a 200-600 thousand people, where your relationship with the community can be more reciprocal, but you can still find a decent turkish coffee and bulgogi tacos. That place is going to be tons cheaper than where you are now.

Re: Behaviours to avoid in a software architecture role

#64

Post by Person5478 »

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…

My experience is that people rationalize what they want. If they want microservices then you're going to get microservices.

It's not all nefarious, I think if many of them truly _UNDERSTOOD_ the difficulties of microservices it would give them pause (there's a difference between knowing and understanding), but they want what they want, they're optimistic, and they tend to back into the reasoning afterwards.

Re: Behaviours to avoid in a software architecture role

#65

Post by perlgeek »

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…

I've seen many engineers reach for a microservice architecture by default.

Why? Because they read HN, reddit and lots of blog posts, and thought that's how you do things now if you start from scratch, no legacy architecture to consider.

Not everyone thinks this way, but it's a frighteningly common thing.

Re: Behaviours to avoid in a software architecture role

#66

Post by perlgeek »

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.

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

Re: Behaviours to avoid in a software architecture role

#67

Post by Geminidog »

otabdeveloper4 wrote: post #30
Geminidog wrote: post #21

Earlier quoted context omitted.

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.

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 because neither person can see the future. It's like pointing at everything wrong with a piece of technology and saying an "Architect" could've fixed that in hindsight.

"Architects" are not the solution to technical design and technical debt.

An engineering manager can place all engineers in a room and ask them to come up with an "architecture" that is the same if not better than anything a single "Architect" can come up with, and this "Architecture" will never solve the problem of technical debt for the same reason why we can't predict stock prices.

Re: Behaviours to avoid in a software architecture role

#68

Post by jayceedenton »

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 should be definitively and objectively exceptional in every way, right? Their depth of knowledge in all technical areas is unmatched, they deliver innovation, domain knowledge, expert teaching and mentoring, strategic vision. They're growth hackers and also they design and deliver timeless systems and ever-green architectures. They're research scientists, and also inspiring leaders who (with no formal seniority) are able to align large groups of engineers via respect alone. How else can they be deserving? I wonder, does any other discipline in the org require this?

Whenever we come close to settling on a sensible way of recognising the value that experienced engineers (that are well connected to the domain and the business) can bring, it takes only a few years before that route is smashed by a new iconoclastic bunch of thought-leaders.

The parts of the org that are outside engineering now just let us get on with sabotaging ourselves.

Re: Behaviours to avoid in a software architecture role

#69

Post by Geminidog »

perlgeek wrote: post #66
Geminidog wrote: post #21

Earlier quoted context omitted.

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.

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 god, gemstone, animal or molecular structure.

Re: Behaviours to avoid in a software architecture role

#70

Post by taeric »

Geminidog wrote: post #61
taeric wrote: post #55

Earlier quoted context omitted.

Ah, but I would argue those are better described as form and function being part of the designs. Done wholistic, it is why the new apple hardware is able to take some very impressive gains. You can argue that some interfaces are separate products from the services. I agree with that. But each has its design and each is targeted on form and function to something. That is, you don't separate them. You make a new produc…

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 layered. I agree with that, with each layer having is own forms for its functions.

Applied to the example here. I am not saying they are identical. I'm saying that they are best considered together. Such that our industry typically passes the buck on UI and UX, to the detriment of everything.

Post reply on HN