[azalex]

The essence of my job as an architect is commonly described as a 'professional negotiator', implying that my primary responsibility is convincing people into doing the right thing (tm). My time is typically split between two main things: meetings and research/design work.

On a typical day, I have 4-6 meetings with different groups of people. Some will be solution design discussions with engineering teams where we try to figure out how a particular challenge will be solved together. Others will be with product managers, talking about feasibility, cost and time estimation. Yet others will be with senior directors about long term strategy and infrastructure. Finally, a very important part of the meetings is mentoring. Knowing something is valuable, sharing that knowledge is invaluable.

While this may sound like a lot of meetings (and engineers typically abhor meetings) they are typically very useful and very rewarding.

The remaining time I typically spend on doing preliminary research, design, documentation and every now and then even coding, which I thoroughly enjoy.

[azangru]

> convincing people into doing the right thing (tm).

How do you deal with the burden of knowing/predicting what the right thing (tm) is / will turn out to be? I am constantly agonising over choices I'm about to make, and almost invariably come to regret some of the choices that I, or our team, have made (which include, but are not limited to, React, Gatsby, Flow, Stylus, Enzyme, Jest, SCSS, single-page app architecture, possibly graphql, etc. etc...). Not that I'm an architect; but still. How do you cope?

[azalex]

In my opinion, the fundamental difference between an architect and a staff/principal engineer is that architects are more generalists and principal engineers are more specialised. It does not mean, of course, that architects don't or can't have deep knowledge of specific areas or that principals can't have a wide understanding of their ecosystems, but an architect absolutely must understand the ecosystem they work in and a principal engineer absolutely must understand the specific technology stack of their choice. Understanding that every choice is a trade-off and comes at a price, that someone at some point will have to pay.

You chose the latest and greatest web framework? Great! How many developers at your company will know how to use it? How long will it take for them to learn it? How big is the talent pool you can hire from? How much time will it take to migrate your products to it? Who will support it, is it "wild west" open-source or does it come with commercial support? How does it fit with your deployment model? Has it gone through rigorous threat modelling? There are about a billion factors that may affect your choices and finding the right solution will always be a central part of the problem.

To actually answer your question about how I deal with this, this is why I do research. Let's say our product people come up with a brilliant new product idea that we don't have an existing solution for, then I'll spend some time on finding information about the available options and take notes on the benefits and drawbacks. I will try to find people who are experts in the subject and get their opinions.

What I can not do, is to actually go and gain a deep understanding of every single language/platform/framework/library there is, I'm just a human after all.

[jvalencia]

It's probably a good thing if you're not too expert. If you were deep into it, you might be impressed by the choices, but miss the glaring red flags: e.g. The git repo for this cool API has no adoption, no stars, no commits in the last 6 months, etc.

[atom_arranger]

  - Keep your code reasonably clean
  - Use strong typing
  - Make sure your tests don't test implementation details if possible
    - e.g. using more integration like tests written with react-testing-library
    - e.g. using visual regression tests
  - If you sense something is off about the tech stack make a POC of partially migrating to something else as soon as possible
  - If the thing you tried is better come up with a plan to migrate and do it as soon as possible
  - If you've followed all the bullet points above then switching to a better solution shouldn't be that difficult

That's how I try to deal with it. Also if you're not sure which thing is better do POCs with both solutions. Alternatively if you're working on a greenfield project and a week in things don't feel right don't be afraid to try rewriting it with one of the alternatives you were considering, it'll be a slight hit to productivity for a day or two but it'll pay off long term.

By following these guidelines I've never felt on a project that I've painted myself into a corner with the tech stack, or chosen something very bad that is not reversible.

[mickeyp]

That ecosystem moves very fast and... reinvents itself all the time.

Here's another way of looking at that problem:

How many of those tools and technologies existed 1, 3, 5, 10 years ago?

Would you trust a six month-old tool on github to form the nucleus of your -- probably mundane, in the good way! -- project? Would you risk it all for the chance to have a slightly different way of rendering CSS or generating HTML?

... I didn't think so. React's been around for a long time now and it's got a lot of momentum and people who know it. So that's a pretty safe bet. Rinse and repeat.

Not all tools are critical and you do have some leeway. But when in doubt, pick something you can easily hire people to help you accomplish; that has been around a while; and that feels established.

[azangru]

