The Architect
Back in 2008 i remember being honoured by my company with the appellative of software architect.
I was pretty thrilled about my new role, although it didn’t change a thing about my daily job: coding, combining the micro-components that i need, tweaking (less and less) with the UI.
So what’s a software architect is really meant to do?
Our industry is pretty young (50ies), at least compared to other professions, like those of engineers and architects, that can be dated hundreds (if thousands) of years ago.
Indeed we have always borrowed from other professions to name ourselves: check LinkedIn and you’ll be overwhelmed by software engineers and software architects, often dressed by other flavors (like senior, solutions and, worst of all, enterprise).
The funny fact is that real engineers and architects have to deal with something concrete: the hardware. Hardware is constrained by physical rules the software is simply not subject to. The opposite is true: the software is supposed to flex, adapt and evolve with user requirements.
Nonetheless the architect is often seen as a natural career path for a software developer. An opportunity to abstract from the burden of coding and focus on big-bang drawings for the others to interpret, obsessed to build the perfect system.
To me a software architect is just a developer responsible to enforce a rigid coding discipline by maximizing the number of decisions not made, keeping the codebase simple and ready to respond to unexpected change.
Be humble and forget about high-sounding names, after all you’re just a (hopefully pretty good) programmer.