Recently, I was the happy recipient of some very condescending “advice” from the architecture group of a client. The tone, quality and delivery of the information completely overwhelmed the actual message (some of which was actually relevant, and some was off in left field). This pleasant experience reminding me why the term “software architect” has come to be synonymous in some circles with “arrogant jerk who forgot what it’s like to code on a real project”.
I realized that I’ve had that exact same attitude at times and it just didn’t pay off at all. My message was probably lost in the same manner I discarded this guy’s advice in favor of sticking it to The Man and doing whatever I was going to do anyway.
All of this is counterproductive in any development project. Reflecting on the situation a bit more, I realized that there are a handful of key points that all software architects ought to remember. Dispelling the “Ivory Tower” mentality can’t be anything but positive for everyone involved. With that in mind, I bring you the
Five Minute Guide to Avoid Being the Asshole Architect (FMGTABAA):
1) Eat your own dog food
Nothing screams “Ivory Tower” like handing down some code you cobbled together to a group of developers to “figure it all out”. If you write a library to perform common validations, write up a standard test page and post it for all to use. Consider this your uber-test case. Or better yet, write an application that uses that same library and see how it works out. Find out the pain points your consumers will actually feel by becoming one of them. Anyone who hands you code they just put together in a manner they thought “would be useful” shouldn’t be trusted.
2) Standards apply to you too
It’s fun (well, maybe to some people) to put together standards documents that lay out the coding conventions, code organization, source code nomenclature, build structures, and so on. But to publish those standards and fail to hold yourself to them is the highest form of hypocrisy imaginable. If you can’t follow a standard, why would you expect anyone else to follow it too?
By applying the standards to your work, you’re also eating your own dog food in another sense. You see what will be painful for others.
3) Communicate like you are a Teacher, not a Preacher
Architects are supposed to exist as a font of knowledge and experience. Failing to share that information is pretty much against 
your core job description. But how you communicate that experience is just as important as the information itself. Think of your best teachers in school—did they ever strut at the front of the classroom and tell you how damned smart they were? Doubtful. They found ways to express their knowledge that encouraged your learning and questioning.
That condescending tone I received on the architect’s email was the ultimate turn off. Whatever valid information was being delivered in the message was completely lost because there was no mutual respect.
Power politics kills development projects quicker than baby rattlesnake poison will take out your dog.
4) Lead by example in Documentation
What’s the Number One complaint about open source projects? Lack of, or poorly written documentation. Why is that? Documentation isn’t exactly the Crystal Meth of programming. More like Sominex. No one likes doing it. Especially those that are good at writing code.
Instead of whipping development teams saying, “You need to produce better documentation”, give them a concrete example of your work. That also helps with point #3 (Communication), as well as demonstrating point #2 (Standards Apply to You) and point #1 (Eat Your Dog Food). Push development teams to achieve the standard set by your team for quality.
5) Command from the trenches, not the Ivory Tower
If one idea generated the majority of contempt for software architects, I think this was it. Somewhere along the way, the notion of architecture outside of mainstream development took hold and the notion of the Architecture Group was born.
Not once, in any company I’ve ever worked with or for, did this idea bear positive fruit for the development teams involved. Instead, these segregated groups have generated one or more of the following:
- Contempt for the architecture because the developers had no say in it
- Rejection of the framework because it was impractical to apply to the project at hand
- Blatant disregard for the standards set by architects because the architects did not have to adhere to business needs and company deadlines as a result of the delays introduced by their work
Architects should be a member of the platoon, never a visiting dignitary to the army base. Teams respect the opinion of someone who lives their daily reality side-by-side with them, not someone who hands them the Ten Commandments and walks back to their posh tent.
6) Throwing your prototype/framework/design/UML documentation into the hands of the unwashed masses is not the end of your involvement
No sane building architect would throw their blueprints over to the foreman and expect it to be built in their vision. Related to point #5, architecture teams that believe their involvement is limited to the design phase don’t really understand what it means to be architects. When a building is being built, the architect is on site during the majority of the project, overseeing the effort at a high level, ensuring that little changes are not impacting the big picture. All the while, the architect assists in solving minor problems that arise from his or her design from a practical standpoint.
In short, the architect’s involvement is continuous, not discrete.
7) Attitude may work in the military for commanding respect, but it rarely succeeds in IT
Finally, acting superior, like a know-it-all, or someone who is above listening to others, is just asking to be ignored. Don’t do it. Ever. Not even on a bad hair day.
Friends don’t let friends act like asshole architects. The respect you save may be your own.
Very good article. To bad the asshole architects I know rarely read these types of articles because they already know everything there is to know and don’t see a point.
Great post! Your FMGTABAA is just perfect, I can tell.
I was with you up to point #7.
I’m guessing the limit of your military experience is a late night with Full Metal Jacket?
You’d be surprised, should you research the subject, exactly how much effort the United States military puts into leadership training. I suggest you locate and read the Army Field Manual 6-22 on Army Leadership. That document and related documents thereto are regularly reviewed and updated by a number of experts both civilian and military. One of the most important things you might learn is that despite sharing a derogatory attitude with your audience toward a group of people, it’s ill-advised to leverage that with a snide closing remark. Certainly when that remark demonstrates ignorance on your part and does nothing other than to perpetuate a ridiculous stereotype and make you look like a hypocrite. After all, aren’t you acting superior when you belittle the training and experience of the most respected group of leaders in the world — men and women who’ve devoted their lives to leadership and service?
Thanks for your thoughtful response, Jeremy.
Indeed I have zero military training, but certainly the media has shaped my impression of military leadership as much as any civilian around. To that point, Gunnery Sergeant Hartman (R. Lee Ermey)’s role in Full Metal Jacket has become a stereotype for the drill sergeant from hell and that’s the image I’m trying to evoke here. No offense was intended to the men and women in uniform who act with honor, integrity and use their leadership skills for good, not evil.
I agree with the basic gist of what you’re saying, but there are people–many people–who will take *any* suggestion as condescending. And there are people that will smile and nod at your “brilliance”, but then ignore everything you say, often choosing to be contrary for no apparent reason.
By the way, I’m only a lowly developer and not an architect, but I find that the same principles and politics are relevant between developers, whether they are of the same experience level or not.
Jeremy,
I’m going to have to respectfully disagree with you. My work with an ex marine and an ex naval guy. They both tell me when climbing the latter in the military there are ass holes above you and smiling face below. Meaning you shit on the ones below you and take shit from the ones above. But I think the point from #7 is even though you are an Architect don’t disregard the junior because they’re a junior.
Great post. I am an architect myself but I do my best to not become an Asshole architect. 🙂
I’m an architect and according to that criteria I’m not an asshole. I agree with you wholeheartedly.
For projects to succeed there must be a partnership of developers, implementers and architects. Successful partnerships require two way communication and trust, none of which happens when an architect acts like God’s gift to mankind, insists on his way or the highway and doesn’t actively get his hands dirty with the hard work.
We also need to talk about the “asshole coder”. I totally agree with many of your observations of the “asshole architect”, but the teacher can’t teach if the student feels entitled to not learn.
There are two sides to this problem. It can’t be solved from either side alone. Developers need to take a good honest look at just how much they feel entitled to go their own way.
Somewhere along the way, agile development’s message of “self-organization” turned into “self-determination”. It wasn’t asshole architects that initiated this perversion. They certainly had a role in creating the context that can drive it, but coders give in to it far too often.
There’s more to being a student than just showing up for class, just as there’s more to being a teacher than just the flapping of the gums.
Creating learning cultures and learning organizations means recognizing some social protocols that allows it to happen, and allows the kinds of organizational structures and organizational mechanics that are naturally activate the ability for learning cultures to create productivity.
Part of these protocols is a recognition of authority – like the kind in an arts apprenticeship (whether martial arts or fine arts).
Learning organizations don’t work like contemporary American high schools where students are just doing time. Powerful, game-changing learning often comes with a good amount of “un-learning”, and un-learning is usually a lot more painful due to its counter-intuitiveness.
To unlearn, sometimes you need to force presumptions and habitual thinking into the background and just do the work dictated by a teacher so that experience creates the hole in the cognitive obstruction, allowing understanding to shine through.
When students feel entitled to only do the learning without requiring of themselves the ardors of un-learning, not much happens. Not much ever comes from one-sided efforts.
I’d like to add this:
I always get my hands dirty – from start to finish, top to bottom, in every work function of getting a product shipped. I listen to the voices around me. I consolidate the collective intelligence. But in the end, it’s my call. And ultimately, that makes it “my way or the highway”.
When leaders are indeed out of the ivory tower and into the work, they have even greater authority to set even stricter expectations. That’s a natural outcome of being able to be in the work; to know it, to do it, and to have significant fluency with it.
There are just times when I can’t afford the time for a coder to take a path that I already know is a blind alley – no matter how entitled to the exercise he feels is his right as a person. As much as this learning would be valuable, sometimes the execution of the exercise is just too costly and has to be redirected.
I’m fortunate to have instincts that I keep sharp to make these decisions with. I also have made decisions over the course of my career to stop following leaders who were no longer sharp. That’s a decision that more coders need to have the courage to make.
As the old saying goes, if you can’t change your job, then change your job.
I’m in the choir on this one and you’re the preacher. I guess I’m in class and you’re the teacher. I totally agree. I would love to drop in stories of all the bad architects I’ve coded with in the past, but the session would timeout on my browser.
Thanks. Great post.
From http://bit.ly/1IU0UC
The Non-Coding Architect
The Non-Coding Architect simply became so good at coding that he reached a spiritual coding nirvana where his mastery of code was so high, and so pure, that he had to move to another plane of coding consciousness and leave the code behind altogether. Because his code was so pure he can understand all technical problems just by reading a product announcement on the vendors’ website, watching a video and meditating. He is able to pluck the essence of the solution out of the aether, which in turn gets handed down to the unwashed developers for implementation.
Part of the problem is immediate vs. deferred gratification. A development team is in charge of the “immediate gratification” of its stakeholders. In smaller companies, this works great and agile processes ensure consistent delivery. But in larger companies, there are “deferred gratification” concerns about integration, compliance, skills transfer, etc.
Architecture groups are often set up to ensure the “deferred gratification” itch gets scratched. They are supposed to look around and say, for example, “if we use a consistent set of hardware for deployment across development teams, we can build a server farm and flexibly move apps around depending on demand.” But then the hard part comes in where they have to work with individual teams whose apps would ideally run on different hardware, or in a different configuration. It’s a local vs. global optimization problem.
You make many good points in the article. One that underlies many of them is that to be effective, developers and architects should understand the roles they are playing and cooperate to get the job done. Developers need to understand that someone needs to look across many projects and make choices that are good for the group but not necessarily for a particular project. And architects should listen well to your warnings, avoiding preaching, leading by example, keeping humble, treating their job as engineering, and ensuring the viability of their proposals.
Thank you for the interesting post. You may find my book, Just Enough Software Architecture, a refreshing change from most architecture books — in fact it uses the term “developer” throughout instead of “architect” to emphasize that architecture is an engineering task separate from job titles. Several chapters are available for download at: http://rhinoresearch.com/book.
The architect persona, as described in this post, is a product of how most engineering organizations are run. What I am hinting at here is the fact that they are frequently run by non-technical managers, even down to 5-6 person teams. An architect is frequently hired to “fix” the mess resulting from managers intersted in everything else but the code quality. Even with best intentions, a person like that has an up-hill battle to wage to make some sense within the organization. A position, meant to be technical, becomes political.
I have worked in organizations where team managers were non-technical and in organizations where team managers were true technical leads. My life of an architect was much easier in the latter, not because I did things differently, but because the overall level of frustration inside of the organization was lower and people tended to have more fun.
Having teaching proclivities and easy going personality helps but it’s not the whole story.
I don’t see much importance in publishing these advises.
It’s expected that a software architect know these as common sense.
If these were “obvious common sense”, every architect would be practicing them diligently. I clearly have a single case disproving that theory, so we can assume that they are not obvious common sense.