I’ve read recently Dustin’s post “Software Architects Need Not Apply” (and in fact was very pleasantly pleased to see that JavaWorld has republished it on their site!) and I felt the subject needs a few words from me too (as always! 🙂 ).

I think Dustin made a valid point there : “those who can, code, those who can’t, architect” — and this definitely covers a certain segment of the population in the software creation industry, however, there’s a bit more to it. If your architect is worth any money, yes, he comes up with a design — but unless the managerial structure around him allows him to, he shouldn’t be able to bulldoze that through to your product, right? Of course you trust your architect (otherwise why would you hire him?) but I bet you trust your developers too, right? So while your architect’s job is to come up with a design, it’s not his job to decide whether that is the final production-ready architecture!

In other words, I feel the problem is not so much the architect being rather useless in this case (though I would argue indeed that any architect that doesn’t work close to the “metal” — hardware that, is for you and I — is not worth a dime!), but the empowering of the architect to reach this stage. It’s probably the eternal problem of the engineer-turned-manager — and we know that years of technical experience in a company doesn’t really justify “promotion” to a managerial role: it’s one thing to deal with technology, another one to deal with white boxes drawn around in PowerPoint or Visio and a totally different thing to motivate a team, drive it, and ensure you create the perfect environment for them to do what they do best: code!

I’m not here to argue the need for architects — or engineering managers and the whole middle layer around your coders — as they are needed. I expect everyone in my team to be able to design a component as well as implement it, unit test it and even make recommendations on (and help out with) integrating it; however, there isn’t to say we don’t need architects. In complex systems, it is worth having members of the team who have a high level understanding of how everything hangs together and how components interact. Quite likely you will have a lot of your developers understand that — or at least aspects of it — but you still need to designate peeps whose job is to overview all the components together as a whole. These guys will probably understand weakness of the overall system — your caching layer maybe can scale up only to a point? database getting hammered like hell? — but here’s the main point: they probably “know” these things either because they actually actively write code and get their hands into the guts of the system, or because they are constantly in touch with each team looking at code, system performance indicators etc.

These are your architects — and you want them as close to both the team and to the platform as possible such that they can make valid design/architecture decisions. Even so, when they do think they got it nailed, you (and by “you” I mean the whole infrastructure you have created in the company around them!) want that validated by the teams around those components — and not accept their proposal as a simple order to your coders to “go and just do it”!

You want to know, when your architects tell you that you need to change your database layer from a MySQL-based to an Oracle-based one, that your developers can safely say “well yeah, the effort to change all the SQL is minimal (or acceptable at least!)”, and you want to know from your sysadmins that your infrastructure can support the hardware requirements it takes to run a beast like Oracle. If your caching layer is about to get changed by your architects from an in-JVM to a centralized (memcached?) caching cluster, you want your developers to look at this proposal and hopefully not come back and say “well, actually, we are caching a lot of things we don’t need so we’re probably better off removing those than rolling out a whole caching cluster — and the code afferent to that”!

If instead, your architects just give you the standard “best practices”, on the basis that “Google does this”, “Microsoft recommends this” and so on, it’s probably time to talk to your developers — after all you are not Google (and if you are, your architects from what I heard act differently! :D) — and figure out how much of a cowboy your guys are. “Nobody gets fired for buying IBM” is a phrase from the past which no one applies anymore! Similarly, “nobody gets fired for applying best practices” is a no-go: best practices for who? It could well be that one of these “best practices” applies to your company, but is the decision to go ahead based on actually investigating — hopefully with your developers — whether this would work or not? Or is it simply the case that “oh well, I did it this way in the past for IBM, and Oracle recommends it so we must do it”? If it’s the latter, you’ve hired a cowboy — give him a coding test and guaranteed he’ll fail it — so kick him out before you find your whole platform “decorated” with best practices that actually bring your solution on its knees.

I touched earlier on in the post on the subject of developers-turned-managers — in most cases the shortest route from transforming a kick-ass coder into a cowboy manager! Same as with your architects, you want your engineering / development / production / whatever managers to be technical enough to understand what the hell your guys are working on, yet have all the other skills that your developers don’t have (and don’t really need!) — prioritizing tasks, aligning work with your roadmap, estimating work, delegating, shielding teams from the daily grind of managing a software project. There are developers who thrive on this — though the percentage is rather little, I found that most coders if they are good at this tend to stick to coding — maybe move into a team leadership role and take on more design tasks on board — however, there are those who for whatever reasons (I’m not saying that it’s the case they are rubbish at writing code :D) decide to step into management. Now, jumping ships like this from writing code to writing project plans is a tough step — so have you made sure that you have made this transition for them as smooth as possible and you are there to help them? Or is it the case now that these guys are the boss of everyone and start bullying your coders around, because they think they have raised above them? (In case you haven’t realised, they haven’t! They are there to serve your coders and not viceversa!)

So is your engineering manager conscious of his/her role? Do YOU understand their role — to take care of all the non-coding tasks for your developers so these guys can produce your state-of-the-art system? Or have you just lost a developer in the favour of a cowboy manager who now sees himself above the system and as such expects to do a bit of coding every now and then and nothing else in between — but expects otherwise all developers to bow to the floor when he pushes papers down your company’s corridors?

I’m sure there’s more than 2 types of cowboys when it comes to software — I quite likely only scratched the surface here! I just saw Dustin’s article on JavaWorld like I said and thought there’s a few things that potentially haven’t been touched upon. Guaranteed there’s about another 1,000 angles to this — but nevertheless I thought I’d bitchslap a bit more some of the typical cowboys we see occasionally when it comes to software development: you never know, someone might actually read this (apart from my mom! 🙂 lol) and dodge a couple of so-called architects out there. Remember: if they can’t code, they’re not techies 😀