5 ms·

Software Architecture is vitally important to the long term success of a software system. Software Architects are not the only way to get software architecture

Software Architecture is vitally important to the long term success of a software system. Software Architects are not the only way to get software architecture. They may even be the worst way. "Software Architects who Code" often do not suffer from this issue, depending on how much they actually get involved in production software and operations. However I would struggle to define a meaninful difference between a "Software Architect who Codes" and a sufficiently "Senior Software Developer".

malandrew 7y ago
Could not agree more about coding. These days I am doing more architecting and code reviews with coding as time permits and the less coding I do the less I’m able to stay ahead of pathologies developing in the codebase as the codebase scales. Right now I’m trying to get the engineers I lead to be more self sufficient on code reviews among themselves and self directed in terms of what to do next so I can spend enough time coding. It’s hard to do if the team is growing and the number of inbounds demanding your attention grows.
- taurath 7y ago
  API and system design is usually technique agnostic - but I think the biggest reason to have someone designing the system close to those doing the work is both motivation and buy in. As people get more senior they tend to code less frequently, but that’s usually okay - a doc describing all aspects of a system is very much a coding exercise.
mixmastamyk 7y ago
Some places call this a "Principal Developer." Believe it is largely the same thing, i.e. software/system designer.
- zwkrt 7y ago
  In my time at $bigCorp, I saw the title “principal engineer” used to describe two positions simultaneously, and sometimes both in the same org; - the good, hands-on, full-of-wisdom senior engineers, whose relevant experience and strong vision enable an entire floor of developers to build the right stuff and quickly. These guys made commits to high and low level code, from network debugging to interpreter design. Really inspiring people. - The toxic “ideas guy” “architects” who believe it is their job to write white-papers on how everything should be, without providing any guidance on how to actually get there. They believe that all problems would be solved if only we had the right perspective, even though perspective can’t be executed on x86 architecture. These guys constantly made me wonder why they were there and what they did all day.
- qznc 7y ago
  Sometimes the architecture is not designed by a single person. Sometimes it is a group. Sometimes it evolves from every-developer-does-it. Sometimes the role switches quickly from person to person. I don't know scientific studies to compare the approaches. Usually everbody just agrees that ideally one person should do it all. It is usually easy to identify architectural decisions. You can then find out who made that decision and thus figure out who is the architect. For example, in a web project: Who decided to build microservices vs a monolith? Who chose the database technology (PostgreSQL vs MySQL vs MongoDB vs ...)? Who chose the cloud platform? Who introduces external SaaS products? Who split up the big thing into pieces for different teams?
siggen 7y ago
I feel managers, directors, etc. who cannot code should not be managing, either. You have two classes: management and individual contributors, when there shouldn’t be. Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.
- sidlls 7y ago
  This depends on the size and context of the organization. I'd argue that front-line managers should handle trivial, low-priority, low-glamour development, but not more than a small fraction of their time (say between 10% - 30%). If they're doing development work that is more sophisticated or requires more of their time, they aren't going to be able to do their more important job: managing. Managing, by the way, is more than just having 1:1s every week and filling in the budget spreadsheets--it's negotiating for priority, fighting for direct reports' career needs (e.g. fighting to get the team assigned the projects that ICs will be able to use in their performance reviews) and balancing that against the needs of the business, etc.
  - siggen 7y ago
    Mmm, what I was arguing for is that a manager ought to have sufficient experience that they can substitute for and work as any individual under them. I understand that many large institutions are constructed in a mechanism you describe. In many cases, these managers are technical enough that they can substitute any individual working under them. There are also many cases where they are not sufficiently technical. Nonetheless, if a manager’s purpose tailored towards prioritizing, fighting for projects, and assisting ICs career growth, I am not convinced that that manager is necessary as I am not seeing his value. Prioritization ought to be intrinsic for everyone and is more a collaborative choice, no? Why does a single individual (manager) decide priority?
    - sidlls 7y ago
      Prioritization is a collaboration in many parts: between members of a team including the manager, and between managers, their managers, etc. Often ICs don't have the context necessary to contribute much to the conversation once it leaves the sphere of influence of the team they're on--and more importantly most of them don't want to acquire that context, often because they view it as inferior work that is beneath them. They don't see value in management because they can't see past their own egos and myopia.
