I found my self in an interesting conversation just the other day about the commonly and oft wrongly used term for a position in Big Co. called the 'Architect' or 'Software Architect' or 'System Architect', you pick your poison. These days the term 'architect' is over assigned, over used, and overloaded to mean someone that has been in the programming or software development industries for an extended period of time. 'Architect' is being used to indicate that the individuals time 'IN' should equate to them knowing what they are doing and as such that they should be able to 'architect' a good system, or at best design a bit of software now and again from scratch. In the end, this over use and overloading of the word leads to misunderstandings and misinterpretations, and I ran into one in the form of an interesting debate question:
Should an architect also be a coder?
At first I was quick to answer this question in a simple and unequivocal manner: YES!
Then I stopped and thought about the reason for asking the question in the first place and the premise for thinking that an 'architect' should not be involved in any code base, or involved in producing any code for a given system. I then provided what I thought to be a more complete argument then simply answering yes. It went something like:
How can an organization, or any given programmer, expect to have a person or persons be responsible for helping set an over all direction for a system(s) without knowing what it is made of? As a programmer I find out what a given bit of software is made of by digging in and checking out how it is coded. I look to see what the codebase would be capable of doing, what it is resilient against, what code smells might it have - what the over all feel of the code is. I can think of no better way to help set direction and I find it difficult to see the other side which states the 'architects' like managers should not be interested nor involved in how the code is written. That they should only be interested in the high level direction - and that should be their only responsibility. I turned the counter argument in my head into something that I don't like architecture groups to do - and that is to become Ivory towers, or worse yet 'Picture-tecture" groups.
I firmly believe that architects should be involved in code... they should have coding tasks in each and every scrum/sprint/dev cycle (Insert term of choice for your company here). Only in this way can they truly understand the issues and problems and come up with creative and innovative ways to solve them. You might be able to find a unique individual out there who can just "KNOW" a system by hearing it be described - but to me that sounds more like a miracle person then someone I would care to get to know OR take any direction from.
In alot of ways I would hope that an architect would be 'OK' eating their own dog food now and again and being involved in implementing some of the things that they may have at one time put down on paper for someone in a meeting or design session. In essence I think all architects should be ok chasing items down the rabbit hole now and again. Its good for the soul, its good for development and its a spectacular sign that you have someone that is REALLY interested in understanding what they are talking about. An architect interested in a full understanding is what I want - not someone who just thinks they are the shiznit, or like Joel recently posted is an 'Architect Astronaut' or even better someone who is 100% enamored with the title of a blog post. I want to be someone who does really work and ACTUALLY helps programmers solve real problems that let them be faster, and get more done with less effort. I want to chase items down the rabbit hole once and a while - stay sharp and keep current.