Fog Creek Software
Discussion Board




software architects

I remember I read a thread here about a guy who was a software architect, who claimed he was just a mediocre programmer.

Is anyone else like this, or has anyone worked with someone like this?  How do you get to be an architect?  I would assume that you would just through being a programmer and working your way up.  But if you're not really a great programmer, then you're probably not going to get promoted a lot.

I am much more interested in high level design than coding.  I imagine though in most software development (certainly at my job) that technical design and coding are done by the same people.  I guess design only becomes separate when you have huge applications like AutoCAD or MSOffice and such.

What does it take to be an architect?  It seems like personality will play a big part.  I have good communications skills but I'm not a "networking" kind of guy.  I don't make contacts or anything.  How does an architect prove that they're worth the money?  It must be hard for other management to detect what the architect is actually doing.  Wouldn't they think that all they need is a bunch of programmers, and the architect is superfluous?  Do programmers respect architects?

Andy
Friday, July 11, 2003

Architects are predomintantly under skilled middle manager types that wanted to cash in on the boom, but couldn't bear to be associated with the smelly progammer types, or god-forbid, actually work.

You become an Architect by taking an MIS course where your will learn all about software development while avoiding actually programming.  Your job consists of writing a monolothic up front design document which is entirely incomprehensible.  That's okay, because it impresses clients and bosses which is what really matters.

When your incomprehensible design inevitably fails because of your complete lack of understanding of technical issues, fault invariably falls to the lowly programmer.  If a product actually sees the light of day, primarily due to the superhuman efforts of the programmers, you will take all the credit.

All in all, a great career move.

tongue-in-cheek
Friday, July 11, 2003

The System Architects I have worked with are at the top of their class. Most have 15+ years experience on everything from mainframes to servers to the web.  They understand technology and they can tell you what is emerging and what is proven and why you should choose one over the other.  They can truly architect a system which includes choosing the right tools, languages, databases, and interfaces.  And they can explain why those are the best choices in the context of the application AND the business.

To move to Enterprise Architects they must be able to  discuss networking, programming, hardware and project management, AND business impact  in a near seamless fashion. 

From "tongue-in-cheek", I see the common misconception that because an architect also understands the business they are somehow a management wanna-be.  Instead, they are people who can actually talk about technology in a business context.  This makes them few and far between.

Mike Gamerland
Friday, July 11, 2003

Yeeesh, here we go again ….

Actually, tongue-in-cheek’s response is not really a misconception at all.  Mike appears to have been fortunate to have only worked with system architects that deserved the title. 

I’ve worked with architects ranging from the type tongue-in-cheek describes, to type that Mike describes. 

From my experience, companies/projects that employ a pure “architect” who couldn’t code at-all have failed miserably.  In the successful large-scale projects I’ve worked on, the software architect was either a highly accomplished software engineer, or there simply was no single dedicated software architect; architecture was arrived at in a collaborative manner. 

One particular dysfunctional symptom of many tech companies I’ve noticed in my career has been the conception of software architecture as some mysterious, high-and-mighty activity, while coding is conceived as lowly unskilled labor.  In reality, the analogy of architect/construction worker to software architect/ coder is a grossly flawed one that only leads to disaster. 

To answer one of the original questions, I don’t respect “software architects; the ones I've known have been charlatans.

Immature programmer
Friday, July 11, 2003

The original question was how do people become software architects. I'm going to punt on that and answer the question "how SHOULD someone become a software architect?"

I don't actually believe that being a top-notch programmer is the sole qualification. The main thing I believe a great software architct has is a deep understanding of the software construction process.

Why? Well, the measure of good architecture is that it can be built in the allotted time with the designated resources to the requirements as specified.

So if I were promoting somone to an archtect role, I would look for someone with experience as a lead developer. Not necessarily the greatest programmer, but the one with a track record for leading teams.

She would have the understanding of what can and cannot be built, and why. The smartest programmers don't always have this knack: being incredibly talented, they often have a blind spot when it comes to software construction.

JM2C

http://www.braithwaite-lee.com/

Reginald Braithwaite-Lee
Friday, July 11, 2003

Well if you have experience as a lead developer, to me that suggests that you were one of the most capable people on the team.  From my experience, the lead developers are the best programmers, as long as they have some reasonable communications skills and can take responsibility.  Well, actually let me amend that.. the lead developers tend to get things done fast, but sometimes at the expense of architecture!  I think they are the ones that take responsibility and can get stuff accomplished, which doesn't really intersect totally with the role of an architect, in my mind.

I'm not really arguing, but it seems to me that being an architect without being a great programmer is probably very hard.  It seems like it would be more common that they go hand in hand.  But I think they are two separate skills, and so there might be some good architects out there who never made it up.

