Behaviours to avoid in a software architecture role

. Developers that are mature but lack proficiency because they don't care about software development

. Inexperienced developers that lack, well, experience to make proper designs

. Absence of domain specific knowledge when company tries to shift it's technological gears or switch to new domain/market all together

. Problems in communication and planning between dozens of teams/services that build together 1 product that must work in unison perfectly, yet it's hard for each team to know architecture/plans of all of the other teams and properly consider it during development

. Absence of ability to see "the big picture" by individual teams and take it properly into consideration

. Just a general jack of all trades that will compensate for bad product/project/program management, will establish proper processes, etc.

As part of this you occasionally can revamp organizational structure and leave company in much better shape, but it requires a lot of work that you, as architect have no authority to do :)

> And furthermore, as a developer, those organizations are no fun to be in and you can't pay me enough to want to deal with them

One of my last jobs was in company that I literally sweared to never work for. They gave me a shiny title, 50% raise of already top salary in industry that I had, yet what really sealed the deal was manager who wanted to try to do something new. Even though it was at times horror show, at the end of the day it was probably most fulfilling position that I had due to a sheer volume of things that I managed to change. And we also delivered totally new product, first in industry beating all the competition to market, including companies that were supposed to be market leaders in this area.

>Which adds to the problem. When good developers choose not to be in your company because your company is a disaster for developers, you don't get good developers.

The issue is that really good developers are rare. Developers that you can delegate to them and sleep well at night are a rare commodity on the market. I been working in dev for 25 years, both in startups and in established companies and I maybe know only dozen of people like this. Unfortunately, most of the developers on the market are in it only for money and don't really care about what they are doing.

Also, as anecdote, at this ^ job place that I described, in order to work around bad reputation of the company I suggested to create daughter company with a different name that will be operated independently in a different location in order to try to get better developers. We were a few steps away from closing on office lease before management bailed out because they were afraid that it will upset employees of the company

It was not way before microservices at Google. But it was before there was much general knowledge about them.

Sadly the internal lessons learned by Google have not seeped into the outside world. Here are examples.

1. What I just said about how to make requests traceable through the whole system without excess load.

2. Every service should keep statistics and respond at a standard URL. Build a monitoring system which has scrapes of that operational data as a major input.

3. Your alerting system should supports rules like, "Don't fire alert X if alert Y is already firing." That is, if you're failing to save data, don't bother waking up the SRE for every service that is failing because you have a backend data problem. Send them an email for the morning, but don't page people who can't do anything useful anyways.

4. Every service stood up in multiple data centers with transparent failover. At Google the rule was n+2/n+1. Meaning that your service had to globally be in at least 2 more data centers than it needed for normal load, and in every region it had to be in at least one extra data center. With the result that if any data center goes out, no service should be interrupted, and if any 2 data centers go out the only externally visible consequence should be that requests might get slow.

Now compare that to what people usually do with Docker and Kubernetes. I just have to shake my head. They're buzzword compliant but are failing to do any of what they need to do make a distributed system operationally tractable. And then people wonder why their "scalable system" regularly falls over and nobody can fix it.

Here's the concept of conditional expressions explained via a mathematical text: https://math.libretexts.org/Bookshelves/Mathematical_Logic_a....