Building Bad Software is Like Building a Tower
A little over a year ago, I wrote a post explaining how you can use the metaphor, “building software is like building a tower” to help you write bad software. The idea was that building something like a skyscraper requires insane amounts of planning because the actual act of building is laborious, time-consuming, and expensive, and also pretty much impossible to change once you get going. Furthermore, the real brains of the operation is required for the up-front planning, which is then done in such detail that the actual construction is a pretty straight-forward task that doesn’t require a whole lot of thinking — just following of detailed instructions and a practiced knack for skills like assembling plumbing, taping drywall joints, etc.
Software really only follows this pattern if it’s awful. If you were to describe a project you were working on by saying, “it’s important that we get everything right from the get-go because once we get started, this system is going to be so set and rigid that change is impossible,” wouldn’t you be a little alarmed and/or defeated? And what about the idea that the developer is so wildly different from the architect that they have two entirely separate vocational training paths (in the case of buildings, architectural studies versus carpentry trade school or apprenticeship). Is planning how to write software so very different than writing software?
I believe you’d be pretty hard pressed to continue to like this metaphor when you give it a lot of thought. But that hasn’t stopped the metaphor from being iconic in our industry, to the extent that it still vestigially governs roles, titles, career paths, and team behavior. Even though building software is nothing like structural construction, we continue to have a very real role/title called “Architect” that is responsible for coming up with documentation that looks suspiciously like a set of blueprints so that the lower paygrade laborers can toil away while he supervises.
Is this the best role and set of duties for the person called “architect” — the person on the team who has probably gotten to the position by being a good developer for a long time (or, more cynically, by being a mediocre and tenured Expert Beginner)? Should the result of spending years getting good at writing software be that you get to be in charge of the software by writing less of it? Are the architects of our buildings the people who are really, really good at pouring concrete and hanging drywall? Obviously not. And while we’re at it and this frayed metaphor is truly breaking down, should we even call them architects any more?
A Bit of Philosophy
I think that those of us who occupy the role or aspire to it should perhaps start striving to become post-architects or Uber-Architects. I’m borrowing this latter term from Friedrich Nietzsche, a philosopher and sporter of an awesome mustache that wrote about what he called the “Ubermensch,” which I believe translates from German to something along the lines of “over-man.” Nietzsche’s concepts in “Thus Spake Zathustra” are extremely nuanced and layered, but I’ll summarize what I took out of it when I read it and how I think it relates.
You might know Nietzsche as the philosopher who famously said, “God is dead,” and he said that in this book. I believe that this is largely interpreted as a profoundly and stridently atheist sentiment, but that interpretation is one that ignores the context of the work and his other works. He was looking at a world (he lived in Europe during the 1800s) where morality had long been a matter simply dictated by the tenets of Christianity, but also in a world where the rejection of religion was becoming increasingly common. Nietzsche wasn’t gloating over the corpse of God; he was expressing worry that a growing atheist/agnostic segment of the population would opt for nihilism in the absence of any religion and that society would become dominated by what he called something like “last man,” a rather wretched creature interested only in its own comfort and with no direction or broader purpose. He was saying, “I don’t care for your religion, but if you take it away, I’m worried that things will get a lot worse.”
From Nietzsche’s perspective, 19th century Europe was in trouble and the path forward was for mankind to become the “Ubermensch,” a version of man that was capable of supplying himself with all of the things for which religion had previously been responsible. Basically, he should do good in life because it’s good to do good rather than because he’ll be in trouble if he doesn’t. He should define his own purpose and leave his mark on the world because it’s the right thing to do and the highest calling for an individual would be to leave a mark on history for the better. In the absence of the previous and declining moral order, a new, sustainable one had to be defined, so his argument went (or at least my recollection of my reading and understanding of it).
Forget the religious angle here in a discussion of software. I’m not interested in discussing the merits of Nietzsche’s religious beliefs or lack thereof here. But I am interested in relating his perception of the world to our situation. Throughout the history of software development, our roles have been defined by this now flagging and failing metaphor of “software is like building a tower.” We’ve mimicked construction in our historical approach with lengthy and detailed planning along with the division of labor. We’ve gone so far as to borrow the titles for the roles in that line of work and appropriate them for ourselves. Your software group has to have an “architect” that will make the “blueprints” for the software. But that’s absurd and people are starting to realize it (see the growth of agile methodologies that have no equivalent at all in the construction world).
The danger then becomes what happens in the absence of that metaphor. Do we adopt improvident and cavalier approaches to software architecture, swinging the other way on the “lots of planning versus no planning” pendulum? Do we abolish the role of any kind of technical leader and make all software development groups pure democracy? Do the former architects or developers in general become “last architects,” just nihilistically banging out whatever code seems interesting or gets them out the door at 5 without worrying over the future or the needs of the business?
Emergence of the Uber-Architect
This is where the Uber-Architect comes in. The Uber-Architect deals not in blueprints and orders from on high but from leadership by example in the trenches. Uber-Architecture isn’t about web services, database technologies, N-Tiers or enterprises, but about teaching and demonstrating important fundamental concepts of the craft: abstractions, design trade-offs, and implementation patterns. Uber-Architects don’t create a bunch of rules and enforce them across large organizations for consistency’s sake, like a foreman with a clipboard overseeing hundreds of fungible laborers. They pick up the hammers and nails and work along side those workers, showing them how it’s done, building the thing together, and making those around them better until it is no longer a fungible collection of workers, but a humming, autonomous machine that’s more than the sum of its parts. They leave their mark on the group not because they’re “architect” but because it’s the right thing to do, and it’s something of which they can be proud.
So what do teams look like when all of this comes to pass? I don’t know, exactly. But I think we’re finding out. I think that we’re going to see more and more teams with flatter structures, less worried about seniority, and more buying into the agile concept of self-organizing teams. And on those teams, there is no architect because people doing a good job of building software won’t assemble into organizational structures that are ill suited to building software. On these teams, there will only be Uber-Architects, who don’t hold a position afforded to them by 15 years in with the company, but who hold a place of respect among their peers due to ability and vision, and who create design concepts that make the lives of those around them easier and the skills of those around them sharper.
If this sounds overly idealistic, perhaps it is, but that’s because I view it as a goal and something to start reaching toward. And besides, with all of the cynical posts I make about Expert Beginners and overrated people and whatnot, some starry-eyed optimism probably balances out the cosmic scales a bit.