+972 52-548-6969
Theoretical architects
This is another response to The Daily WTF post. This time, I wanted to talk about the last part of the post, the architect reply interviews. Here is how it starts:
Note: Based on my understanding, the purpose of these low-level programming questions is to draw out the participant’s knowledge and usage of reference materials and web knowledge-base searches to derive the answers, demonstrating his approach and thought process. My role as IT Architect for the past 8.5+ years has been to focus on the bigger picture and higher-level architect and design issues that solve specific business problems, so I don’t know the answers to these specific programming questions off-hand...
At this point, I have alarms bells going all over my head. You can't be a successful architect if you don't know what is happening at the lowest levels. That is like a construction architect saying that they are not interested in validating the strength of a bridge because it impacts their "artistic sense".
I suggest that you will read the whole thing (doc format), it is interesting, in a bizarre way. I agree with the overall methodology that he uses (I had to stop to thing about how to solve the second question), but the actual result is alarming. My impression from that is Do Not Hire, Leech. Leech is a term I use for those people who can't code without hand holding and a group hug. I am willing to bet that this guy would not be able to pass the FizzBuzz test.
Here is another thing that spiked my ire, this comment to the post:
My view of the role of architect, because that is my job title, is that you do the important stuff as well as the high level stuff. The database schema is extremely important so you want to be involved with that, but the code to interface with it? Well I'd write some code so that the minions can use it as a basis for their code if they haven't done it before. Network code as well, unless you have an experienced minion you can trust. But do I want to code piles of business logic? Nope.
Sorry, that is the kind of attitude that will simply irks me to no end. The whole attitude is domineering and repulsive, but "do I want to code piles of business logic? Nope." And then expect the developers to do it? Why the hell are you writing piles of code in the first place?
I interview architects, and it really gets me that some of those guys actually think that coding is somehow beneath them. My expectation from an architect (and I should mention that I do mostly the technical verification side of it) is that they can discuss everything along the line from the high level architecture to the implementation details that can affect it. My favorite question in this regard is designing a grid, and the best interviewees were able to discuss making it fault tolerant and scalable at the high level and face issue in the Assembly.Load context.
Sorry, but if you don't code, you can't be an architect. There is not such thing as theoretical architects.
I feel better now that I let it out.
Comments
We have another word for the architect you're talking about: the "Talkitect". The "talkitect" is responsible for creating "marketecture". He/she has strong arms from all of the hand-waving.
Wow. That is stunning. I will admit that I spend most of my time applying technology at the higher levels (business strategy, framework selection, etc.) but the truth is that my favorite part of my life is open source contribution and the Design Patterns group hosted by one of development managers.
BTW, If I called one of our developers a minion, I hope they kick my ass.
David Starr
Chief Software Architect
Healthwise, Inc.
@Jimmy: +1
@Ayende:
An architect should be able to get her hands "dirty" with code. However, she need not be an alpha-developer, and need not know the bits of every method.
A brigadier is not the one that can shoot an apple from half a mile with his M-16, Basketball coach usually can't slam dunk or score a three-pointer.
100% agree - I often have the word 'Architect' somewhere in my job title, but anyone who calls themselves a software architect without the ability to do the real hands on work, shouldn't be telling others how to.
@Ken - Brigadier is equivalent to a manager position, not architect, a basketball coach is similarly equivalent to a manager position. An architect is equivalent to the term captain in your examples, and they sure as hell know their jobs and their mens jobs.
Ken,
No, they aren't, but I would refuse to hire a Basketball coach who has never played.
I don't mind the architect needing a tech lead there to help with some of the code, but the whole attitude is taking it too far.
There is a nice antipattern describing the point.
http://c2.com/cgi/wiki?ArchitectsDontCode .
As a personal experience, in Italy where I live is actually diffused the idea that if you have a degree in computer science, you should not code at all, but by default you are an architect ( or a project manager, you choose ). I think that a good architect has to program ( or at least love to ), I can't imagine myself with the program background I had 5 years ago ( C++ /MFC ) designing something for the net platform ...
I remember reading Martin Fowlers discussion on what architecture is in the PoEAA book. I thought he wrapped it up really nicely.
He boiled architecture down to being the parts of software that the expert developers consider to be most important, for a given project.
So, for business apps, most experienced developers think that persistance is important amongst other things. For a distributed spidering app, you may think that in-depth tracing and logging is highly important.
Based on this, an architect is the person who worries about the important stuff. Fowler goes on to discuss the role of the architect, which in his view does include coding, requirements etc. It's VERY hands on.
This article sums it up nicely, but it's covered in PoEAA too as far as I recall.
http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
For a Solution Architect to be effective they need to know how to implement the architecture. However an Enterprise Architect doesn't have to have a programming background. I've known several that were very effective at their job but have never written a single line of code. It's probably important to differentiate between the two.
There is something satisfying about the architect role...
You think of a design, collaborate it with developers. Then your designs get done w/o doing any code!
those were the days :P
Applause!
Wow I didnt realize this had so many diverse opinions.
In my personal experience, I've written "scaffolding code", or "interfaces" that contractors or newer guys could flesh out while I write some critical sections of the application.
The new guys like it because the interface makes for some strong requirements, and I like it, because I can start to program around it without having to wait for them.
I've worked with people that use the word "minions"... they are the sign of a toxic co-worker, everyone should be an equal in terms of respect and attention.
I couldn't more agree with Ayende.
I actually just wrote a similar rant on Technical Architects:
http://blog.dries.net/2007/08/05/technical-architects/
Today, the term architect is so overloaded that my former collegue Michel Baladi ended up opting out of the whole terminology: http://blogs.msdn.com/baladi/archive/2006/07/05/656731.aspx
Personally, I love to code, and although I also love software architecture, I shy away from any job position or role involving the work 'architect', as that typically implies that I'm not allowed to write code.
Comment preview