9 ms·

The Myth of Architect as Chess Master

73 points by yarapavan 7y ago

loopz 7y ago
Architects have two primary purposes (not roles): 1) Facilitate that architecture and design happens in teams (dev or not) 2) Ensure coherency of architecture That's it folks!
- tyingq 7y ago
  That seems right. City planner seems more apt than chess master.
  - jaggederest 7y ago
    I used to joke that the term "business-to-engineering psychologist" was more descriptive than "software architect". You had to know how to get people to agree a lot more than how to get technology to work together, especially in "larger organizations". It's politics, pure and simple - most of the conflict isn't technical.
    - mehh 7y ago
      damn right!
- dehrmann 7y ago
  Most places I've worked use the architect title to retain people.
- pjmlp 7y ago
  In many companies architects is just a synonym for a project manager that happens to also grok UML.
rehasu 7y ago
And then you go another level deeper and see everything is actually just different ways of doing the same old Linux and/or Java. I feel especially in Ops people can see that all the time. For instance just today I saw someone debug a NO_PROXY topic in Kubernetes. Kubernetes is super cool and works different than the old LAMP stacks or even Openstack. But still they deal with NO_PROXY not being standardized problems. Also shows that the same, actually hard problems (like standardizing something that is "out there" for more than a decade already) are never really solved. Each shiny new tool comes with its own way of doing things, but what they do with your input is in the end always the same. Mounting, multiprocessing, sockets, string parsing, memory management, log searching, etc. So yes, I think there's a way to become a chess master. You just need to go one level deeper and accept that there might be multiple topics that each will need half a decade to learn good enough to be useful.
cmhnn 7y ago
If the argument the blog is trying to make is Architects can't know everything then it's a bad article to submit. On the other hand, if the argument is a boss should not expect someone called Architect or senior engineer etc. to be able to troubleshoot based on experience I have a problem with that. If someone can't be air dropped and they have a title that is intended by the business as code for a senior level software person who can think of how to build systems and can also build them themselves, then I am not sure what they bring to the table.
- loopz 7y ago
  This is the problem with development for, forever. Most of the time, people are tasked with: Here's the spec/user story/loose idea/unrealistic wishlist, and can you be done before this weekend at least? What's the problem again? The facilitation of foundational discussions and exploration is seen as waste. So the business spends X months building the wrong idea, without any feedback and adjustments along the way whatsoever instead. To air-drop someone senior to set things straight. What a great way to sabotage organisational learning and simplification. Not that anybody gives a rats ass about eachother anyways, right?
  - cmhnn 7y ago
    There are a lot of problems in the industry but the experienced helping the inexperienced on demand in response to a crisis doesn't seem like one that is nearly as serious as others. I am old enough to have been on XP teams and to have become a certified scrum master in its first few years. It's gotten out of hand. Being agile and blasting to an MVP is fine for people who think Netflix or sending dick picks is mission critical but with IOT and AI scenarios emerging that allow all the little software napoleans to fuck up something serious or inadvertently create a universal spying machine it might be time to put the breaks on for at least a class of problems. No industry hates old people as much as tech and that industry has people all over it like an idiot on another thread who clearly had no idea who Brian Kernighan was when they wrote their post. Young programmers have always been arrogant idiots. I was one myself. But it astounds me that many programmers today don't even know a ton of stuff that would make their job easier since it is shit that is already figured out or is shit the science says can't be figured out. I hate people that wallow in history as much as the next person with an ounce of inclination to independent thought but for fucks sake learn some basics before applying that code golf to 20,000 cores because that shit costs money you free food demanding little jack ass. As for building what the customers need or want? The more time I spend around programmers the less inclined I am to want them deciding anything for anyone in terms of features. If you're blessed enough to be great at programming and picking things people actually want or need then you'll be too rich soon to bother with stuff like being told to help a team fix their shit anyways.