ztjio 7y ago
I'm a Software Architect who made a progressive move to that role after being a Sr. Software Engineer for almost a decade. I see the distinction as pretty simple. We do the same things, but, we specialize in terms of time spent and breadth of awareness and contact in the business. As far as skills go I expect to maintain my coding skills and as far as what I know more about than other SE's is not about skill as much as it is about practicality of time spent. We need the devs to be writing code/implementing every day and the architects spend more time on the, well, architecture as well as business interfacing and planning side. So that's basically it, the difference is where we spend our time and focus. It's more about roles and needs of the group than about the skill set. At least, that's what I'd hope. Anyone thinking they are a Senior level engineer who can't understand the concepts of software architecture needs to rethink their position and maybe broaden their skill set a bit, imho.
- Retric 7y ago
  Good Software Architects can make a huge positive impact over time. But, people often fail to live up to the role. The most common issue in my experience is Software Architects who don’t spend ~10 to 25% of their time actually working with the code base are largely ignored. You get things like two layers that are both 100% 1:1 mappings of the layer below them. It’s not about coding skills, but software is complex enough people quickly lose touch without regular feedback. Resulting in people spending a lot of time solving non problems.
  - crimsonalucard 7y ago
    I think "architect" is code for manager who is slightly technical enough to make high level decisions about a system. You get layers that are 1 to 1 mappings from engineers? Gee only software architects have the innate ability to notice an issue like that. An isomorphic layer more than likely exists as a translation layer to make composition with another layer easier even though entities are bijective. So you think an engineer is unable to comprehend anything about a layer that is basically an identity morphism in disguise? Wow. Please tell me about some other architect things that an engineer is unable to comprehend. I would like to learn more from great architects who have super powers like "big picture thinking"
jffhn 7y ago
Your last sentence reminds me of https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
- shyneeup 7y ago
  this was a great read thanks!
RugnirViking 7y ago
"They may even be the worst way." I'm interested in whether you think this could be the case even when compared with say a development team designing the architecture as they go.

malandrew 7y ago

Could not agree more about coding. These days I am doing more architecting and code reviews with coding as time permits and the less coding I do the less I’m able to stay ahead of pathologies developing in the codebase as the codebase scales. Right now I’m trying to get the engineers I lead to be more self sufficient on code reviews among themselves and self directed in terms of what to do next so I can spend enough time coding. It’s hard to do if the team is growing and the number of inbounds demanding your attention grows.

taurath 7y ago
API and system design is usually technique agnostic - but I think the biggest reason to have someone designing the system close to those doing the work is both motivation and buy in. As people get more senior they tend to code less frequently, but that’s usually okay - a doc describing all aspects of a system is very much a coding exercise.

mixmastamyk 7y ago

Some places call this a "Principal Developer." Believe it is largely the same thing, i.e. software/system designer.

zwkrt 7y ago
In my time at $bigCorp, I saw the title “principal engineer” used to describe two positions simultaneously, and sometimes both in the same org; - the good, hands-on, full-of-wisdom senior engineers, whose relevant experience and strong vision enable an entire floor of developers to build the right stuff and quickly. These guys made commits to high and low level code, from network debugging to interpreter design. Really inspiring people. - The toxic “ideas guy” “architects” who believe it is their job to write white-papers on how everything should be, without providing any guidance on how to actually get there. They believe that all problems would be solved if only we had the right perspective, even though perspective can’t be executed on x86 architecture. These guys constantly made me wonder why they were there and what they did all day.
qznc 7y ago
Sometimes the architecture is not designed by a single person. Sometimes it is a group. Sometimes it evolves from every-developer-does-it. Sometimes the role switches quickly from person to person. I don't know scientific studies to compare the approaches. Usually everbody just agrees that ideally one person should do it all. It is usually easy to identify architectural decisions. You can then find out who made that decision and thus figure out who is the architect. For example, in a web project: Who decided to build microservices vs a monolith? Who chose the database technology (PostgreSQL vs MySQL vs MongoDB vs ...)? Who chose the cloud platform? Who introduces external SaaS products? Who split up the big thing into pieces for different teams?

