A common train of thought in the employed hacker’s head: I enjoy hacking; I don’t want to become a pointy-haired boss therefore I’m not going for management; I don’t want to have anything in common with suits and meetings and investors and therefore would not go for entrepreneurship; but I still want to do some career management for myself. The option that seem obvious for him is to aim for becoming a software architect. If you ever found yourself in this way of thinking, think again, for there’s no such “software architect” job that you would desire.

On the first glance this seems wrong. There are dozens of open positions in software companies bearing this title. A quick search on Amazon for “software architecture” reveals thousands of titles. But first 50 results or so are dealing with the software modeling using some higher-level description language, which is usually UML, and sometimes more exotic choices are presented like Z Notation (anyone?). There’s even a book luring the described hacker into buying it with its title: Software Design: From Programming to Architecture (it is about UML modeling, too). The only exception is the useless collection of developers’ anecdotes named 97 Things Every Software Architect Should Know (carefully cached by Google here), but I tend to think that this is the exception which supports the rule.

But wait, shouldn’t software architecture be an activity which involves dealing with software itself and not the models of it? Book authors do not think so. I guess the reason for that is the fundamental dichotomy between programmers in different companies. A former colleague of mine wrote recently a piece on that:

From what I see, a typical Java-centered company is either a J2EE enterprise or a place where they care about util.concurrent. Amusingly, this seems to be a very clear dichotomy. In both cases, there is a pile of (de facto) standard APIs and frameworks which take considerable time to master. And people who gravitate to one of the two types tend to be rather apprehensive if not ignorant of the other

“J2EE enterprises” love “outsourcing-style interview questions”:

[…] an endless stream of extremely low-level technical questions on particular technologies and APIs. RDBMS isolation levels, the servlet lifecycle, the methods on EJB home/remote interfaces, JSP scopes. A design pattern for them is always one from the GoF book or Sun J2EE patterns guidelines. Characteristically, they do not care about your design skills or code quality and really like J2EE-style

For the recruiters or book writers “software architecture” is neither an activity nor a way of thinking, it is a way of determining the job title. In their reality “software architect” is the person squeezing 3rd party code into a conceptual software model. He clearly belongs to the J2EE side of the dichotomy though might not use J2EE at all. It is a person who values dependency on someone else’s software in favor of developing it. This sort of dependency may be good, but for the demanding subject domains this is a double-edged sword (Paul Graham covers this issue with his usual bias towards Lisp in one of his essays). The reason behind all that is simple: “architect” does not write code. Mr Joe Hacker, is this the career path you were dreaming about?

A curious reader might ask: why do you proudly claim to hold this title then? Because I believe in software architecture as a way of thinking. I see this as a capacity to deal with the huge problems and significant amounts of code nip and tuck with the in-house development team. I do even know a single good book on the subject: Eric S. Raymond’s The Art of Unix Programming. Even is you never will hack Unix, this is a very valuable book to read.

What about career path then? Well, I can’t give any personal advice here except for the “avoid advertised ‘software architect’ positions”. The best company will allow you to keep writing code while expanding your area of influence wider and wider into the company products at the same time. This is what really software architecture is about.