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?
Top comments (24)
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.
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.
FWIW, I feel you are doing it right. I've been on both sides of this and can confirm:
I was much more effective when developers learned I could keep up with them. I (personally) distrusted anyone who wasn't current on our current technology stack and understood both the opportunities and implementation risks in the same.
I often had my developers be the primary reviewers on my designs. (E.g. invert the ivory tower. You serve them, not the other way around)
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.
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.
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.
"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.
System Architect here, I have found I am most effective when I know not just the high level, but also most of the deeper level of capabilities of the code, coding methods, systems, etc. What I don't do anymore is do the repetition necessary to go from amateur to pro. I give a wide berth for my engineers to be the professional coders/operators to solve the details and give me feedback when my knowledge pool isn't deep enough. Only some of my code is production quality and used, the rest is used to make me a better translator/listener.
In my current company developers are transforming requirements into architecture. So, this is part of the job description of us developers all, smaller features to juniors, bigger ones to seniors. Challenging requirements are going to be discussed by the team, and decisions are made in consensus, weighing arguments. Naturally, senior developers with a lot of experience have way more influence.
We don't miss dedicated architects.