Uber-Architects: The Building Metaphor Is Dead

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.

Nietzsche

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.

  • Allen Conway

    I really like your thought process on this topic. I certainly have used the building metaphor previously, and in the same breath speak to ‘scalable and flexible’ software. I suppose a bit of an oxymoron as you point out in the article.
    Obviously, I think we gravitate toward metaphors to explain to those that don’t build software as a means to help them ‘see the light’. Maybe I should start using Play-dough as the metaphor! :)
    Nice article!

  • Mark

    I actually think the construction metaphor is ok, but you’ve made the wrong parallels.

    Writing software is actually writing a spec… A spec for the compiler (or interpreter). So a developer writing code is analogous to the architect devising blueprints; the actual “building” is all automated by the computer and over in minutes or even seconds. Software has an advantage over construction in that most programs don’t risk lives if they have flaws, and rebuilding is cheap: so iteration is practical most of the time. It’s also often far more complex than most buildings, so flaws are to be expected in early iterations

  • http://www.daedtech.com/blog Erik Dietrich

    Play-dough would be an interesting metaphor — I’d be curious to hear more about that line of thought. The metaphors are definitely important, particularly for explanations to people that don’t really understand what we do. And, the building metaphor can help with spot explanations — I just think we’ve relied to heavily on it and believed it a little too much among ourselves.

  • http://www.daedtech.com/blog Erik Dietrich

    This is along the lines of what Uncle Bob said and I referred to in my earlier post on this subject. I’d definitely say it’s a better metaphor, but it doesn’t line up with how we’ve defined things over the years, and that’s the construction metaphor to which I’m referring (but not defining — just citing).

    What I mean is, if we say that the compiler is the equivalent of laborers and the developer is the equivalent of an architect, writing the source code/blueprint, then the job role/title “architect” that we have defined as an industry would really be more like “urban planner” or “city council.” But the industry hasn’t made the parallels that you’re suggesting and the result has been a lot of awkward fumbling to make “blueprints” (design documents) for how we’re going to make the real blueprints (source code). And that is really what I’m suggesting we get away from — using the wrong parallels to dictate how we work and even to create actual roles and titles at companies.

  • Jordan Whiteley

    The best metaphor I’ve ever heard for this is that of a commander and an angry hoard of barbarians (weird I know, but follow this for a bit)

    You need a commander (architect, scrum master, ITO, ect…) who is well versed in how battles are fought, to draw out the general shape of the battle. Basically to mark the targets and draw out a general game plan of when what needs to get attacked first. He will then direct the hoard of barbarians to the conflict.

    When barbarians are faced with a conflict a Champion emerges to lead the charge. Say you have someone with artistic vision and you’re faced with putting together the UI, chances are he’s going to step up and lead the charge, and the others will follow his lead. When the database needs to be tackled your most talented DBA should step up, and the guy with artistic vision should meld back into the angry hoard. Back in the hoard the artistic one can get a first hand perspective of how a DBA in his element does battle and vice versa. The whole time your angry hoard is ever growing stronger.

    It is then the commanders duty to recognize his champions and to make sure that they are not just the most loud / most opinionated / most expert beginner. Also make sure that they have what they need and that they’re not leading their team off the battle field. This often entails having a commander that has been in every trench, and knows that no plan survives first contact with the enemy.

    For some reason the idea of a commander directing arbitrary champions who lead loosely organized mobs around really hits home to me when I think about how difficult projects get finished.

  • http://www.daedtech.com/blog Erik Dietrich

    I really like this metaphor because it focuses on the team members and not the eventual product. When you build a building, there is a planning time, and then that ends, and that’s basically it until something breaks or you paint a room or something. Software that works this way is rare and getting rarer — but the roving barbarian hoard is constantly in a state of war, so there’s always work to be done.

    I’m always game for analogies, comparisons and metaphors, so I love these kinds of thought exercises. It’d be interesting to use this as a pay model for organizations — reward emergent champions but only retroactively and if they lead the group in the right direction. Something like that, anyway.

  • Danni Efraim

    I agree that the building metaphor just doesn’t work. However, I still see the need for someone in that seat doing something roughly along the lines of what the architect’s role today is. You can keep calling him the architect, or you can choose to call him the coordinator, senior developer, product responsible, or whatever floats your boat. Because there is definitely a need for someone with a bird’s eye view of the product, who can make sure that development efforts are coordinated and consistent, and make use of each other.

    If someone for instance has need of new functionality somewhere inside the product, this person should be able to say “this already exists here, see if you can use it” or “check with team X, because they’ve just started working on something along those lines – maybe you can benefit from their work or coordinate your efforts with them”. He should be responsible to see that different parts of the product are consistent – they should as far as possible use the same basic technologies, patterns, tools and development principles, because that makes it a lot easier for people to move around in the code and between different roles and teams in the company as well. All of this also makes sure that as the product grows, it’s not as likely to grow completely out of control (which as we all know is a very real risk).

    And in my opinion, this is often the role filled by the person designated as ‘architect’ today.

  • Danni Efraim

    (Oh, and also – thank you for a really, really good and interesting blog. I just found it today and it went straight into my Feedly feed.)

  • http://www.daedtech.com/blog Erik Dietrich

    This role that you describe I tend to think of as “advocate for the code” in its best light. In my experience, most organizations have architects with two principle responsibilities with regards to the code base: planning/dictating vision and advocate for the code. In this post, I was kind of driving at doing away with the former, “dictator” role. I could certainly see room for the advocacy to stay.
    It seems like it’d be less of a status symbol this way, and more of a position for someone who really just enjoyed cataloging code and had a head for it.

    (Glad you’re enjoying the blog — thanks for the follow :D )

  • Pingback: Uber-Architects: The Building Metaphor Is Dead | DaedTech | Backfill for 'Note to Self'()