EL_Loco 7y ago
Off topic, but you know the person doesn't play chess when (this is very common) they think that a chess master can spot a mate-in-1 and nobody else can. Mate in 1s are fairly easy to spot if you've been playing chess for, let's say, 2 years. In reality, a chess master would spot something like "bishop to queen whatever, rook takes bishop, pawn to whatever, rook takes pawn, queen to whatever and then you have mate in 2" I'm only whining about this because it's too common a cliché in popular culture.
- throw17ebfruary 7y ago
  Against me, a chess master can call "mate in X" before the first move.
  - mlyle 7y ago
    ;) Mate-in-___ means given the best possible response.
    - bluGill 7y ago
      Any master against me can call mate in 40 and be right. I did remove grandmaster though. Grandmaster is a lifetime title, while master is something earned and taken away. Thus former great can earn grandmaster and then go senile and play at a level below me - well at least in theory, I don't know if any exist but I'd love to play one just so I can say I beat a grandmaster.
      - casion 7y ago
        That's not correct if utilizing terms that are common chess parlance. "Mate in..." implies that a mate will occur, with a forcing sequence, with the longest branch being the announced number of moves. Given that chess is not solved, nobody can claim "Mate in..." from the starting position.
        bluGill 7y ago
eternalban 7y ago
The fact is that the architectural mindset is a very distinct and recognizable mentality and most certainly not the byproduct of a "process". I suggest one first try their hand at defining what is "architecture" and if one has trouble with that, suggestion is to not venture to the subsequent topic of "what is an architect and how does one recognize this rare [1] animal?" [1]: it is definitively a talent and a rare one at that.
- karatestomp 7y ago
  I've long had the notion that taste is secretly the most important quality of a good developer or worker in computing technology more generally, and we only pretend other things matter so much because taste is hard to measure in an interview, difficult to quantify, and no-one knows how to teach it reliably.
  - The_rationalist 7y ago
    What do you mean by taste?
    - tydok 7y ago
      Taste and Aesthetics https://www.artima.com/intv/taste.html https://www.artima.com/intv/taste.html Taste for Makers http://www.paulgraham.com/taste.html http://www.paulgraham.com/taste.html
  - friendlybus 7y ago
    Taste works well when you are in a position to receive a large amount of work that can be organised in a hierarchy according to the work's quality. We will need a lot of that in a few years. Working up from first principles, staying on time to produce a large quantity of stuff and discovering new facts are valuable methods too. You can't get to useful work from tasting without an ocean of work to receive.
phlakaton 7y ago
Let me tell you about the time I was called in as an architect to a technical meeting. Two teams were baffled why their systems weren't integrating properly, and each was heatedly pointing the finger at the other. Annoyed, I pulled up the code for the system call that was failing, and within a few minutes I found an int64 that was getting truncated incorrectly. I pointed it out to the team in the room. The shouting match suddenly grew very quiet, and I strolled out the door in satisfaction. Sometimes, on rare occasions, it is a mate-in-one.
- regulation_d 7y ago
  Sometimes you need org-level rubber-ducking.
- alexeiz 7y ago
  I noticed that oftentimes software developers on senior levels (and "architects" too) when faced with a problem, would start speculating about solutions without gathering the necessary information about the problem first. They would theorize that the problem is likely caused by something or maybe something else, then the solution should be some other thing, etc, etc. And they can go on and on along that path, because they have enough experience to do so. But in reality, all such speculations are bullshit. They should have realized that they missed some key information and instead of speculating, gathered the missing information first. Doing so would have saved them a lot of time and unnecessary meetings. I consider this a skill: to understand that there is a missing key information/knowledge without which all speculations are of little value, and what needs to be done to obtain that missing knowledge.
- rjzzleep 7y ago
  I had something similar but unlike you I was freshly in the company and it was a room full of people close to retirement. When I saw the suspected error before the meeting I spoke to one of the guys. He said I absolutely cannot mention the issue right away. He helped me workout a couple of questions I could ask to nudge them in the right direction. When the meeting started the Director of Infrastructure, some people of the accounting department and a couple of the IT people supporting them were shouting at each other and trying to find the one responsible for the fault(this bug actually cost them a couple of millions). I interrupted them by saying I don't care who's responsible and asking the questions I rehearsed. The director of infrastructure who was supporting the accounting people then found the issue(he retired a year later and yes weird structures in that company). Anyway, the guy was really proud and the accounting department was praising him and the blame each other games stopped until ... ... I had my 1on1 a while later and the CIO told me that he heard I was yelling at people in that meeting.
