The Dirty Work for Software Architects

Last week, I spent some time in two Egyptian cities: Alexandria and Cairo. I enjoyed this a lot. The Egyptian people were very friendly and good-natured, and there were some truly fascinating sites to see. Beyond just the obvious trip to the Pyramids, I saw Greco-Roman ruins, an incredible library in Alexandria, forts constructed during the Middle Ages, etc. These cities were very much alive and had distinct and enjoyable personalities.

One thing that really struck me, on the negative side of the ledger, however, was how much garbage there was everywhere. It looked as though it was trash day for the entire city and some kind of low-grade typhoon passed through, leaving the buildings intact and scattering trash everywhere. The problem was so bad that, in the canals feeding off the Nile, the government had actually started to fill them in with dirt, stopping the flow of water to prevent local children from playing in what had essentially become open sewage.

One might chalk this up to some kind of cultural difference or something, but that didn’t seem right to me. As I made my way around, I saw shopkeepers sweeping up their floors, people scrubbing their windows, occupants picking up debris from the sidewalks. Residents clearly cared about the conditions of their surroundings. This struck me as some kind of logistical problem, and a little googling around upon my return seemed to confirm this suspicion. Apparently, since the overthrow of Mubarak, public works suffered and the programs implemented by Morsi haven’t sufficiently addressed the problem. In Egypt, more garbage is currently generated than is hauled away–to the dismay of the locals, I’d imagine.

On the long, long flight home a few days later, my mind wandered between the trip I had just experienced and the work to which I was returning. I thought about the role of architect on a project and how in some ways it’s like a role of governance. In realpolitik context such as discussed in my post about job titles, it’s like government in that the role comes with a lot of perks that people tend to take for granted, at times to the extent of forgetting what they’re really supposed to be doing. This gives rise to the classic jokes about supervision being a role that involves doing nothing.

But in a less cynical context, the role of the architect is one of vision, persuasion, balancing concerns and understanding business needs such as keeping costs down. And this is very similar to government as it’s meant to be undertaken. It’s not all slush funds, lobbyist-bought dinners, and cigars–you need to get things done. Some of that work may leave your stamp on the world (or at least the group for which you’re the architect), allowing you to tout that you introduced continuous integration or forged ahead with a new, distributed architecture. But sometimes, you just have to pick up the garbage, even when you want to build pyramids.

Architect as Trash Collector

I’ve seen a lot of different code bases and approaches over the years. Sometimes you see well curated, organized code bases being maintained by conscientious developers, but this is probably the least common scenario because it’s hard and requires training and practice. The most common scenario tends to be that a rather rotten code base is being maintained by developers whose attitudes range from checked out and indifferent to interested but frustrated. Code bases tend toward entropy, and the longer they’ve existed, often the more run-down they are. The garbage starts to pile up in the streets.

But surprisingly, I’ve found that a scenario you see more than you’d expect is one where the code base is in a sorry state but the developers are conscientious and hard working. And this is what my mind kept coming back to as I reflected on my tour through parts of Egypt–hardworking people in a frustrating and often futile struggle to be clean in an unclean world too big for them to control. The developers do their best with new code and improve legacy code when they can, following the Boy Scout rule, but improvement is slow and painful, if not at a standstill.

How would you fix this as architect? Start over with a complete, grand rewrite? Good luck with that because, if you’ll recall, one of the things that the architect should do, like the government, is understand value tradeoffs and budgets. Rewriting the software is sort of like saying, “Well, retirees, sorry, but paying your social Social Security is really dragging us down…” It’s a non-starter. Do you order some pyramids built–some introduction of an impressive, slick piece of latest and greatest framework, design pattern, or tool? Hmm… I’m reminded of Percy Shelley’s Ozymandias–terrible in your greatness and power, all that will remain of your architecture when you’re five years gone from the company is dust and the occasional, cryptic comment in the code about the great things you were going to do. “I am Ozymandias, Architect of architects–look on my code generation ye Mighty, and despair!”

Governed agencies that succeed are built on good infrastructure and logistics. Non-glamorous things like those are what governance is really all about. Building impressive, shiny things is a luxury and a thing that governments built to last only do when the lifeblood of the government is healthy and flowing and the foundation is strong. When communication fails and rubbish piles up in the streets, that has to be addressed first. So what does a good, governing architect do? Well, he rolls up his sleeves and takes out the trash.

You Have to Get Your Hands Dirty

You do drudgery clean-up. You methodically go through the code base breaking apart 1000 line methods into 200 line ones. You break those into 40 line ones and those into 5-10 line ones. You get rid of copy-paste jobs in the same way, and you add automation to your builds, tests, and process as you go. People laugh at first and think you’re crazy. They tell you that the architect should be meeting with the department heads and executives, drawing massive UML diagrams and entity-relationship models. They’re right–you have to do those things and this too. So you chip away in the hour before you leave but after everyone else has taken off. You remote in on weekends. You make progress and build sweat equity. People stop laughing at you and join you, appreciating that you work as hard as they do when you don’t have to anymore and that you’re rolling your sleeves to take the trash out. It’s infectious, and you start to fix the problems in earnest and make the infrastructure hum as improvements are noticeable.

I think that this is what an architect ought to be. You do all of the planning and technical lead work, making decisions, mentoring developers, strategizing and scheming, but you lead the way in the trenches, too. You work hard making life better for the developers on the team, ensuring their code base stays clean and easy to work with. You keep the potholes filled, the crime down, and the garbage out of the street.