6 ms·

Architects make the best decisions when they code In the Tech Lead courses I run, I advocate for Tech Leads to spend at least 30% of their time coding.

Architects make the best decisions when they code In the Tech Lead courses I run, I advocate for Tech Leads to spend at least 30% of their time coding. Spending time with the code helps build trust, respect and a current understanding of the system. Making architectural decisions without regard for the constraints of the current system are often bad decisions. I really hate it when people don't know the difference between an architect and a tech lead. I'm happy that you gave your tech lead a title bump if that's what you want to do, but there is a difference. If you have your architects coding you are wasting time and money. Hire another programmer and have your architect do what they are supposed to.

FordPrefectAO 11y ago
I think the article is saying: people who are making architectural decisions (whatever their job title) should spend some time coding the system they make decisions for. It's easy enough for me to buy.
nickpeterson 11y ago
Honestly, many people that are architects can't code. Forcing them to code on the project helps save organizations from trusting important architectural decisions to people who simply are not or never were developers. Also it helps teams work together if the person often creating work for developers understands exactly what he's asking them to do.
umanwizard 11y ago
Titles and job roles vary enough across the industry that I'm pretty sure there isn't a canonical, obviously correct meaning to things like "architect".
- AstroJetson 11y ago
  I agree that job descriptions can vary. The article says "Architects make the best decisions when they code" and then goes on about having "tech leads" code. In a startup the CIO / CTO can be coders (they may be the other partner in a 2 person company). But in a company that is 12 years old, they should be at the point that they have high level/high talent people doing those jobs. So I would expect that they have a CEO that runs the company and a CIO that runs IT and architects that do systems / application architecture. Not spending a day and a half each week cranking out code.
  - nilliams 11y ago
    The argument I imagine (and that I agree with) is that if you aren't in touch with the code you begin to lose touch (esp. in this fast-moving industry) and you become an ivory-towered twit that your teammates can't relate to and begin to resent. I am a fairly experienced JS dev and I can't imagine retiring to a hands-off architect role in that world, because there are so many tool choices and options in terms of programming style (even languages that compile to JS), so I feel like I need to be regularly writing 'app code' to know how to advise my teammates well. Saying 'though shalt write TypeScript and use these libraries, and these OOP practices, and structure your app in this way' would feel fairly obnoxious if I wasn't working with the team, with those technologies to write actual code myself. If my teammates instead wanted to do functional programming in Elm, and all I could offer was hypotheticals as to why that was a bad idea, I really wouldn't expect my teammate's respect, and would expect them to be quite-rightly put-out.
    - AstroJetson 11y ago
      There is a difference between the two. As an architect you would need to keep up with what the different tool sets (compilers, transpilers, frameworks, database interfaces, etc, ) and what's going on in those spaces. Understand why your currently chosen toolset is working and where their roadmap is and how well your company is on that roadmap. Whats the new universe of tool in your space, is one of them going to help you? Is it something you should pilot/plan for, keep an eye on or ignore? You need to focus on that and figure that out. Having you work on tickets or new features isn't the best use of your time. Working out how it all works (and works well) together and where the holes are is your prime function. Let's talk about the "Thou shalt". That's when you lead the education process. Why AstroScript is the way, what it will do, how it will work, how it scales, etc. You get some level of buyin and once that's done the team rocks and rolls in that effort. You want to help out with the first set of features fine, but once they get going let them go and get out of their way. You then look for the next thing down the road. Hey your team wants to do Elm? Is that in the plan, have all the little nuances been looked at, does it scale, etc. etc. Yes, then go that way. No? Then it's up to you to either close the gaps with Elm or put the ship back on track. That's what architects do. I understand people ending up as "white board architects". They suck, they happen. You can be "hands on", be an advisory, be a resource, be involved with the team. But you shouldn't be cutting daily code. Lastly, I want to repeat that the original article is about a company that is 12 years old. Well past a few developers, a company that wants and should be on a growth path. Scout around and look at some Y successes that are $100+ million companies. Track their architect(s) down and ask what they do. If they are spending 30% of their time doing app-dev write back to me. Happy to treat you to dinner anywhere in Philly.
jacques_chester 11y ago
I think the concept of software architects as a kind of Supreme Leader, distinct from team, is a legacy of waterfall. A project fails. It is an expensive failure. Fingers are pointed. Lessons are "learned". "Never again!" is the cry. A new project is authorised. More effort is put into the front of the project, because that's what the classic software engineering literature says you must do to avoid costly failures. The budget is bigger, but that's OK, because it's being spent on requirements analysis and some architects to Make Sure It Goes Right This Time. The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned". A new project is authorised. Even more effort is put into the front end. Even more money. "This time we're going to hire Senior Architects!". Firms that used to be accountancies, but have now discovered the lucrative value of having interns move boxes in Visio while billing out the Senior Architect for $800/hr, are called in to help. The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned". A new project is authorised ...
lbarrow 11y ago
Do you really think software architects shouldn't write code? It's very very important that someone designing the system in the large understand how it actually works day to day, and writing code is an effective way to do that.
maxxxxx 11y ago
I work a lot with architects in our IT department and I have had that title before. In my view an architect that doesn't keep coding will be outdated within a few years and most of them know that they are not really needed. Coming up with an architecture should be fairly easy for experienced senior developers if allowed to do so. Actually implementing it and adapting the architecture to real-world problems is the hard part.
dasil003 11y ago
Maybe you should enlighten us then. An architect who doesn't code to me is redundant. And BTW, I say this as a developer with 20 years experience who has turned CTO as my company approached 50 employees. I am extremely capable of thinking through architecture level decisions, and it is my prerogative to declare myself chief architect and fulfill that role if I wish. The only problem is, as someone who is writing very little code these days, it would be extremely foolish for me to dictate architecture down to my senior engineers. To me, "Architect" has become an anachronism, it dates from a time when programming experience was thin on the ground, and languages were very low level, requiring a lot of bit twiddling and optimization to be viable. Under those circumstances, it makes more sense to have someone laying things out without writing any code. These days, I just don't see the point.

