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.
