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.
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".
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".
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.
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.
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.
What are your lessons learned on how Architects should keep up (and avoid becoming whiteboard architects)?
My personal realization is that it is necessary to be hands on to understand new technology rather than just reading up documentation and others' opinions on such technology.
Actually this is good for any architect. The ability to achieve consensus across all the groups gets you the buy-in that you need. It also ferrets out the detractors that are going to spend the next decade throwing rocks at the decision.
Next is go make friends with the operations people. Learn how operations works and what they do, how they monitor, how they keep things running. While they appear to be BOFH like, when they get the idea that you are listening to them, they will help you out. Make sure someone from OPS is on your consensus team. I had a white board architect (WBA) work for me and I made him get signature approval from OPS on everything he proposed. After awhile he got it and became less of a WBA.
Do lots of proof of concepts to see if what you are thinking about will work. In the past I've had a cadre of co-ops / interns do the grunt work. They are always excited about working with a new technology.
(If you are in the Philly Area, call Drexel University. You can get co-op students year round in either 3 or 6 month increments. Pro tip: Don't hire them until after they graduate. If you don't send the co-op back to the University so the Uni can get the rest of their money, they will stop sending you co-ops. )
The other advantage of co-ops is that you can afford to go down some dead ends. It's a win-win, you use a less expensive resource to find out bad news, the co-op gets to put "Worked on Astroscript at major company" on their resume. It's very freeing because you can then take on someone from the outside going "Hey lets do Elm", assign an co-op to do most of the grunt work rather than burning your time up.
You can be as hands on as you want. I've always found that getting some new tool installed is a huge mess. Need this library and that version of something else, these scripts don't work, etc. So my co-ops do that. Once it's spun up and running and their first mini-Proof Of Concept is working then I'll get involved with a larger POC and get my hands dirty.
(An aside on the install mess. When we get ready to start the "Moving to Astroscript" to the internal consensus cycle, I assign a co-op to package it. They put together a clean setup process for both Operations and the Dev Manager to sign off. Nothing kills a project faster than the people you want approval from not being able to spin it up to look at it.)
It's mostly lots and lots of talking to people about what their pain points are, what direction the business is going in, thinking about planned and unplanned pivots, etc. Always be thinking about a Plan B.
My check list for new things (in order)
* What business value does this bring (ROI)
* How does operations run this
* What is the Disaster Recovery Plan
* What is the opportunity cost
* What is the internal friction
* What is the external friction with our partners
Other things that may help:
Start a series of brown bag sessions (your call if the bags contain lunch or beer) and present out to anyone what you are thinking about. ( Tip: Master the ability to create a 50 minute long Powerpoint in 30 minutes. )
Talk to other architects / users that are using the tools, designs, etc. and see what they are finding out. Be ready to share back what you find. "Hey our review and POC of Astroscript figured out that getting any useful logging out of it was impossible, so we are punting"
Be a nice person. And remember, someday you may end up working for one of those co-ops.
I've found it is easy to avoid white board architects:
Dont give them any actual authority.
If they want to drive architecture in a certain direction then they have to convince the senior developers, project managers, and tech leads to follow them.
As someone who works with a bunch of architects who don't code, I'd really rather not. It's basically a one way road to not being current, which in theory shouldn't matter, but in reality it very much seems it does.
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.
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.
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.
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.
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.
