Why I don't believe in software architects

This blurs into my vision of top-notch software engineer without the fancy title, which was the reason I wrote that post in the first place.

As best as possible, I think a company should screen for that in the Interviews. (given that Interviews are sometimes a effectiveness gamble, I realize that it can be difficult to screen for that). I usually watch to see if they light up and get into conversations when I ask questions in the Interview related to our tech. If they don't get that expression and interest (hard to qualify but I think most people know what I am talking about) than that is a lot of hire points lost. If you spend an hour talking computers and they never 'light up', I feel, they are probably not the right fit.

I blame the myth that young hackers are somehow strangely more knowledgeable than their elders because of the putatively ever-changing nature of technology. I've always been suspicious of this self-serving narrative (in what other engineering field is this true?), but as I approach what passes for Old Fartness in this industry (30) now I know it's bullshit.

All the twenty-year-old whizzes I know are experts at taking something like Ruby on Rails, trading in the quality of the underlying framework to put together a hack-job very quickly, and then promptly getting themselves stuck in a morass that they can't get out of because they don't even understand why they are in a morass. Hand these people something with a lot of technical assets they can borrow against and yeah, they can toss something together fast, but that's hardly "better" then what I can do now, which is actually produce technical value.

(Mind you, I'm not saying that's necessarily a bad thing. There's a time and a place for that. What is a bad thing is that the developer won't understand the tradeoffs they just made, and probably didn't make the tradeoff after a sober and careful balancing of the costs and benefits, but did it because it's all they know.)

Anyhow, my point is that thanks to that mythology, a lot of younger people don't think they can be mentored by the old farts they think know nothing in this rapidly changing technical environments. The old farts (at least the ones who have ten years of experience and not one year of experience ten times) have learned that frankly, the tech world isn't changing that fast (different languages, different APIs, pretty much the same messes). There's plenty of mentoring to be done, but you gotta accept that the mentors are going to tell you some things that may shattered your treasured conceptions of the programming world....

As I'm saying in the neighbour thread, this was the reason why I wrote this post in the first place. Something like "hackers, don't be lured by fancy architect job, just master your own craft, this is more valuable".

It seems to me that the biggest problem is not software architecture per se, it's when you have a software architect who thinks they are automatically senior to other members of the team. Software architects are (or at least, IMHO, should be) co-ordinators, not directors/dictators.

Of course architects need to be technically strong, because they need to be working with the team leads responsible for each part of the software project. That means they need to be able to communicate effectively with those leads and understand the technical implications of what is being said.

But it's a two-way street, and both the team leads and the architects have their own role to play. The team lead needs to be more aware of the finer details going on in their area of the project. The architect doesn't need to know those things, but does need to be aware of how everything fits together. That includes knowing enough about what each individual team is doing to identify areas where something new would be useful, or where multiple teams are doing the same thing and there is redundancy that could be eliminated.

Ultimately, it's all about collaboration. A software architect who only draws diagrams and produces hundred-page design documents probably isn't very useful. A software architect who talks to business leaders to clarify the requirements, liaises between the various development teams to make sure that they collectively meet those requirements, keeps an eye on testing and on bug reports coming in from the field, and so on, is pretty much essential to building large software systems successfully IME.

(Edit: I realise that my final description there was rather broad, and has some overlap with management responsibilities. Realistically, I think a software architect is going to have an element of that as part of their role, just as team leads do within their particular areas. But both are primarily technical roles.)