ryanthedev 7y ago
I enjoy this line of thinking, having domain knowledge is always critical to success. Being invested is always ideal. I would like to counter with the delivery transformations I have been apart of, the role of the architect has dried up. I do predict for most large enterprises the role of a manager will start to become more full stack and becoming that invested visionary technical leader and mentor. At least that's what I hope for...
Ididntdothis 7y ago
I know people who are good at architecture but I always get skeptical when people have the title “architect”. If they don’t keep working in the weeds I feel they often get out of touch soon. They may be good at doing nice presentations but their designs become more and more unrealistic.
- cmhnn 7y ago
  Any software "Architect" who can't build what they say to build should have to get a new job. Any programmer of less experience who continues to argue with the "Architect" after they have met the challenge of proving their ideas can be done should also have to get a new job. Many less senior programmers are better at the every day idioms of a given language or tools used in daily programming. Many senior people have to do more than just code. But most senior people who can still practice if called upon are much better problem solvers in part because they have already failed so many times and each new batch of programmers keep re-inventing the same mistakes.
  - Ill_ban_myself 7y ago
    What toxic pit do you work in where junior programmers are ARGUING with senior architects and the senior devs aren’t mentoring, reviewing and empowered to make key decisions in another room before junior developers ever see a spec? And how do I avoid working there?
    - cmhnn 7y ago
      A1) Your typical mega corp that is too big to be one thing and filled with geniuses around every corner. So some parts are a pit and some parts aren't. It depends. A2)Probably don't have to worry about it.
    - nitrogen 7y ago
      I've seen this in a couple of places. Junior dev assigned to design new system. Senior dev assigned to mentor junior dev. Senior dev encourages junior dev based on experience. Junior dev ignores everything senior dev says. Manager listens to whatever junior dev says and sidelines senior dev. Senior dev goes on vacation. System explodes.
thanatropism 7y ago
I wonder if the analogy "software architect" isn't being stretched too thin. What are the essential or characteristic traits of the architect as a professional and of architecture as an enterprise that translate or have direct equivalents in the software world? Are trained architects expected to be better sofware-architects than trained physicists or... chess masters?
deleted 7y ago
[deleted]
teambob 7y ago
Being an architect is like training a bag of cats. You are also in the bag
have_faith 7y ago
The interesting thing about grandmasters is their ability to recognise a winning position regardless of working out the moves yet, something AlphaZero (chess engine) seems to take to the extreme of recognising winning patterns that it can intuit will lead to winning games without hard calculation. Maybe the architect equivalent is someone explaining the structure of a system and instantly knowing roughly where the problems are before inspecting the individual parts. Like the grandmaster the architect will intuit better than most where the problems likely are given a high level overview.

73 points by yarapavan 7y ago

Architects have two primary purposes (not roles): 1) Facilitate that architecture and design happens in teams (dev or not) 2) Ensure coherency of architecture That's it folks!

tyingq 7y ago
That seems right. City planner seems more apt than chess master.
- jaggederest 7y ago
  I used to joke that the term "business-to-engineering psychologist" was more descriptive than "software architect". You had to know how to get people to agree a lot more than how to get technology to work together, especially in "larger organizations". It's politics, pure and simple - most of the conflict isn't technical.
  - mehh 7y ago
    damn right!
dehrmann 7y ago
Most places I've worked use the architect title to retain people.
pjmlp 7y ago
In many companies architects is just a synonym for a project manager that happens to also grok UML.

rehasu 7y ago

And then you go another level deeper and see everything is actually just different ways of doing the same old Linux and/or Java. I feel especially in Ops people can see that all the time. For instance just today I saw someone debug a NO_PROXY topic in Kubernetes. Kubernetes is super cool and works different than the old LAMP stacks or even Openstack. But still they deal with NO_PROXY not being standardized problems. Also shows that the same, actually hard problems (like standardizing something that is "out there" for more than a decade already) are never really solved. Each shiny new tool comes with its own way of doing things, but what they do with your input is in the end always the same. Mounting, multiprocessing, sockets, string parsing, memory management, log searching, etc. So yes, I think there's a way to become a chess master. You just need to go one level deeper and accept that there might be multiple topics that each will need half a decade to learn good enough to be useful.

cmhnn 7y ago

If the argument the blog is trying to make is Architects can't know everything then it's a bad article to submit. On the other hand, if the argument is a boss should not expect someone called Architect or senior engineer etc. to be able to troubleshoot based on experience I have a problem with that. If someone can't be air dropped and they have a title that is intended by the business as code for a senior level software person who can think of how to build systems and can also build them themselves, then I am not sure what they bring to the table.

