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.
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.
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.
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.
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.
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.
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.
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?