siggen 7y ago

I feel managers, directors, etc. who cannot code should not be managing, either. You have two classes: management and individual contributors, when there shouldn’t be. Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.

sidlls 7y ago
This depends on the size and context of the organization. I'd argue that front-line managers should handle trivial, low-priority, low-glamour development, but not more than a small fraction of their time (say between 10% - 30%). If they're doing development work that is more sophisticated or requires more of their time, they aren't going to be able to do their more important job: managing. Managing, by the way, is more than just having 1:1s every week and filling in the budget spreadsheets--it's negotiating for priority, fighting for direct reports' career needs (e.g. fighting to get the team assigned the projects that ICs will be able to use in their performance reviews) and balancing that against the needs of the business, etc.
- siggen 7y ago
  Mmm, what I was arguing for is that a manager ought to have sufficient experience that they can substitute for and work as any individual under them. I understand that many large institutions are constructed in a mechanism you describe. In many cases, these managers are technical enough that they can substitute any individual working under them. There are also many cases where they are not sufficiently technical. Nonetheless, if a manager’s purpose tailored towards prioritizing, fighting for projects, and assisting ICs career growth, I am not convinced that that manager is necessary as I am not seeing his value. Prioritization ought to be intrinsic for everyone and is more a collaborative choice, no? Why does a single individual (manager) decide priority?
  - sidlls 7y ago
    Prioritization is a collaboration in many parts: between members of a team including the manager, and between managers, their managers, etc. Often ICs don't have the context necessary to contribute much to the conversation once it leaves the sphere of influence of the team they're on--and more importantly most of them don't want to acquire that context, often because they view it as inferior work that is beneath them. They don't see value in management because they can't see past their own egos and myopia.

ztjio 7y ago

I'm a Software Architect who made a progressive move to that role after being a Sr. Software Engineer for almost a decade. I see the distinction as pretty simple. We do the same things, but, we specialize in terms of time spent and breadth of awareness and contact in the business. As far as skills go I expect to maintain my coding skills and as far as what I know more about than other SE's is not about skill as much as it is about practicality of time spent. We need the devs to be writing code/implementing every day and the architects spend more time on the, well, architecture as well as business interfacing and planning side. So that's basically it, the difference is where we spend our time and focus. It's more about roles and needs of the group than about the skill set. At least, that's what I'd hope. Anyone thinking they are a Senior level engineer who can't understand the concepts of software architecture needs to rethink their position and maybe broaden their skill set a bit, imho.

Retric 7y ago
Good Software Architects can make a huge positive impact over time. But, people often fail to live up to the role. The most common issue in my experience is Software Architects who don’t spend ~10 to 25% of their time actually working with the code base are largely ignored. You get things like two layers that are both 100% 1:1 mappings of the layer below them. It’s not about coding skills, but software is complex enough people quickly lose touch without regular feedback. Resulting in people spending a lot of time solving non problems.
- crimsonalucard 7y ago
  I think "architect" is code for manager who is slightly technical enough to make high level decisions about a system. You get layers that are 1 to 1 mappings from engineers? Gee only software architects have the innate ability to notice an issue like that. An isomorphic layer more than likely exists as a translation layer to make composition with another layer easier even though entities are bijective. So you think an engineer is unable to comprehend anything about a layer that is basically an identity morphism in disguise? Wow. Please tell me about some other architect things that an engineer is unable to comprehend. I would like to learn more from great architects who have super powers like "big picture thinking"

jffhn 7y ago

Your last sentence reminds me of https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

shyneeup 7y ago
this was a great read thanks!

RugnirViking 7y ago

"They may even be the worst way." I'm interested in whether you think this could be the case even when compared with say a development team designing the architecture as they go.