FordPrefectAO 11y ago

I think the article is saying: people who are making architectural decisions (whatever their job title) should spend some time coding the system they make decisions for. It's easy enough for me to buy.

nickpeterson 11y ago

Honestly, many people that are architects can't code. Forcing them to code on the project helps save organizations from trusting important architectural decisions to people who simply are not or never were developers. Also it helps teams work together if the person often creating work for developers understands exactly what he's asking them to do.

umanwizard 11y ago

Titles and job roles vary enough across the industry that I'm pretty sure there isn't a canonical, obviously correct meaning to things like "architect".

AstroJetson 11y ago
I agree that job descriptions can vary. The article says "Architects make the best decisions when they code" and then goes on about having "tech leads" code. In a startup the CIO / CTO can be coders (they may be the other partner in a 2 person company). But in a company that is 12 years old, they should be at the point that they have high level/high talent people doing those jobs. So I would expect that they have a CEO that runs the company and a CIO that runs IT and architects that do systems / application architecture. Not spending a day and a half each week cranking out code.
- nilliams 11y ago
  The argument I imagine (and that I agree with) is that if you aren't in touch with the code you begin to lose touch (esp. in this fast-moving industry) and you become an ivory-towered twit that your teammates can't relate to and begin to resent. I am a fairly experienced JS dev and I can't imagine retiring to a hands-off architect role in that world, because there are so many tool choices and options in terms of programming style (even languages that compile to JS), so I feel like I need to be regularly writing 'app code' to know how to advise my teammates well. Saying 'though shalt write TypeScript and use these libraries, and these OOP practices, and structure your app in this way' would feel fairly obnoxious if I wasn't working with the team, with those technologies to write actual code myself. If my teammates instead wanted to do functional programming in Elm, and all I could offer was hypotheticals as to why that was a bad idea, I really wouldn't expect my teammate's respect, and would expect them to be quite-rightly put-out.
  - AstroJetson 11y ago
    There is a difference between the two. As an architect you would need to keep up with what the different tool sets (compilers, transpilers, frameworks, database interfaces, etc, ) and what's going on in those spaces. Understand why your currently chosen toolset is working and where their roadmap is and how well your company is on that roadmap. Whats the new universe of tool in your space, is one of them going to help you? Is it something you should pilot/plan for, keep an eye on or ignore? You need to focus on that and figure that out. Having you work on tickets or new features isn't the best use of your time. Working out how it all works (and works well) together and where the holes are is your prime function. Let's talk about the "Thou shalt". That's when you lead the education process. Why AstroScript is the way, what it will do, how it will work, how it scales, etc. You get some level of buyin and once that's done the team rocks and rolls in that effort. You want to help out with the first set of features fine, but once they get going let them go and get out of their way. You then look for the next thing down the road. Hey your team wants to do Elm? Is that in the plan, have all the little nuances been looked at, does it scale, etc. etc. Yes, then go that way. No? Then it's up to you to either close the gaps with Elm or put the ship back on track. That's what architects do. I understand people ending up as "white board architects". They suck, they happen. You can be "hands on", be an advisory, be a resource, be involved with the team. But you shouldn't be cutting daily code. Lastly, I want to repeat that the original article is about a company that is 12 years old. Well past a few developers, a company that wants and should be on a growth path. Scout around and look at some Y successes that are $100+ million companies. Track their architect(s) down and ask what they do. If they are spending 30% of their time doing app-dev write back to me. Happy to treat you to dinner anywhere in Philly.

jacques_chester 11y ago

I think the concept of software architects as a kind of Supreme Leader, distinct from team, is a legacy of waterfall. A project fails. It is an expensive failure. Fingers are pointed. Lessons are "learned". "Never again!" is the cry. A new project is authorised. More effort is put into the front of the project, because that's what the classic software engineering literature says you must do to avoid costly failures. The budget is bigger, but that's OK, because it's being spent on requirements analysis and some architects to Make Sure It Goes Right This Time. The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned". A new project is authorised. Even more effort is put into the front end. Even more money. "This time we're going to hire Senior Architects!". Firms that used to be accountancies, but have now discovered the lucrative value of having interns move boxes in Visio while billing out the Senior Architect for $800/hr, are called in to help. The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned". A new project is authorised ...

lbarrow 11y ago

Do you really think software architects shouldn't write code? It's very very important that someone designing the system in the large understand how it actually works day to day, and writing code is an effective way to do that.

maxxxxx 11y ago

I work a lot with architects in our IT department and I have had that title before. In my view an architect that doesn't keep coding will be outdated within a few years and most of them know that they are not really needed. Coming up with an architecture should be fairly easy for experienced senior developers if allowed to do so. Actually implementing it and adapting the architecture to real-world problems is the hard part.

dasil003 11y ago

Maybe you should enlighten us then. An architect who doesn't code to me is redundant. And BTW, I say this as a developer with 20 years experience who has turned CTO as my company approached 50 employees. I am extremely capable of thinking through architecture level decisions, and it is my prerogative to declare myself chief architect and fulfill that role if I wish. The only problem is, as someone who is writing very little code these days, it would be extremely foolish for me to dictate architecture down to my senior engineers. To me, "Architect" has become an anachronism, it dates from a time when programming experience was thin on the ground, and languages were very low level, requiring a lot of bit twiddling and optimization to be viable. Under those circumstances, it makes more sense to have someone laying things out without writing any code. These days, I just don't see the point.