Maybe it is a problem that the architects are thought of as being above the programmers.  It's just a different job.  I think Joel has written in one of his articles about program managers at Microsoft that they don't have any direct reports.  But I think the program managers mainly do feature design and specs, and not technical design.  They also have marketing responsibilities and such.

Andy
Friday, July 11, 2003

In response to Andy:

Yes, I agree that the lead developers are certainly some of the best developers. But there's always room on every team for a wizard or two who don't get the same fulfillment out of the construction and team dynamics that a lead does.

My point is that such a wizard tends to be a terrible architect, while a good lead that "gets stuff done at the expense of architecture" makes an EXCELLENT architect.

In fact, thanks for the line. When I'm interviewing, I think I'll incorporate it into my questioning. Someone who never compromises the pure, crystalline beauty of their architecture to ship software isn't going to enjoy having me implement their vision ;-)

Reginald Braithwaite-Lee
Friday, July 11, 2003

Andy,

I had asked this question a while back, and got some great responses.

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=29766&ixReplies=7

HTH,

Prakash S
Friday, July 11, 2003

Mike, thanks for the patronizing "common misconception" remark and the implication a lack of experience.  I found it very amusing.

tongue-in-cheek
Friday, July 11, 2003

I'm with Reginald.  An architect need not be the best programmer, but he does need to be uniformly above-average and above all, well-informed in the construction process.

Mike Gamerland wrote:
"They understand technology and they can tell you what is emerging and what is proven and why you should choose one over the other.  They can truly architect a system which includes choosing the right tools, languages, databases, and interfaces.  And they can explain why those are the best choices in the context of the application AND the business.

To move to Enterprise Architects they must be able to  discuss networking, programming, hardware and project management, AND business impact  in a near seamless fashion"

Heh.  Sounds a lot like being an independant contractor.  You need to be a business analyst, designer, programmer, tester, implementer, project manager and marketer, all at the same time!

Norrick
Friday, July 11, 2003

"My point is that such a wizard tends to be a terrible architect, while a good lead that "gets stuff done at the expense of architecture" makes an EXCELLENT architect.

In fact, thanks for the line. When I'm interviewing, I think I'll incorporate it into my questioning. Someone who never compromises the pure, crystalline beauty of their architecture to ship software isn't going to enjoy having me implement their vision ;-) "

Reginald, this reminds me of the saying "You don't make money by writing software - you make money by *shipping* software".

Norrick
Friday, July 11, 2003

I use to be an architect. I got there by moving up from junior programmer to lead programmer with some pretty heavy doses of project manager and development group manager. I'd like to think I was the type of architect Mike describes. I can point to a couple of projects that were very successful and also, at one point, the group I was working in had several development teams evaluated by a consultant, and my apps were the only ones that were praised and in fact didn't get heavily slammed.

I think a big part of my ability to do well was that I was narrowly focused on a particular type of moderaterly complex and difficult type of app: capital markets trading systems. I had enough experience in these types of systems that I could help drive high-level product strategy with executive business management but I could also throw down with programmers about low-level networking library details, sql issues, object modeling, etc. I know the business, I know the technology, and I know how technology is going to change the business over the next few years. (I also know how to get out of the way of good lead developers.) This is what it takes to make good decisions about tools, languages, architecture, etc.

My current gig however is much different. I manage production support for a large-scale EAI "service delivery center." This is for a very bureaucratic, heavily compartmentalized and proces-oriented company. The architects here are defintely in the tongue-in-cheek camp.  Many of them have crossed-over from other technical fields where they have advanced degrees.  Some managers just aren't wowed by a guy with B.S. and fifteen years development experience in comparison to a guy with 2 Master's degrees and a PhD, even if the degrees are in irrelevant fields like chemical engineering or something.

A big problem here is that there is no feedback loop. Architectural decisions are made based on sales brochures and not on experience. An architect can specify any bloated over-hyped technology out of some magazine and by the time it's in production he's on to some other project and no longer involved. When the system breaks because of bad design decisions, or business level support spends several man-days a day fixing orders that dropped on the floor, the architect responsible literally won't even know.

Personally, I don't buy into the idea that you can just do high-level design. Like the arms control guys say "The devil is in the details." In more specific terms, high-level design involves abstractions and abstractions are leaky. These leaks aren't apparent at the design level, they manifest themselves at implementation and operational stages, which are very low-level activities. Successful design takes these leaks into account - and it does by specifying the high-level design down to very low-levels. Thus, a good architect must span all levels. Once architects think their responsibility stops part way down the stack, then you've got the situation tongue-in-cheek describes.

