[HN Gopher] Behaviours to avoid in a software architecture role
___________________________________________________________________
Behaviours to avoid in a software architecture role
Author : geidies
Score : 126 points
Date : 2021-02-02 16:00 UTC (6 hours ago)
(HTM) web link (www.danielwatts.info)
(TXT) w3m dump (www.danielwatts.info)
| sjg007 wrote:
| 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 create a lot
| of documentation and train new developers and stakeholders. So
| it's really a job where you spend 95% of your time
| contextualizing, writing and communicating to others. It's a bit
| like doing continuous self reflection of a project.
|
| It's kind of a thankless job, do your job well and it's like
| flowing water and nobody notices you. Do it badly and things dam
| up quickly.
| rmah wrote:
| Back when I was starting out, what your describing was called
| an "systems analyst".
| Geminidog wrote:
| > 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.
| nitrogen wrote:
| I've had my worst experiences in teams where the Product and
| Engineering were completely siloed. Things go a lot more
| smoothly if there's a bit of overlap. Also, many orgs don't
| have a TPM role, so that falls on Staff/Principal engineers
| and engineering managers. In fact, roles _should_ be fluid
| and slightly overlapping, as every team and every org will
| have different needs.
| pc86 wrote:
| 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.
| bjornsing wrote:
| You only need one maxim for software architecture work:
| "Implementation ruins architecture!" :P
| hellohello1 wrote:
| Hey that's my portfolio! 100 products written by 100 people in
| 100 different ways. 100 people left and I'm the one left trying
| to unfuck 100 products.
| hertzrat wrote:
| 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.
| lovehavetodo wrote:
| Software architects is a critical role. Need someone with higher
| level knowledge of the system to make sure every decision makes
| sense.
| hinkley wrote:
| Software architecture is a critical responsibility.
|
| There is more than one way to get that taken care of, and it
| tends to work better when the people who are responsible still
| have their hands in the code.
|
| I've seen too many pure architects spout off about how the
| system works and not notice the meaningful glances among
| everyone else at the table. That's how _you_ wanted it to work.
| We couldn 't make that work (possibly because Information
| Theory or physics) so we did something else.
| christiansakai wrote:
| Is software architecture role the end game for SWEs?
| ed312 wrote:
| When I'm managing junior folks, I generally advise them there
| are three main paths: 1. Keep focusing on IC/software work. You
| keep growing and having larger impact, capping off with an
| architect type role. 2. Lean into project management, full
| stack, and business a bit. Become a tech lead for increasing
| large/important projects. This is a great general path that
| still lets you be pretty close to the code. 3. Focus on
| business & people. Gain experience mentoring teammates, then
| interns, then become a people manager. At some point you're
| going to be trading cutting edge coding skills for mid level
| management skills. You can branch off to focusing on CTO or
| engineering leadership from here.
|
| There are definitely a lot of other paths, but that above three
| are the most "well worn" and achievable in my experience.
| joncrane wrote:
| I think FIRE is the end game for SWEs.
| sharadov wrote:
| LOL! Can't second this enough!!
| christiansakai wrote:
| with the housing cost I think it is impossible to do FIRE
| even with SWE salary.
| sharadov wrote:
| You can, just don't FIRE in a western country.
| hinkley wrote:
| 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.
| hinkley wrote:
| This is not a rhetorical question:
|
| Do you still want to live close to SV when you're not
| working there anymore?
|
| Your burn-down rate for your retirement fund is predicated
| pretty substantially by the standard of living you maintain
| after you retire. If a lot of your day to day activities
| become indefensible once you can't justify it based on work
| concerns, then your costs may be lower.
|
| Look, for instance, at all the fancy cars that real estate
| agents have to drive to exude competence. They end up
| leasing a high end car, when maybe all they want is a 2013
| Subaru Outback for activities and half a closet of clothes
| from Duluth and Patagonia that last forever. Once you pull
| on that thread, then moving to an exurb might make sense
| too.
| cek wrote:
| 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
| implementations. Only by being close to the details can we earn
| the respect needed to be effective technical leaders.
|
| Technically Fearless - Our company's startup culture does not
| admit the luxury of conservatism. Principal Engineers tackle
| intrinsically hard problems, venturing beyond comfortable
| approaches when necessary. We acquire expertise as needed,
| pioneer new spaces, and inspire others as to what's possible.
|
| Balanced and Pragmatic - Principal Engineers are pragmatic
| problem solvers. We apply judgment and experience to balance
| trade-offs between competing interests. We simplify processes and
| technologies while advocating a long-term view.
|
| Illuminate and Clarify - Principal Engineers bring clarity to
| complexity and demonstrate smart ways to simplify. We frame each
| problem in its customer and business context and boil it down to
| its essence. We probe assumptions, illuminate pitfalls, and
| foster shared understanding. We accelerate progress by driving
| crisp and timely decisions.
|
| Flexible in Approach - Principal Engineers adapt our approach to
| meet the needs of the team, project, and product. We solicit
| differing views and are willing to change our minds as we learn
| more. We recognize there are often many viable solutions, and
| that sometimes the best solution is to solve a different problem,
| or to not solve the problem at all.
|
| Respect What Came Before - Principal Engineers are grateful to
| our predecessors. We appreciate the value of working systems and
| the lessons they embody. We understand that many problems are not
| essentially new.
|
| Learn, Educate, and Advocate - Principal Engineers are constantly
| learning. We seek technical knowledge and educate the entire
| organization about trends, technologies, and approaches. We
| combine vision and discretion to drive fruitful and even game-
| changing technology choices.
|
| Have Resounding Impact - "Deliver Results" is a low bar for a
| Principal Engineer. Without seeking the spotlight, Principal
| Engineers make a lasting impact that echoes through the
| technology, the product, and the company. We amplify our impact
| by aligning teams toward coherent architectural strategies.
| sjburt wrote:
| 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.
| commandlinefan wrote:
| > 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...
| Geminidog wrote:
| 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.
| perlgeek wrote:
| I would argue that naming very high-level things (like your
| top-level services) is very much an architectural decision.
| Geminidog wrote:
| 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.
| spookthesunset wrote:
| 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.
| Geminidog wrote:
| 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?
| BillinghamJ wrote:
| To be fair, most of AWS's services are also mere users of
| other AWS services
| Geminidog wrote:
| Naw. The term "mere" was to de-emphasize the importance
| of the term "architect" which doesn't apply to other AWS
| services.
|
| The parent poster declared that AWS needed some
| "architects" which I think is kind of arrogant given the
| fact that most "architects" don't even have the ability
| to engineer the tools built by AWS. They are just "mere"
| users of the tools.
| taeric wrote:
| Hard disagree. Thinking you can separate form from function
| is the evergreen mistake of our industry.
| Geminidog wrote:
| 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 fundamental to the entire industry.
| taeric wrote:
| 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 product,
| that has its own form and function.
| Geminidog wrote:
| 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.
| taeric wrote:
| 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.
| Geminidog wrote:
| 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.
| taeric wrote:
| 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.
| Geminidog wrote:
| >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."
| taeric wrote:
| 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.
| otabdeveloper4 wrote:
| 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.
| Geminidog wrote:
| 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.
| otabdeveloper4 wrote:
| 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.)
| Geminidog wrote:
| 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.
| jayceedenton wrote:
| 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.
| AmericanChopper wrote:
| I've worked in a few organisations that had that sort of
| role, and managed to fill them with people who suited it very
| well. They had a very high level of experience and expertise,
| were absolutely fantastic and mentoring, were incredibly
| approachable, were very much not dogmatic about things, and
| primarily devoted their time to helping other engineers
| design solution. What they weren't was infallible, all-
| knowing experts of every domain. When we didn't know how to
| do something, they'd help us test and validate ideas. When we
| got things wrong and failed (and by we I mean them too),
| they'd help us learn as much as we could from it.
|
| To the point, their job wasn't to be right all the time. It
| was just to help everybody get things right as often as
| reasonably possible.
| ClumsyPilot wrote:
| Just one question - 'elastic beanstalk' - who the fuck came up
| with that name?
| [deleted]
| Geminidog wrote:
| 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"?
| cek wrote:
| It really comes down to the tenets I posted above from
| Amazon. At MS there was a propensity for folks in these roles
| to just pontificate. We called them "Architecture
| Astronauts". As an example, they were rarely practitioners
| (they rarely wrote code).
| LgWoodenBadger wrote:
| For me, regarding the ones who don't actively code, it's
| something along the lines of "everything compiles on a
| whiteboard."
| zippergz wrote:
| 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.
| btilly wrote:
| 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.
| ClumsyPilot wrote:
| "make them write code in the interview... Because now they
| can't program"
|
| This comes across disrespectful and presumptious.
|
| Firstly, do you believe that if you have not coded for 4-5
| years you become useless just becauss you don't know the
| latest %fad% framework?
|
| Secondly, the whole phrasing just conveys disrespect for
| cadidate, where the only responce to 'jump' is 'how high'.
|
| If someone is interviewing for non-code postition they
| might tell you to take a hike.
|
| The idea that a contrived 30 minute coding session tells
| you more about a candidate that studying code they've
| previously written or debugging together is idiotic.
| humbleMouse wrote:
| 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.
| dominotw wrote:
| 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.
| shagie wrote:
| 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.
| nick_kline wrote:
| There was one key entry there, actually coding. Non-coding
| architects are rife with the possibility (but not certainty)
| of being too disconnected from the reality of the systems
| they are working on.
| nitrogen wrote:
| 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.
| dominotw wrote:
| > 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.
| Person5478 wrote:
| 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.
| perlgeek wrote:
| 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.
| majormajor wrote:
| > Everyone understands that there are tradeoffs and
| "pitfalls" associated with any decision.
|
| I haven't seen this to be true. Especially as companies
| get larger.
|
| Sometimes it's because they really believe option A is
| better in every dimension than option B. (But often are
| mistaken.)
|
| Sometimes it's because option A means their team has more
| work and can hire more people.
|
| Sometimes it's because they understand their own ideas
| really well but aren't understanding other people's
| arguments.
|
| Sometimes it's because they just don't respect the other
| people in the room.
|
| But assuming that everyone is going to rationally jump
| initially to the thing that's best for the long-term
| health of the organization isn't something I've been able
| to count on.
| nitrogen wrote:
| _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.
| [deleted]
| digitalsushi wrote:
| 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.
| AnHonestComment wrote:
| That's something Amazon does well:
|
| Principal engineers are expected to give talks about their
| experience, which are heavily attended in person and widely
| shared.
|
| It's not perfect, but it's less abstract when one or two
| concepts at a time, they explain why those truism through
| their personal experience.
|
| "Earn Trust" is a truism -- but being able to search for
| talks by the keyword "earn trust" where a high level
| engineer discusses different situations from their career
| and how they handled them is useful.
| bob1029 wrote:
| #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 where you run into massive
| problems on more complex systems.
|
| Taking this a little bit further, having a clean model of the
| problem domain also makes other downstream aspects easier.
| Business analysts can start expecting certain types to have
| certain properties and you can leverage things like SQL to
| dramatically speed up projection of business facts without
| involving developers.
| arethuza wrote:
| 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"?
| bob1029 wrote:
| 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.
| steve_adams_86 wrote:
| 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
| interface with correct code in its own way.
|
| I've set myself up for failure this way, essentially by
| assuming things would just fit into place as more of the
| project became clear. That's a really bad way to work, haha.
| But you learn as you go.
| TameAntelope wrote:
| 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.
| craftinator wrote:
| 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.
| offtop5 wrote:
| 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.
| swirepe wrote:
| >I'll add another one, don't openly confront the CTO.
|
| Looks like we found the CTO :)
| hellohello1 wrote:
| 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.
| treis wrote:
| 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.
| joncrane wrote:
| Nope, we found someone who, shortly before a low point in
| their career, openly confronted a CTO.
| NDizzle wrote:
| Even when they have indefensible positions? When the idea
| doesn't hold up to ~2 hours of research?
| coryrc wrote:
| the important word is "openly"
| TameAntelope wrote:
| 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.
| pc86 wrote:
| 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.
| bluefirebrand wrote:
| 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.
| AnimalMuppet wrote:
| 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.
| vmh1928 wrote:
| 2+2 = 5 situations.
| TameAntelope wrote:
| 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.
| offtop5 wrote:
| More like when you've been at the company for about 3 weeks
| NDizzle wrote:
| What about the inverse? The CTO is the new person in my
| situation.
| willvarfar wrote:
| And nothing about business needs and wants, working with
| stakeholders and all the rest? I've seen both newly minted and
| seasoned "architects" fail again and again because they think in
| terms of technology not business.
| theptip wrote:
| 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.
| willvarfar wrote:
| -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.
| mateo411 wrote:
| 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.
| theptip wrote:
| 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
| zug_zug wrote:
| >> 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.
| nelsondev wrote:
| 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.
___________________________________________________________________
(page generated 2021-02-02 23:00 UTC)