Once upon a time in a previous job, I stated to my colleagues that people with high proximity to complex software delivery must know how to program. This declaration became a bit of a running joke with which I was (in good humor) teased fairly frequently. Those of you who know me outside of this website won't be surprised, you know I can be quite firmly committed to the well-being of software and the people who nurture and care for it.
But is this a hardline stance?
It's very common now in the enterprise IT sector that quite a lot of people involved in the delivery of software do not program, or (in the Pyrrhic best case) dislike programming. I have participated in quite a lot of interviews for software or IT architects (what is the difference?), and the overwhelming majority either do not and never have programmed, have taken a token Java/.Net course, or are hoping to transition out of daily programming activities. Put simply, this is irresponsible.
As one function, the architect navigates a vast sea of technology options and establishes suitability and appropriateness to the enterprise. This function cannot be carried out responsibly if the architect is not intimately connected to the technical constituents of the existing software portfolio and the people who deliver the software to this portfolio.
The larger the enterprise software portfolio grows, the easier it is to forget that it is made or broken by the lines of code we add and subtract. It's not a sin to forget this; it's easy to forget as we struggle with the exponential complexity of creating harmony in an expanding software portfolio. But as we forget that it's the lines of code that make or break, we begin to think that the skills needed to solve these portfolio-level problems are skills which are allowed to be dissociated from the skill of creating these systems in the first place.
In practise, diagrams on whiteboards do not help the software delivery function produce better software. In practise, the most highly valued ability of a streetsmart architect is the ability to sell the notion of aggressive refactoring of existing systems; the ability to free up budget for programming work which does not introduce visible new functionality. Dissociation from the lines of code leaves the architect unaware of the pressing need to make this sale, and unaware of the in-the-trenches needs of the software and those who produce it.
In practise, most architects are long gone before the codebase they were responsible for has reached a state where the quality is so poor it's considered punishment to work on it.
In practise, a good architect is hard to find, and few enterprises who need one are even aware they should be looking for one. "Surely more UML will fix this codebase?"
In theory, software architect should be a role and not a position; can we make this common practise?
And yes, it's true, I program for fun, for work, and I am available for consulting assignments.