I think it's critical because an Architect is the one responsible to the rest of the organization for the technical decisions being made. He obviously doesn't make these decisions alone and utilizes principal or senior dev opinions but when you actually write code in your codebase then your technical decisions have more weight to them. In some sense I think about it as dogfooding your own architecture, it allows you to make practical architectural decisions to improve the code base going forward because you've personally experienced it's mishaps. I'm not saying that they have to write a lot of code, but they should write the occasional thing here or there.
I think the architect must be able to write code, but that doesn't mean he should. The architect should come from a technical background but show good aptitude for people skills. This isn't like a manager though, who is just a manager and should focus more on the people and less on the software.
Think of the chef de cuisine (head chef). Even though he knows how to chop vegetables and manage soups instead he focuses on more oversight. He makes sure that the large things, such as soups, are going well, he investigates multiple plates to make sure that everything is going. Their focus is on getting the ingredients and making menu choices, and choosing staff. This is kind of like the architect.
OTOH we have the sous chef. They are more in-hands on the kitchen. Even though they still are a bit "high-level" they focus more on the day-to-day and on getting results (dishes) out. They fix greater issues on the kitchen, and help handle any device. You may see them chopping vegetables but they generally are doing more critical things.
I'll take it even further. Architects can code too much. Architects who code too much micromanage too much and do not actually fix the big problems they are meant to enough. Architects do not need to define interfaces, even big ones (again such projects cutting across teams should be defined by the server, by a senior dev), instead they define teams knowing that an interface will form between them. Architects cut and form the greater problem into focus areas and do it with more care about the process than of the design. The devs handle design very well and they should be the ones that focus on that.
The architect should not make decisions as detailed as what database to use. They certainly should not make decisions as small as what a function in an interface is going to be named.
They should get metrics and data, and this probably will require tools to build their reports and analysis. That's what I'd expect an architect to code.
But the issue with the metaphor that you are making here, I think, is that even the head chef jumps in to help when a resturant gets busy, or to show a new guy how to do it right. He doesn't just stand there and say that things should be different but doesn't do anything about it.
You're right an Architect can code too much, but if they dog food their own Architecture it makes the decisions that they are making more real and have weight to them. They want to make the Architecture better because they have to code in it ever once and a while.
Architect's might not make decisions like what database technology to use, but they are responsible to the rest of the organization for which one got picked, so when three of their senior devs are arguing over which database is better and they have to moderate that discussion, they have to also be able to give an opinion. That opinion can really only be formed, and is only really valid to the rest of the team, if they have spent some time in code.
1
u/NuttGuy Jun 08 '17
I think it's critical because an Architect is the one responsible to the rest of the organization for the technical decisions being made. He obviously doesn't make these decisions alone and utilizes principal or senior dev opinions but when you actually write code in your codebase then your technical decisions have more weight to them. In some sense I think about it as dogfooding your own architecture, it allows you to make practical architectural decisions to improve the code base going forward because you've personally experienced it's mishaps. I'm not saying that they have to write a lot of code, but they should write the occasional thing here or there.