loopz 7y ago
This is the problem with development for, forever. Most of the time, people are tasked with: Here's the spec/user story/loose idea/unrealistic wishlist, and can you be done before this weekend at least? What's the problem again? The facilitation of foundational discussions and exploration is seen as waste. So the business spends X months building the wrong idea, without any feedback and adjustments along the way whatsoever instead. To air-drop someone senior to set things straight. What a great way to sabotage organisational learning and simplification. Not that anybody gives a rats ass about eachother anyways, right?
- cmhnn 7y ago
  There are a lot of problems in the industry but the experienced helping the inexperienced on demand in response to a crisis doesn't seem like one that is nearly as serious as others. I am old enough to have been on XP teams and to have become a certified scrum master in its first few years. It's gotten out of hand. Being agile and blasting to an MVP is fine for people who think Netflix or sending dick picks is mission critical but with IOT and AI scenarios emerging that allow all the little software napoleans to fuck up something serious or inadvertently create a universal spying machine it might be time to put the breaks on for at least a class of problems. No industry hates old people as much as tech and that industry has people all over it like an idiot on another thread who clearly had no idea who Brian Kernighan was when they wrote their post. Young programmers have always been arrogant idiots. I was one myself. But it astounds me that many programmers today don't even know a ton of stuff that would make their job easier since it is shit that is already figured out or is shit the science says can't be figured out. I hate people that wallow in history as much as the next person with an ounce of inclination to independent thought but for fucks sake learn some basics before applying that code golf to 20,000 cores because that shit costs money you free food demanding little jack ass. As for building what the customers need or want? The more time I spend around programmers the less inclined I am to want them deciding anything for anyone in terms of features. If you're blessed enough to be great at programming and picking things people actually want or need then you'll be too rich soon to bother with stuff like being told to help a team fix their shit anyways.

EL_Loco 7y ago

Off topic, but you know the person doesn't play chess when (this is very common) they think that a chess master can spot a mate-in-1 and nobody else can. Mate in 1s are fairly easy to spot if you've been playing chess for, let's say, 2 years. In reality, a chess master would spot something like "bishop to queen whatever, rook takes bishop, pawn to whatever, rook takes pawn, queen to whatever and then you have mate in 2" I'm only whining about this because it's too common a cliché in popular culture.

throw17ebfruary 7y ago
Against me, a chess master can call "mate in X" before the first move.
- mlyle 7y ago
  ;) Mate-in-___ means given the best possible response.
  - bluGill 7y ago
    Any master against me can call mate in 40 and be right. I did remove grandmaster though. Grandmaster is a lifetime title, while master is something earned and taken away. Thus former great can earn grandmaster and then go senile and play at a level below me - well at least in theory, I don't know if any exist but I'd love to play one just so I can say I beat a grandmaster.
    - casion 7y ago
      That's not correct if utilizing terms that are common chess parlance. "Mate in..." implies that a mate will occur, with a forcing sequence, with the longest branch being the announced number of moves. Given that chess is not solved, nobody can claim "Mate in..." from the starting position.
      - bluGill 7y ago

eternalban 7y ago

The fact is that the architectural mindset is a very distinct and recognizable mentality and most certainly not the byproduct of a "process". I suggest one first try their hand at defining what is "architecture" and if one has trouble with that, suggestion is to not venture to the subsequent topic of "what is an architect and how does one recognize this rare [1] animal?" [1]: it is definitively a talent and a rare one at that.

karatestomp 7y ago
I've long had the notion that taste is secretly the most important quality of a good developer or worker in computing technology more generally, and we only pretend other things matter so much because taste is hard to measure in an interview, difficult to quantify, and no-one knows how to teach it reliably.
- The_rationalist 7y ago
  What do you mean by taste?
  - tydok 7y ago
    Taste and Aesthetics https://www.artima.com/intv/taste.html https://www.artima.com/intv/taste.html Taste for Makers http://www.paulgraham.com/taste.html http://www.paulgraham.com/taste.html
- friendlybus 7y ago
  Taste works well when you are in a position to receive a large amount of work that can be organised in a hierarchy according to the work's quality. We will need a lot of that in a few years. Working up from first principles, staying on time to produce a large quantity of stuff and discovering new facts are valuable methods too. You can't get to useful work from tasting without an ocean of work to receive.

phlakaton 7y ago

Let me tell you about the time I was called in as an architect to a technical meeting. Two teams were baffled why their systems weren't integrating properly, and each was heatedly pointing the finger at the other. Annoyed, I pulled up the code for the system call that was failing, and within a few minutes I found an int64 that was getting truncated incorrectly. I pointed it out to the team in the room. The shouting match suddenly grew very quiet, and I strolled out the door in satisfaction. Sometimes, on rare occasions, it is a mate-in-one.

