Fog Creek Software
Discussion Board

Hiring coders versus architects

I have two questions in one.

First of all, suppose I wanted to hire a top-notch coder for my company. This person was going to be responsible for creating patentable or similarly critical code that would drive the core business of my company. Now suppose that even though I am the architect of the system, I am not a coder at all (but a good engineer nonetheless). My question is, how can I verify that the person I'm hiring is really a good programmer if I know little about it? I can certainly verify their professionalism and high-level thinking, but is there a way for me to verify how well they know C or how elegant their coding ability is. Any ideas?

And now the other side of the coin: I am a systems architect who has experience with every type of system and who has designed several successful ones. Unfortunately, I cannot code worth a darn. In this economy, I find that companies aren't interested in architects that cannot code even though my architectural skills are top-notch. Any ideas from software people about how to break into system design jobs that are coding-centric?

Tom Fairlie
Wednesday, February 12, 2003

Are you sure you are really a good architect?  Most good architects who I've met are still at least decent coders.

Perhaps what you really aspire to is management instead of architecture.

Wednesday, February 12, 2003

flamebait's got a good point -- and,  I suspect most developers I know would have some difficulty respecting an 'architect' who could not code reasonably well.

If an architect, who organizationally seems to usually end up in charge of developers, cannot earn their respect, then that architect isn't going to be very effective.

Wednesday, February 12, 2003

"I am a systems architect who has experience with every type of system and who has designed several successful ones. Unfortunately, I cannot code worth a darn"

Uhhh ... no offense, but this sounds REALLLY bad.  None of the companies I've worked for would even consider hiring someone who claimed to be a systems architect but could not or did not want to code at all.  I know I would never want to work with such a person. 

Maybe it's personal bias; the good architects I've known over the years were also highly skilled coders.  The bad ones (meaning they had no capacity to design nor see a project through to success) were either bad coders or not coders at all.

As flamebait suggested, you are probably confusing systems architect with manager (at least I hope so).   

No offense ...
Wednesday, February 12, 2003

"Patentable code"? There is no such thing.

Patentable ideas on the other hand are not a coder's job at all, that is why there are architects.

When you hire one how do you verify that your lawyer is good? Or that your doctor is good?