> React's been around for a long time now and it's got a lot of momentum and people who know it.

That was true for jQuery as well; and yet, it is clearly no longer the right thing (tm) to choose for a project. Not because it's no longer cool; but because the underlying technology — the web browser — has gotten so much better it is no longer relevant.

Same fate may await React. At least, with jQuery it's pretty straightforward to gradually wean oneself off of it. I don't know how firmly we are going to be stuck with React when its time comes.

[thrashh]

It wasn’t a change in web browser tech

It was that someone put in the time to write a JS preprocessor that went along with their framework. That was React’s novel addition

Without a preprocessor, users of your framework either use plain JS to generate HTML (i.e. jQuery) or you use templates.

Both of them always looked really ugly on frontend

With React’s JSX preprocessor, you can write HTML by… writing HTML. And you can mix custom components without doing some weird and ugly syntax

Does React use a shadow DOM? Yes, but so could have jQuery or Handlebars.js too, and it wouldn’t have mattered. People don’t care how it works as long as it works. As far as libraries go, what gets adopted is what looks and feels the nicest — as it should be

[azangru]

> Does React use a shadow DOM? Yes

No. You must be confusing it with virtual DOM.

As for React, what we are currently observing is that 1) it's a fairly large library in itself (~50kB of minified gzipped javascript); 2) it has a relatively slow DOM update mechanism; 3) it rerenders too eagerly, making it too easy to further degrade performance; 4) it's a lock-in into a non-standard jsx syntax, forever tying you to preprocessors.

What conclusions an architect would make looking at all this, I do not know.

[Too]

Jquery got squashed from two directions. One being react and other data binding frameworks, the other side being browser tech modernizing and aligning, such that bare js could be used, without a thick compatibility layer in between.

[bcrosby95]

jQuery has existed for a long time, still gets updates, is still used in greenfield projects, and has a large body of expertise around it.

The concern is abandoned projects that no one knows how to use, not that something is a bit old. React is beyond that point. It's not just the tech junkies hopping from the latest fad using it. There's been enough widespread adoption that there will still be React projects in 20 years.

[ARandomerDude]

Nevertheless the point is the same. Some technologies are more stable and broadly adopted than others. A slice of the total risk management pie entails selecting a tech stack that is less likely to die soon than its competitors.

[jupp0r]

A great mentor once told me about the poker analogy method of coping with situations you describe.

Let's say you are a great poker player. When you get dealt a good hand, you play it and end up loosing - does that make you a worse player?

Turns out even the best of all players loose quite frequently. What distinguishes them from others is that they make the best choices with the limited information they have at the time. They later go back and learn from any mistakes they have made and move forward.

[anon7725]

I ran into an interesting point about poker in a recent episode of EconTalk[0]. Really good players play slightly more hands than they should (ie on a tournament table with 9 seats, a good player might play 15-20% of hands). Amateurs play way more hands than they should - like 50% or so. Translating to this thread, I’d map “playing a hand” to committing real resources to a project (switching tech stacks, etc). Pros will be somewhat conservative and only take that bet when they have a higher expectation of success.

[0] https://www.econtalk.org/annie-duke-on-the-power-of-quitting...

[ElevenLathe]

In other words, you gotta know when to hold 'em, know when to fold 'em, know when to walk away, and when to run.

[AlchemistCamp]

She also mentioned how sick she was of hearing that song played when she took to the stage at various events and how Poker Face was a welcome change :)

[comprev]

Similar to management roles in the armed forces - those on the ground have to make split second decisions based on the latest information they have to hand. Getting it wrong usually has fatal consequences and it takes a certain personality trait to continue making those decisions.

[e12e]

Many good responses here already - but I'd say that eg choosing between react and vue or svelte isn't an architectural decision. But choosing between server rendered php and react is (is this a series of web "pages" with some forms, or is it an "app"?).

Choosing between mysql, sqlite and postgresql may be (do we need row level security? Would mysql multimaster benefit us? Do we expect to deploy many, small instances where the simplicity of sqlite will shine) etc.

There are many decisions to make building a solution - the architecture part has to do with fulfilling the requirements.

The tech-lead/senior developer/team lead part has to do with implenting the architecture - our team knows vue, so we go with that to implement the app. We're invested in ms sql so we prefer that to postgres - but sqlite would be a poor fit.

[gautamdivgi]