Jim S.
Friday, July 11, 2003

Hm it seems like the idea of architect is not that clearly defined.  I actually didn't think that the architect is involved with business decisions, project management, and interfacing with customers.  On my team we have the "development director" for that, basically a manager who has some technical knowledge.  What I am imagining is what my team is currently lacking, basically this:

1.  Someone to specify interfaces, and to take responsibility for how things work together on the high level.  That seems to be a very important part of what an architect would do.

Basically my experience is that developers sometimes work with blinders on, caring only about their own code.  The nature of programming is that you need to be pretty detail oriented, and sometimes the forest gets lost for the trees.  Of course the best programmers can see the forest, but it is hard to assemble a team of only the best programmers.

When two developers have to interface their code, it's not always the best interface that wins.  One guy might just be louder than the other about it, or write their code first, or the other guy might be busy doing something else, so the first developer gets to specify whatever interface he wants (or usually none at all, it's just some ad hoc "interface").  Basically the idea of an architect is someone who has AUTHORITY over these issues, to resolve differences.

The interfaces are also what should be tested, which is what makes the job pretty important.  The architect should design things so they are decomposable and testable.

2.  Someone to evaluate tools and make technical decisions about them.

Right now in my project we are using an atrocious tool for some UI work, and we have thousands of man-hours of work locked in this proprietary format.  We would love to change tools, but it is too much work re-write everything.  The architect should be the one to make sure this doesn't happen.

3.  The architect is someone who shines at the BEGINNING of the project.  They are there to "see into the future" and make sound technical decisions that will avoid disaster down the road.  They will make sure the code is flexible enough to withstand spec changes.  I would say the lead engineer is the guy who shines at the END of the project.  His job is to make sure the product is shipped, make the necessary compromises, and break the architect's design.  : )

4.  Also someone who is mindful of performance.  Contrary to popular belief, I think performance can be improved more at the high level than at the low level.  One poor design decision will eat up all the cycles/memory you saved by hand-optimizing that inner loop.  The architect needs to understand memory management schemes and compiler optimizations and stuff.

5.  I don't think the architect can ever just write a huge design doc up front and then sit back.  Obviously the spec can change, first of all.  But no one is omniscient enough to be able to comprehend all parts of an unwritten program up front.  They will probably get a lot of feedback from programmers, like "this data structure is bad because we have to do this operation X times a second", and then architect should be able to say how it should be changed, so as not to adversely affect the rest of the system.

I think on many projects there is no architect, and the decisions are made as a group.  And to a large extent they should be, but I think it would be nice to have something with authority on the matter, instead of a bunch of engineers arguing counterproductively.

Is this a realistic description for anyone you know?  Or does this job not really exist except for huge projects?  If you have read "Large Scale C++ Software Design", the author Lakos definitely seems like a real architect.

And the original question was: is it possible to be a good architect while only being a mediocre programmer?  Clearly you must have been a programmer to architect.  You must understand core CS stuff like data structures, compilers, assembly language, algorithmic complexity, VERY WELL.  But I would say that they are separate skills, and the best programmer may not be the one to promote to architect.  There are some people who are a little slower, and more thoughtful, and not as productive, but might make good architects.  People who tend to think about the big picture more, people who are good with abstraction (which IMHO a lot of programmers are not).  Anyone disagree?

But it seems like architects who have not been great programmers/lead programmers aren't going to get much respect.  It seems like it would be very hard to measure their contribution.  All the stuff that they would do is not really measurable by upper management.  They would be like, "what the hell do we need this guy for, we have a lead engineer, a project manager, and a bunch of engineers".  As I said originally, the architect seems superfluous, but I would say they're not, because the consequences of not having one is what I'm experiencing now!

Andy
Friday, July 11, 2003

You might enjoy http://www.bell-labs.com/user/cope/Patterns/Process/org_structure.html

Christopher Wells
Friday, July 11, 2003

Sorry, one last thing: an architect should be responsible for all parts of the codebase.  I'm sure many people have had the experience of having some ugly, suboptimal legacy code in their app.  But it's so tangled that no one wants to touch it out of fear of breaking everything, so everyone just patches on top of it.

That kind of thing can linger for years and years in a codebase and negatively impact your product.

Andy
Friday, July 11, 2003

Andy, architect was a useful term to describe the overarching design role that very experienced and good developers would naturally fill in a project.

Since this was a prestigious title and the role added a lot of value, it has naturally been picked up by the usual range of wanna-be's.

Thus the challenge these days is to determine whether an architect is an architect by dint of capability or hierarchy climbing.

.
Friday, July 18, 2003

*  Recent Topics

*  Fog Creek Home