Should architects code?
Robert Morschel
May 08, 2017
There is this rumour going around that good architects need to write (production) code. I think the term was coined by Scott Ambler of agilemodeling.com, or was it ThoughtWorks? Anyway, I don't care, because I disagree.
See, I did write code, a lot of it. I was good at it, and I still like to write code for my own pleasure, but my current, full-time role as an enterprise architect does not involve much coding. As a result, I have become slightly detached from the way code is written in our company (tools, processes, etc.) and when I do, it is laborious and frustrating. In fact, I would respectfully suggest that letting me near production code might: a) not be the best use of my time, b) be dangerous.
It's not because I'm older, or wiser, or slower, or too important to code. It's because I spend my time thinking about different abstractions: higher-level ones. The principles are the same, but the moving parts are larger.
See, I write enterprise code.
My IDE is Powerpoint ... or Word, if I'm feeling adventurous.
I am like the town planner. Sure, I could have a go at building a house, but would you really want to live in it?
I know I wouldn't.
But what do you think?
rmorschel
soa-probe.com
Twitter
GitHub
Very good read, loved the "I write enterprise code" thought.
I'm a Solutions Architect with a heavy engineering background (6+ years) and the lack of coding in this position made me feel weird at the beginning. We might not be able to code for our company, but as you said, we focus on the higher-level abstractions, and adding this up with the comment below from Kim Arnett, I would like add this thought: Any professional that takes an engineering enterprise role that do not involve code, has, as part of his or her responsibilities, to be up to date to envision new solutions/architectures. I still code - it's part of my life - but today I code focused on exploring new technologies, learn patterns, architectures, etc.
It's up to the professional to get outside of the role scope to perform better if required.
Spot on! An architect should be up to date withtools, paradigms, patterns, etc. This can only be done by using them, i.e. coding. It could be production code or "callistenics" just to try things out. An architect whose only tools are PowerPoint and Word is, in my opinion, doomed to become technically obsolete and out of touch with the issues that affect the dev teams.
Not an architect - but I've worked with plenty who stopped coding. I'm in mobile, which means things are changing quicker than we can keep up sometimes. Even new programming languages. If our architect is not touching the code at any level, they are not building the best solution for the current tools. Reviews, at minimum, would help, like Daniel was saying.
But, also depends on the technology stack. Architects should code (or be involved with code) IF it helps them build a better solution/product.
Hello, I would like to respond to this point of view. I think more and more that the "architect" role is more and more a non-sense. The typical path to become architect is to be good at "coding" and that because you're good at it, you're removed from it ! Or you work with "higher abstractions" and loose in my opinion the reality of the day to day job.
I think being a developper role shouldn't just be passive and implement what other people (disconected more and more from reality) told them to.
Don't forget, code will always win. Not the specs, or the architectures plans...
I wish more and more good developers stay developers and help new ones and that management respect and listen to their opinions.
Look at this video of Robert Martin youtube.com/watch?v=ecIWPzGEbFc if you need other arguments about it. We are talking here about ethical questions too. Who is responsible of the code ?
You may think that I am switching from topic, but I think these are very related to each other.
Plus younger generations will obey less and less to orders they don't agree with or orders they do not approve. And have architects, "concepteur" and a lot of a vertical hierarchy in the code belong to the past.
Agreed, to a degree. I am an architect, too. In my current position, I rarely have contact with the code. At my last position, I often teamed up with the devs to design code, find bugs, etc. I now realize that this was very valuable and miss that link to the actual code base. By conducting many pairing sessions I got a good code overview that I could put to use by helping design and even debugging code in short chats with devs at the watercooler - it really felt good to hear from the dev that you have helped them solve their problem a few hours or a day later, and I would like to get this feeling back.
I am the same. Coding is what drew me to software. Leaving it behind, even if the problems one solves are higher level, and move bigger blocks, still hurts.
I used to work as a software architect in the past, and due to the lack of (good) developers I also wrote production code for the same project. It was really exhausting having to think of both the project as a whole and of my feature development in the same time.
More to the point: I think architects should write (or "should have been written in the not-so-distant-past") production code. There are several reasons for this:
This all depends on the type of architect we're talking about, though. In the big enterprise world, the architect is the person that knows all about how the business works and what platforms, applications, and people are involved, so he/she may be able to translate business requirements into architecture and, ultimately, in a set of requirements for different vendors.
In the software development world, the architect knows all about the product/solution and yes, it may be involved in some coding. As other commenters said - an architect is a really good software developer.
Architects have a variety of backgrounds. Take an enterprise data architect, for example. May have never coded in anything outside of SQL, but they still need to know when it's beneficial for the enterprise to adopt a nosql solution. Or an enterprise network architect - may have never written any code at all and that wouldn't impact his job.
I've heard plenty of horror stories about architects that choose the toolset or plan APIs for the development team.
Depends on the size of your software shop. Were a team of three and though I do find myself architecting overall solutions we simply don't have the man power for any of us to just do that one thing.
By stepping in and implementing features yourself, you're also proving the architecture you designed is feasible to put into practice. I've designed things in the past that simply didn't work the way I'd hoped. If you at least produce proof-of-concept code for elements your shop hasn't implemented previously, you can lighten the load on the devs putting your ideas into something concrete. Helps avoid getting too far down a design route before realising you've made a bad decision that might have a lot of time-costly knock on effects further down the road...
For me there are only developers. An "architect" is just a developer with more responsibility of the full view of the system. If a developer doesn't know about architecture, doesn't add to the conversation, and doesn't take decisions, either they are a shy junior (that needs encouragment/experience) or a drone that I don't want to work with. If an architect that doesn't code tells me how to do my job, it indicates that I am working on the wrong place.
Writing code is writing a design. Is choosing what is the most appropriate tool, datastore, caching system, being distributed system or not.
An architect is an experience developer. If you loose your developer skills, then you are loosing design skills. Your architecture becomes detached of reality. And then becomes responsibility of the other developers to fix or hack around it.
What is the meaning of "enterprise code". Is the actual code not enterprise code?
Considering the architect's role distinct from the developer's one is a residual of the building metaphor applied to software development. Personally I find it difficult to consider the architect's role as distinct from the developer's one. In my opinion a so-called architect should be an experienced developer able to see the (infra)structure of a system from an higher level and able to make decisions in order to solve a problem and guarantee some non explicit requirements (maintainability, security, readability, reusability, etc.)
It is great that you work for such a large organization that they can afford a person who attends meetings as their primary contribution. Also your organization is large enough that they can afford the technology choice mistakes you make because over time the technical environment changes dramatically and you slowly become completely out of touch and start making decisions based on what you knew first hand 5-10 years ago. I do know architects that don't code - they were super good coders and decided to become "developers of talent" instead of "developers of code". A key to this pattern of individual is that they dip back in from time to time to stay abreast of the latest technology changes. Also for someone to do the architect job well without regular coding they need to be super quick learners of new technology.
Perhaps the biggest problem is that you think you can be a good architect and avoid coding. Sounds like you are rationalizing a six-figure salary+administrative assistant just to go to meetings all day long while letting the skills that got you there fade away. "Enterprise Security Architect" = "The person who can't really protect the company but can be conveniently fired if something goes wrong". A similar argument can be made for non-technical CIOs or CSOs. Nice to have, easy to fire as a symbolic gesture when something goes wrong. No actual talent loss because all they did was sling PowerPoint at meetings. Nice work if you can get it.
If you don't program you have no business doing architecture. It's a fallacy to believe you can be in tuned with the needs of software without being involved in it's writing and deployment .
There's no way you can understand the needs of a database without being strongly aware of how the database is used. There's no way you can understand the needs of a load-balancer without being acutely aware of how the backend software works.
Architecture designed absent the programming element will inevitbly be the wrong architecture. This applies to any kind of administration and deployment. These are all under the same hood of software development.
Now, you might think that you're well enough informed that you can make appropriate decisions. The truth is that if a programming time can summarize and communicate the requirements clearly enough to an architect, they simply don't need the architect, somebody on the team can do it themselves. Architecture is not a role that requires excessive specialization.
If you still don't think this applies, then perhaps your role is more of a product manager and not an architect at all.
"Enterprise Security Architect" might be perfectly fine without writing any code.
Software architect should code because software architecture mostly expressed in code, somewhat in diagrams but never in Word or PowerPoint.
PowerPoint software architecture is dead at the moment it is created. Software architecture evolves with software, it is a progressive development in time and is never fixed. Only by keeping up with the product itself, how it is written, modularised, what tools, libraries and frameworks are used, what infrastructure components are good now and will probably not be as good in a month time - all this evolves continuously together with code.
So, it's about "Powerpoint architects"
You, know, 5yo kid can draw squares and arrows in Powerpoint, you don't need all this CS background and programming experience at all.
I see architect as a person, who, has a vision of connection between "what the system should do" (requirements) and "what the system is" (actual implementation). And it's important to keep this vision real - be able to sit next to developer and make it real, by capturing it into code (also this implementation sample will be priceless for less experienced dev team). Otherwise, there won't be guarantee that it even possible to implement all requirement with required quality and within required time.
I'm ok, that there may be person, who draw diagrams and doesn't code, but don't call this person architect - this is "product owner" - someone who provide requirement for implementation.
Good talk here on being a well-rounded architect.
thekua.com/atwork/2016/11/the-well...
*uninstalls powerpoint
I'm off to learn Clojure.
Maybe architect doesn't have to not code at all, he needs to do some coding while leaning new patterns and architects.. I can say he shouldn't tie him self to a specific programming language and be expert in it, he needs to find better solutions in almost any programming language...
I may be wrong :), I'm not an architect but like to be :D
A developer's effectiveness, particularly in the security problem domain, is dependent on familiarity with low-level details only coding can provide. Beware the architect who isn't at one with the languages that comprise his/her system.
As an old-school architect (you know, buildings and stuff) who also writes code this topic really confuses me whenever it pops up 😂