regulation_d 7y ago
Sometimes you need org-level rubber-ducking.
alexeiz 7y ago
I noticed that oftentimes software developers on senior levels (and "architects" too) when faced with a problem, would start speculating about solutions without gathering the necessary information about the problem first. They would theorize that the problem is likely caused by something or maybe something else, then the solution should be some other thing, etc, etc. And they can go on and on along that path, because they have enough experience to do so. But in reality, all such speculations are bullshit. They should have realized that they missed some key information and instead of speculating, gathered the missing information first. Doing so would have saved them a lot of time and unnecessary meetings. I consider this a skill: to understand that there is a missing key information/knowledge without which all speculations are of little value, and what needs to be done to obtain that missing knowledge.
rjzzleep 7y ago
I had something similar but unlike you I was freshly in the company and it was a room full of people close to retirement. When I saw the suspected error before the meeting I spoke to one of the guys. He said I absolutely cannot mention the issue right away. He helped me workout a couple of questions I could ask to nudge them in the right direction. When the meeting started the Director of Infrastructure, some people of the accounting department and a couple of the IT people supporting them were shouting at each other and trying to find the one responsible for the fault(this bug actually cost them a couple of millions). I interrupted them by saying I don't care who's responsible and asking the questions I rehearsed. The director of infrastructure who was supporting the accounting people then found the issue(he retired a year later and yes weird structures in that company). Anyway, the guy was really proud and the accounting department was praising him and the blame each other games stopped until ... ... I had my 1on1 a while later and the CIO told me that he heard I was yelling at people in that meeting.

ryanthedev 7y ago

I enjoy this line of thinking, having domain knowledge is always critical to success. Being invested is always ideal. I would like to counter with the delivery transformations I have been apart of, the role of the architect has dried up. I do predict for most large enterprises the role of a manager will start to become more full stack and becoming that invested visionary technical leader and mentor. At least that's what I hope for...

Ididntdothis 7y ago

I know people who are good at architecture but I always get skeptical when people have the title “architect”. If they don’t keep working in the weeds I feel they often get out of touch soon. They may be good at doing nice presentations but their designs become more and more unrealistic.

cmhnn 7y ago
Any software "Architect" who can't build what they say to build should have to get a new job. Any programmer of less experience who continues to argue with the "Architect" after they have met the challenge of proving their ideas can be done should also have to get a new job. Many less senior programmers are better at the every day idioms of a given language or tools used in daily programming. Many senior people have to do more than just code. But most senior people who can still practice if called upon are much better problem solvers in part because they have already failed so many times and each new batch of programmers keep re-inventing the same mistakes.
- Ill_ban_myself 7y ago
  What toxic pit do you work in where junior programmers are ARGUING with senior architects and the senior devs aren’t mentoring, reviewing and empowered to make key decisions in another room before junior developers ever see a spec? And how do I avoid working there?
  - cmhnn 7y ago
    A1) Your typical mega corp that is too big to be one thing and filled with geniuses around every corner. So some parts are a pit and some parts aren't. It depends. A2)Probably don't have to worry about it.
  - nitrogen 7y ago
    I've seen this in a couple of places. Junior dev assigned to design new system. Senior dev assigned to mentor junior dev. Senior dev encourages junior dev based on experience. Junior dev ignores everything senior dev says. Manager listens to whatever junior dev says and sidelines senior dev. Senior dev goes on vacation. System explodes.

thanatropism 7y ago

I wonder if the analogy "software architect" isn't being stretched too thin. What are the essential or characteristic traits of the architect as a professional and of architecture as an enterprise that translate or have direct equivalents in the software world? Are trained architects expected to be better sofware-architects than trained physicists or... chess masters?

deleted 7y ago

[deleted]

teambob 7y ago

Being an architect is like training a bag of cats. You are also in the bag

have_faith 7y ago

The interesting thing about grandmasters is their ability to recognise a winning position regardless of working out the moves yet, something AlphaZero (chess engine) seems to take to the extreme of recognising winning patterns that it can intuit will lead to winning games without hard calculation. Maybe the architect equivalent is someone explaining the structure of a system and instantly knowing roughly where the problems are before inspecting the individual parts. Like the grandmaster the architect will intuit better than most where the problems likely are given a high level overview.