An architect that can not code is like a composer that plays no instrument. (Yes, I know they exist they're called rap stars.) It is difficult to believe that what they produce is music.

I would not consider coding to be part of an architects job description. I would never consider making them code in an interview. But I also find it inconceivable that a person capable of doing the job could be unable to code.

Anonymous Coward
Wednesday, February 12, 2003

Perhaps the question could be rephrased to ask, how does an information technology support manager know if someone they are about to hire can deliver the goods?  The simple answer in my case was that the manager asked multiple programmers to talk to me.  I was able to sweet talk my way through a couple of talented people.  So the manager was left with one conclusion.  Isn't that what you want?

Thinking in Java
Wednesday, February 12, 2003

Get hold of someone you trust that *can* assess the coder's skill level and let him help during the interview. 

For the rest, do you expect the architect that designed the building you work in to be a master carpenter, plumber, mason, etc?  I suspect not.  Probably a good thing if they are familiar with those things, maybe even have a little experience to help keep it real, but that's about it.  So why's a computer systems architect that isn't a good coder such an outlandish idea?  Seems a bit myopic and immature to me.  Unfortunately, it also seems to be a fairly common prejudice among the "annointed".

flamebait jr.
Wednesday, February 12, 2003

No, it's not a "geek arrogance" thing.  I can't speak for anyone else, but my prejudice comes only from personal experience.  Software architects I've worked with who were not originally software engineers have never been competent. 

Furthermore, building architecture and software architecture is a poor and overused analogy.

No offense ...
Wednesday, February 12, 2003

Tom, you're not actually an engineer at all, in the sense relevent to this discussion - software engineering - if you can't create software. Full stop.

Must be a manager
Wednesday, February 12, 2003

Why is the building architect/software architect such a bad analogy? 

Also, one of the best architects I ever worked with was formerly an excellent electrical engineer, so maybe I'm focused on my own experience as well.  The little code he did write was horrible and naive, but the man understood "systems thinking" like no one's business and it showed in the products he was involved in.  He made it very easy for us (the people who *were* the coders) to do our jobs effectively.  I learned a lot from him.

To me, there's a big difference between being a software engineer and being a coder, too. Maybe to others there isn't, I don't know.  I do know that the earlier posts sound like the ability to code well is a chief component of determining someone's suitability for a Software Architect position.  To my mind, the measurement does not support the goal, unless by Software Architect, you mean chief hacker.

flamebait jr.
Wednesday, February 12, 2003

So if you were an architect and you have absolutely no knowlege of structure, you might think "Hey, why don't I just build all of the walls out of glass and then have them support the ceiling"

Comparison to physical architects is a pretty bad argument, I'd say.  Most people have some sort of a notion of structural engineering because otherwise, you'd end up hurting yourself quite regularly.

I guess that I'm kinda biased towards hiring somebody who is an excellent coder and an excellent designer, all in one.  But that's just me.

And, to get back to an answer, without all of the 'tude, for the first part of this, I'd say that it's often quite instructive take one thing that they claim to know and force them to break it down to brass tacks.  If they pass, they are either bright or lying.  Generally the lying can be taken care of somewhat by checking references and whatnot.

flamebait sr.
Wednesday, February 12, 2003

I think it's a bad analogy. Tomorrow I'll ask the building architect I work with who's currently a software architect.

The reason *I* think it's a poor analogy is that a building architect designs buildings to the atomic level - the blueprints for my house show where every 2x4 goes. When you design to that level, you can do the actual mechanical engineering analyses. Heck, the architect *is* a carpenter, he's just not actually pulling a saw.

Software isn't the same. A software architect won't go past the class level in design. "Implementation is left as an exercise for the reader."

I suspect if building architects stopped at the walls without doing the structural and load analyses that designing the framing requires that we'd have more buildings falling down.


Philip Janus
Wednesday, February 12, 2003


Unless you're one of the following:
1. A math genius.
2. A hardware designer.

Then sorry, there ain't no such thing as "architect" on a 2 person project.  You'll have to write your own code.

Nat Ersoz
Wednesday, February 12, 2003

As most have pointed out, if you design something, you have to be able to understand the aspects that influence your design choices. What these aspects are depends on the level of design you speak of.

Since this is about architecture, which is the highest level of design that still makes sense, consider the following about those aspects.

In software design, that is usually the technology that is available. But programming language is hardly an issue.
In mechanical design, that are usually structural qualities and limitations of materials.
In building design, that is usually human factors and structural qualities and limitations of materials.

Note that understanding what needs to be done does not equal being able to actually do it. That's why the world has specialised.
Many people benefit from doing to create understanding, but that is not a requirement.

If it were, you should consider Einstein a lousy scientist, because he is not able to prove his theories by example.
And if you think that is too far fetched, than at least wonder if people who design cars, can actually weld. And if they can't, does that make their design worthless?

Know how does that apply to software architecture? As someone else already said, it depends on the size and complexity of the project. If it is small, it would be a waste to have a seperate designer and coder.
But if it is huge, you don't want to keep everyone waiting for a designer to finish her design, while she is doing her share of coding. But more to the point, she is not dealing with code level design decisions at all, so having understanding of it would not help. And should she need it, she'd have you great coders to provide your specialist expertise.

Practical Geezer
Thursday, February 13, 2003

Seems to me that the World doesn't agree on what an Architect really is, as we have seen suggestions varying from Manager to Chief Hacker.

Someone should have the responsibility for the high level view, the requirements and the business needs. That person should be able to articulate what's important and not. He should also see the relations between the high level parts.

If that person is the Architect, I agree.

Thomas Eyde
Thursday, February 13, 2003

[Someone should have the responsibility for the high level view, the requirements and the business needs. That person should be able to articulate what's important and not. He should also see the relations between the high level parts.]

Yes, but although that person could see the big picture in terms of the domain or in terms of strategic thinking, he/she would not know that it is a bad idea to do certain things in an application. I have actually seen this. The last place I worked had an "architect" that would constantly insist on things that simply did not make sense, without first consulting any of her developers. This drives mistrust and dissent through the development team and ultimately effects the outcome of a project. If on the other hand she had acted as a good captain should and consulted her NCOs (the experienced developers on her staff) she could have avoided such situations.

I am sorry but even a building architect knows how to put a building together. Ask any architect in the world about a particular material and they will know what it is capable of and what it is not capable of. They can consult engineers, and usually have to, but nonetheless they have a VERY good understanding of the process. Could the same be said of this architect? Does he know when and when not to use a particular language or platform. Does he know all the drawbacks that go along with using a particular package? The last true software architect actually went under the title of chief scientist and he could not only drive all the projects in the company in the same strategic direction, he could also show you how, why, and when to use a particular tool to make your life easier AND most importantly he could code his butt off. Now that is an architect.

Ian Stallings
Thursday, February 13, 2003

I ran across this "Architect Also Implements" process patter a while ago.

The implication is that an architect that doesn't get his/her hands dirty isn't going to be as successful as one who does.

Note that one of the quotes is from Virtruvius, an architect who practiced 2000 years ago.  The more things change...

Thursday, February 13, 2003

You are a contractors dream come true. I assume you "architect" by using some UML tool and then giving it off to the "coder".

Thursday, February 13, 2003

Only a contractor's dream come true on hourly jobs. Nightmare come true on firm fixed price (assuming you didn't do the research to find out that's how things will be)


Philip Janus
Thursday, February 13, 2003

I mean, to be constructive, since you *are* having problems finding a job, why don't you figure out why you aren't doing so well as a coder?  Coding skills only help your architecture abilities.  Maybe you need to spend some serious time coding or something. 

flamebait sr.
Thursday, February 13, 2003

I'm glad this thread went on long enough to get at least a few interesting responses. First of all, please allow me to clarify something: I chose my words carefully to cause a debate/discussion to ensue. The truth is that I *can* code, but I'm not that good at it and I don't enjoy doing it. I designed and wrote a system completely by myself a few years back that processed more than $100M/year with only one major bug found in 2 years of constant use.

I, of course, disagree completely with the notion that one cannot architect without top-notch coding skills. Likewise, I have worked with numerous developers (a majority if you will) that have zero architectural skills. I typically have to wait until after system integration to test their code and show them the huge pile of structural errors that is invariably found.

There are parallels to other industries. I am pretty much incapable of reading music at a speed necessary to play an instrument and am not that talented at playing any particular instrument anyhow. However, I can still write music because I have the ear for it.

Writing code is much like writing a story. Anyone can do it and skill goes up with training. Unfortunately, only those with sufficient creativity, drive, and talent can create a popular novel. If you turn this analogy towards complex, comprehensive documentation then you would start to see how important "architecture" is to the overall work. If I understand how to put together documentation that is easy to read and effective to use, I don't actually have to write the text if my style guide is a good one.

Tom Fairlie
Thursday, February 13, 2003

Reading _The Inmates are Running the Asylum_ this week.  From that perspective, your problem with dealing with programmers while not being one is that we tend to be arrogant jerks, the mental equivalent of schoolyard bullies.  We categorize people, we label, we rank.  We think people who understand fork() are a superior species to those who don't.  And when it comes right down to it, we write the code, and you don't, and we all know it.  We're passive aggressive bastards who think "design spec" is a code word for "suggestion," and do things our own way anyhow, and we tend to be allowed for whatever reason to get away with it.

Not all the truth, and perhaps not entirely true, but I can recognize myself in that mirror.  How about you all?

Thursday, February 13, 2003

> I, of course, disagree completely with the notion that
> one cannot architect without top-notch coding skills.

And I, of course, disagree that "architect" can ever be used as a verb, and that even what you mean by it can be called anything but "design." Don't insult a legitimate profession and endeavor with your own professional insecurity and contrived vocabulary.

Even architects do not "architect;" they design. The elite activity you mean to make reference to is called "schematic design," or "creating a parti." It is only a tiny part of the entire building conception and realization process. If we translate your poor affinity for implementing software into poor understanding of architectural design development, building construction, or civil engineering, I can assure you that you would never earn the right to do the analogous schematic design work in that profession. Maybe software professionals are more easily duped.

Steven E. Harris
Thursday, February 13, 2003

What a lively thread!

From my professional experience, there is a fundamental problem that’s much worse than the “geek jock” mentality Alan Cooper loves to talk about in his "Inmates .." book.   

In the typical dysfunctional dilbertonian culture, productive coders regarded as lowly, unskilled labor while UML paper-pushers are regarded as elite.  Software architecture and design should be regarded as a specific task, not something mysterious, high, elite profession.  “Cool architectures” are not worth a damned without implementation.  I am not suggesting software architecture and design isn't a vital task in large-scale software projects.  I am suggesting that it is a task, not a profession separate from software engineering.  I strongly agree with Joel’s sentiments in ( 

"Steven E. Harris" seems to suggest this bizarre architecture elitism would indicate a fundamental lack of integrity in the software development industry when compared to fields like Civil engineering.  I agree completely.

And to reiterate, the building architecture/software architecture analogy is badly overused and almost always incorrectly drawn by those who insist on using it.

No offense ...
Thursday, February 13, 2003

I haven't heard a convincing argument that the building architect/software architect analogy is incongruous.  What seems to be more correct is that some folks (possibly myself included) misunderstand what a building architect does.  To my mind the analogy is sound.  Whether or not it is a useful comparison, though, seems to be debatable if there is just as much confusion about what a building architect does as there is about what the proper role of a software architect is.  There's another thread asking about that so maybe that discussion will shed some light on things....

flamebait jr.
Thursday, February 13, 2003

[I haven't heard a convincing argument that the building architect/software architect analogy is incongruous.]

How about:
"The software architect I work with who was formerly a building architect says it's a bad analogy"? [grin]

The difference between building architecture and software architecture is that a building architect has codes and standards to rely on - he is fundamentally building the structure from basic building blocks. Those blocks have to be built, but he knows exactly how they will be built: when he calls for "four inch framing" then he knows he's going to get 2x4 pine boards every eighteen inches nailed head and foot at right angles. He knows the maximum loading of such a structure, how its torsion loading will affect the building's stability in wind, etc.

A software engineer does NOT have that luxury. We don't get to identify components down to a level where we know exactly what the component will do, what its response time will be, what resources it will use, etc. In general, software architects will only define a project down to the class level. How that class is implemented is left to the coder.

If building architects worked like software architects, they would sketch house designs just showing general exterior appearance and interior layout, but the implementation would be left to the carpenter.

So (IMHO) the work/design division in software is much more evenly distributed and the lines are much fuzzier than they are in building architecture.


Philip Janus
Thursday, February 13, 2003

Okay, I'll grant that the building architect has to deal with a lot less variability in his work and that he has a much broader set of tools to bring to bear on the problems he is tasked with solving.  What is not clear to me is that the inputs and outputs of the two jobs are all that different.  Each one is responsible for producing a design subject to a set of qualitative and quantitative constraints.  Each one has to evaluate many solutions to achieve a balanced design that meets all of the critical constraints and trades off non-critical ones that cannot be satisfied simultaneously.  Each one needs to understand the basic components available for the design in terms of their observable salient properties (though not necessarily how these components are built) and how these components may be made to relate to each other.  Each one deals with issues of scale, design rules, materials, forces, constraints, budgets, relationships, and so on.  To me, the endeavors seem fundamentally similar - only the tactics are different.

Like I said earlier, though, a lot of this may just depend on my understanding and expectations for each role.

flamebait jr.
Thursday, February 13, 2003

>>  In the typical dysfunctional dilbertonian culture, productive coders regarded as lowly, unskilled labor while UML paper-pushers are regarded as elite.

Tell me about it.

I contracted for a period of time at a Big Blue Company, at the tail end of its rise and the beginning of the end of its self protective, narcissistic beemer culture - late 1980s.

Our team was developing a complex shop floor integration project that had components hosted in real mode DOS.

I remember the beemer managers and the "architect" wringing their hands in befuddlement that the DOS software crashed and locked up all the time.

The attitude of the company people appeared to be that architecture guaranteed execution, that the thought process of anointed great minds assured that we servile contractor code monkeys would inexorably develop a rock solid system.

It (the product)  was a pile of steaming rubblish that customers soundly rejected once released. Because - *all* the company's emphasis was on architecture and "system". Real life considerations such the non-protected memory OS not providing a 'sieve' for invalid memory accesses were beneath consideration by the high and mighty lotus eating management.

I *do* think there's a place for non coding architects in most projects. However, the tendency of the "pure" architect is to be extremely intellectually self indulgent about the complexity that they shove down to the "mere coders".  If someone only "designs" classes or systems without doing some of the coding that results from those design decisions, they tend to become less than honest with themselves about the viability of their designs.

I've also witnessed similar intellectual vanity biases "against" so called "mere" application developers, who in many companies are accorded less than zero respect because what they *do* is a (sneer) application.

Bored Bystander
Thursday, February 13, 2003

Sorry guys, an Architect who isn't a good coder isn't worth the paper his contract is printed on.  How in the world are you supposed to design a system when you don't even know if its possible to do it that way.  I've come into projects where the "Architect" designed a database layout and a reporting tool.
Well, his great design (and it wasn't bad from the standpoint) took forever to finish. I had to do some hard thinking to figure out how to get it down to under 20 seconds.  (it took nine hours). 
  I don't care how good of an architect you are, your going to make mistakes like this.  First of all, your not going to be able to write and implement test cases to see if your superior architecture actually works. 

Sorry guys, but its time to think about doing something else.  Why in the world woudl someone hire an architect who can't code, when there are plenty who can?

Vincent Marquez
Thursday, February 13, 2003

The "Architect" in Building and software are 2 different things, its like comparing apples and oranges...

How can an architect who does not code, come up with good estimates, etc??

Agree with you on this Vincent.

Prakash S
Thursday, February 13, 2003

I think at least some of these postings seem to have missed my point and perhaps it is partially my fault. I never meant to imply that design is some elite art that feeds the base coding function. On the contrary, I consider coding to be highly important and of equal value to a good architecture.

However, many of your observations about the "architects who are worthless without coding skills" are equal to my frustrations about coders without architecture skills. I continually strive to learn about new coding technologies and read about best coding practices whenever I can. This doesn't improve my coding ability (which, as I have said, is dormant), but it does give me a more legitimate idea of what can and can't be done (i.e., developed).

By the same token, I continually see "senior" developers writing code that is seemingly meant to exist in a vacuum without any real-world event handling or even a minor attempt at reusability. This is far too common and my original question in this thread centered around how to avoid this. In other words, should I simply interview them based upon their architectural skills or is there some way to actually learn or get a feel for the quality of their code and code design. Perhaps this was already answered when someone suggested that I "borrow" a trusted friend for the interview. I am still hoping for some better insight.

Tom Fairlie
Thursday, February 13, 2003

>> my original question in this thread centered around how to avoid this. In other words, should I simply interview them based upon their architectural skills or is there some way to actually learn or get a feel for the quality of their code and code design

Tom, you've raised a really good issue, and you've been a very good sport considering some of the hard nosed geek abuse you've endured in this thread.

Some "hard core" developers can develop an incredible degree or tunnel vision and can decide on their own that nothing except their "pwecious" little program, subroutine or class is the alpha and omega of the project.  They can be super-sharp and yet leave useless modules and chaos in their wake because all they care about is what they themselves are coding at the moment...

A few years ago I worked on a distributed system based on CORBA (remote object broker) and the developers involved in coding the interface only seemed to be concerned with the maximum amount of academic purity of their work, and screw when or how it would get done. I remember arguing with some developer about some silly trivial data type convention for almost two hours, and it amounted to NOTHING... CHOOSE ONE OR THE OTHER AND GET ON WITH IT.

To answer your question - I would ask the developer to describe the most complex system that he's developed or played a key role in, and I'd ask him to relate the portions that he was responsible for to the *business goals* of the end user. IE - I wouldn't stop at the technology interface alone - I would want to see if this person could describe the system top down and bottom up and defend his role in it.

This kind of interview must be conducted  in addition to assessing the person's coding expertise as a separate topic, because one can run into really lame developers who excel at cultivating an air of exceptional "systems guy" imagery while having no clue how to write "Hello, World".

Bored Bystander
Friday, February 14, 2003

A few observations:

Some question how you can design something if you don't know if it can be built. The question is valid, the answer is not necessarily "having done it before". That might be one way of acquiring understanding, but certainly not the only one.
By that definition you can only design what you've built before.

Some question how you can provide good estimates if you don't code. Well, usually you can't. But that's why you have and consult people who do code.

Some take their worst experience with a chief designer who did not code and then point out all the things that go wrong and conclude it can't be done. Not a very good argument.

Some pick a very specific piece of knowledge that you can only acquire through repeated coding, then assign that knowledge to be the responsibility of the chief designer, and then conclude that you have to code to be a chief designer. Circular logic.

No-one seems to wonder why you might or might not need a chief designer who doesn't code. Or what skills you need on a project and who they require different views and knowledge. And who they can be best represented in the same, or different, people based on their nature, and of the project's nature.

In fact, most seem to reduce product development (system, or single programme) to technical solution. Apparently most of you are technical people and some have suggested that you define your world by what you know. No wonder you insist that you have to understand fork() to be able to analyse a problem.

Think of it, before you implement a solution, you have to choose between valid solutions. Before you can, you have to identify valid solutions. To do that, you have to understand the problem domain. That you do by analysing the people or system that use it and the goals they are trying to achieve.
It depends on the product and the organisation which balance this requires between understanding and doing. So therefore, it depends on your situation whether it makes sense to have different specialists for these activities.
But it does certainly not mean that if your situation does not call for it, or that your people can't combine skills, that no situation ever does and noone ever can.

The world will not suddenly become all nails just because you happen to own this great hammer.

Practical Geezer
Friday, February 14, 2003

Just to make sure, I used "you" in the general sense. Not to point to any one specific poster in this thread.

Practical Geezer
Friday, February 14, 2003

Tom, you do bring up a good point that some developers are too focused on their minor module or class, and don't see the big picture.  These are low level developers.  Perhaps the debate has to do with definition of "architect". I'm picturing someone who outlines the data model, decides how they will interact, how your objects will relate, specificly what technologies will be used (CMP vs. BMP for EJBs, Messaging vs. Web Services, Form Controls vs. HTML) and even how they will be coded.
  For someone to do this who has never implemented these themselves...well, thats straight out of a bad dilbert cartoon.  Now, I understand if you meant "i'm an OK coder, certainly not great compared to the guys on my team", but if you don't even know how to interview a coder, good luck.  If you can't even evaluate a coder, how can you even tell yourself your a decent developer?  Perhaps your "architect" postion is more what I would call an "inward facing" Project Manager. 

Vincent Marquez
Friday, February 14, 2003

Well, you will have to accept the possibility you may hire the wrong person, and might have to start again.

While I think it's correct to treat it as unlikely that you're a good architect without coding, it's still a matter of probability and you very well may be a good architect.  Not a profound issue, but one of statistics.

One litmus test is if your interviewee can explain something to you, for example if you give a basic architecture and ask how it could be implemented; if this person can explain how it could be done and answer your doubts, this could be feasible.

Also, while you can make a good architecture, you might not be able to know the hidden limits of things.  So you could posit that you have an architecture where a company's salesman travels the least distance...  Does the interviewee mention possible problems and ways to relax the requirements to do this reasonably?

Friday, February 14, 2003

I think Bored and Tj have raised the most salient points. I think by asking candidates to describe systems they have developed, plus how they would react to a sample architecture (perhaps purposely flawed or skewed), I can gain a more complete idea of their thinking process.

I used a similar tactic when I hired people for a senior technical support position. I gave them real world problems that I had already solved and then changed the requirements to make the solution undesirable. The best candidate? A former lawyer with only 18 months of technical experience who had earned an MCSE only a few months before. Other candidates had much more experience, but this gentleman laid out his entire thought process in front of me and I could clearly see that this was someone with the aptitude and the drive to solve tough problems.

I continue to take at least some offense from people who believe that I cannot be an architect. Let me be more clear. I took undergrad CS courses and later earned an MS in CS. I understand how to code and have written programs in at least 6 languages. I also understand data modeling and database performance and once modeled a complex data feed so well that a $175/hour consultant didn't want to help me because he would have had to work too hard to earn his money. I have been working with all kinds of computers for 20 years and have seen a lot of things.

My skills (don't we all have these) happen to be (a) seeing the big picture very clearly, and (b) dealing with customers and effectively boiling down their pie in the sky wishes to detailed requirements. I can do this well because I have built systems from scratch and understand the tradeoffs of different methodologies and technologies. I can design Use Cases and UML models, but I *don't* care to specify implementations because that is *development's* job (except user interfaces--never let a developer design the user interface :-). I am also willing to work with them and alter requirements as necessary to simplify or facilitate their work.

I will further defend this delineation [that coders want to make] by pointing out that those developers who complain "I don't code" probably cannot "architect". In fact, the type of person I want to hire probably is someone who can do both. However, I do *not* need another person like myself who has given up coding. Rather, I need someone who enjoys it.

Tom Fairlie
Friday, February 14, 2003

Another obvious tool to use in your interviewing is to sound out the candidate's references. 

management candidate
Friday, February 14, 2003

Tom, from what you described your job position as, I still don't think your what I consider an architect, although you definatly sound like the ultimate project manager.  Your last post clarified a lot of things, and it sounds like you'd be a great guy to have lead a development team.  If you re-read your first post though, I think you'll see why so many people gasped and thought "oh no, another one of THESE guys".   

Vincent Marquez
Friday, February 14, 2003

Vincent, I am not sure why anyone would think "oh, no" although I can guess why. Software developers, like many other kinds of engineers, have a terrific ego that keeps them from seeing the light even though it does keep them motivated. I suffer from this as well, but try to keep it in check because business always suffers when someone believes that only they know "the truth".

In the end, I wish I would have received a reply to my second original question. I guess developers are either too caught up in the project at hand or too convinced that they can do it all to even consider that someone else might have better ideas. Too bad actually.

Tom Fairlie
Saturday, February 15, 2003


On "oh no" reaction - Most of us with any seniority at all have suffered through a software development project or two that was specified into the ground by an 'architect' wanna be that didn't understand that he was (a) asking for the undoable and/or impossible and who (b) was unaccountable for the success or the failure of the implementation. 

I think it's a standard reaction based on the premise that the implementors are about to get another dose of 'leadership' shoved down their throats, without accountability or demonstrated expertise.

I'm not saying this applies to you. I'm stating how the "architect" title sounds to most hands on developers. This ties into the point below...

And, since developers posting to online threads are notoriously bad at jumping to conclusions and making sure not to read (myself included at times):

>> In this economy, I find that companies aren't interested in architects that cannot code even though my architectural skills are top-notch. Any ideas from software people about how to break into system design jobs that are coding-centric?

What I've found is pretty much what you say. I have worked as a software contractor for the last decade. I find that most clients won't even pay knowingly to have a simple narrative written describing the work to be done.  If you talk about 'discovery' their attention wanders and they go to the next heads down dweeb.

The attitude of the people writing the checks in most businesses is that all that counts is delivery, and process leading up to delivery is superfluous and not to be acknowledged in any way.  It doesn't matter if this actually costs them more, we're talking about a battle founded upon ignorance. Even getting paid properly for the number of hours it requires to implement something is challenged by the path of greatest resistance.

So, asking short sighted business people to pay someone to essentially "think about coding" is far fetched when far more 'pragmatic sounding' efforts often go unfunded. 

If I were you (or anyone else that had an accompanying 'high level thinker' title applied to one's name) I would distance myself from architecture as much as possible and associate myself as much as possible with deliverable systems.

Bored Bystander
Saturday, February 15, 2003

Thanks Bored for a well-reasoned response.

Tom Fairlie
Saturday, February 15, 2003

You are welcome, Tom.

Something else occurred to me. This industry NEEDS architects very badly. Geeks working in industry are generally akin to the builders of the tower of Babel - often found milling around and not understanding the greater goal to be accomplished, refusing to speak anyone's language but their own.

But - bona fide architects - who pull things together, who develop the  unifying principles of systems, who allocate tasks and delegate responsibilities based upon technical requirements which, once satisfied, lead to solutions- often get absolutely no respect from the "money" people nor entrepreneurs. I sometimes think that this is a characteristic of the sort of personality that gravitates to management positions - they are impatient with abstractions because they don't see a direct connection between process and fulfillment of their immediate business goals. Wealth and power create a ham handed stupidity and blindness.

Basically, in order to "be" an architect in this industry, you *have* to operate in 'stealth' mode. Act "down and dirty" and blue collar proletarian as your masters demand with their checkbooks, but do what it takes behind the scenes to make things actually happen.

It sounds pretty discouraging, laid out like that. Unfortunately, it's our lot.

Bored Bystander
Saturday, February 15, 2003


The reason you got such a negative response is simple: You said you can't code. Not that coding isn't your strongest skill, or that you can code but don't enjoy it as much as design, or even that you won't code becuse you hate it. You said you *can't* code.

I'm pretty sure that there aren't too many buuilding-architects out there who would admit to not being able to use a hammer.

I have personally encountered many 'architects' who said much the same thing as you did, but with a sense of pride. They were *proud* of the fact that they didn't know (and didn't care) about the difference between compiled and interpreted languages, for example.  Even worse, they couldn't understand that HTTP is a stateless protocol, and the consequent implications for the web-based architecture they were designing. I'm not talking about particularly abstruse technical concepts here, just the 'hammer and nail' basics. And, of course, they proceeded to specify in great detail exactly what methodologies, languages, toolkits, and libraries we needed to use, based their decisions entirely on marketing literature.

Now, based on your subsequent postings, it's clear that you (a) actually *can* code, and (b) that you did not intend to make a statment that seemed to denigrate coding as 'mere implementation'. But I and apparently (based on their responses) others pictured you saying those words with a smug sneer on your face.

Now, prejudices are an interesting thing. It's one way in which we apply our experiences, both individually and collectively, but (as the negative connotations indicate) they are most often misapplied, and can become self-fulfilling prophecies of the worst sort.

Thank you for sticking it out in this discussion, and perhaps we all won't be *quite* so quick to dismiss the next architect we encounter, at least until they've actually proven themselves to be a menace.

*But*, I think you have merely proven the point that a good architect must be able (on some level) to code, even if that isn't their best skill.

Since you *can* code, I'm somewhat unclear as to what special insight you think you're lacking. If the person you're evaluating seems to have the right skills (especially skill-acquiring skills), and their personality and working habits will mesh well with yours, the only thing that remains to be seen is whether they work out in practice as well as you expect. A probationary period should suffice.

Long-term productivity isn't something you (or someone with magic coder mojo) will be able to ascertain in an interview anyway, although a coder *might* be better able to discern bullshit when they hear it. The most important thing about this prospective hire is how well they work with you. Not *anything* else. The most brilliant coder will be useless to you if you can't work with them.

Michael Bernstein
Tuesday, March 4, 2003

*  Recent Topics

*  Fog Creek Home