My personal take is I would go a level higher and define data consistency and availability requirements. Provide them to dev teams and if the teams need help meeting them I provide recommendations.

I generally try to keep design out of architecture. It’s what you need to satisfy product or service needs. The technology gets into how you want to implement. I try to leave that to the tech lead for the team.

[jononor]

Realize that a perfect solution is not feasible (it does not exist). Not even an optimal solution for your particular problem is feasible (too many unknowns about both the problem and potential solutions, impossible to uncover and analyze them before hand).

Realize that if you had chosen another solution, you would have other issues. Not "no issues". Probably not even "fewer issues" or "less severe" issues - just as high a chance

Realize that most technology choices actually have very little impact on the business. If one uses A or B, it does not matter much to do whatever it is your company does. Very few tech choices have the potential to kill the company/unit/product.

Realize that once a choice has been made, worrying about it does not help anyone.

So the goals are not perfection. Not anywhere close. Just something that:

1) lets us move forward now (avoid decision paralysis)

2) not worse than before (if so, just stick with what you got)

3) good _enough_ to deliver the needed business value

4) does not paint ourselves into a corner. Then we can always fix and improve things later

[just_a_username]

almost invariably come to regret some of the choices that I, or our team, have made (which include, but are not limited to, React, Gatsby, Flow, Stylus, Enzyme, Jest, SCSS, single-page app architecture, possibly graphql, etc. etc...)

I have invested in some of these technologies. The biggest commonality is that they ALL have their faults and weaknesses. The key is ensuring everyone makes best use of whatever framework/package/tooling that you have invested in via a set of best practices and standardised processes. Over the last 20+ years, i've found you should only switch to something else if there are significant gains to be had. Otherwise it rarely offers more value.

[0xbadcafebee]

> I am constantly agonising over choices I'm about to make

You cannot predict the future. It is impossible know which choice will result in better outcomes. Whatever you choose has probably about equal chance of success or failure. So just make a choice, with a general idea of what you will do when the choice fails. Most choices are not make-or-break, so you should really not be agonizing over most choices.

[ycombobreaker]

> It is impossible know which choice will result in better outcomes. Whatever you choose has probably about equal chance of success or failure.

It's a common fallacy to assign 50/50 probability to unknown distributions. Furthermore, many choices are not binary, or may not be as simple as right/wrong in hindsight.

But I agree with the idea of amortizing your perspective over many choices.

[mathewvp]

Can you comment on why you regret about choosing React and graphql? I'm asking because my Director is kind of pushing us to move from current server side rendered stack to react or some other js framework with graphql just because everyone is using it.

[gardenhedge]

How do you personally deal with designing solutions where you haven't been able to convince people to do the right thing? For example where there are limitations imposed on you or someone higher up makes a call that doesn't sit well with you

[azalex]

It does happen, quite often, to be honest. The single most important thing in this case is to understand why it happened. A typical example is when we come up with a design proposal that I think is a good one, but turns out to be that the estimated cost of building and running it outweighs the projected revenue the product will generate. Another example would be when I want to have a particular design implemented by an engineering team but they don't have enough capacity (people, time, etc) to deliver it the way it was intended. There have been cases when it was all about politics (sadly, I must add, but it does happen), i.e. someone in higher places of power want to push their own agenda and you get overruled.

These are cases when the previously mentioned 'professional negotiator' role gets really important. These are the cases when you need to go to the people involved and try to understand their priorities and their constraints. Once you have the information necessary, most of the times you'll be able to come up with an alternative solution that is acceptable for everyone. Sometimes you can convince others to give way, sometimes you'll need to.

And then there are times when you just can't do anything because, for example, you get overruled by an overzealous CTO. In these cases, as sho_hn also pointed out, the best you can do is to make them understand the implications and brace yourself for damage control, because the fallout is going to be on you anyway :)

[sho_hn]

Make sure you negotiate the responsibilities of your role so that you can say "I'm not able to sign off on this". You may get overridden anyway, but the consequences must be known. And if you got people to agree that you should be able to say this, they usually understand the gravity of you having to invoke it and will live by it.

[stronglikedan]

CYA. Send an email to the higher up stating the negative impact that their decision will impose, and ask them to confirm that they would still like to proceed. Then don't do anything related to that decision until they respond.

[weard_beard]

Same. This is a great depiction of a healthy practice.

[rcarmo]

This. This is the “right” answer.