How to Avoid Being the Asshole Architect

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”.

Someone's having a case of the MondaysI 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 Son, you're gonna burn for using tabs instead of spaces...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

Throw it over the wall!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.

Habit 7: Principles Are More Important Than Results

Our last installment today is about the Great Ivory Tower of Standards and Architecture.  In case you missed the previous bunch:

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Principles Are More Important Than Results

Beware the Ivory Tower

Ever work on a project where some group (or some person) in your company espouses standards above all?

“You absolutely must follow our standards to the letter.  We’ll be having daily code and design reviews, anything out of compliance will of course, be refactored to meet the corporate standards immediately”

Principles and best practices are great things to engender on a project.  A highly respected architect friend of mine said to me over and over, “It’s better to be consistent than right”.  Consistency gives predictability to people looking at code for the first time.  They learn what to expect and it reduces up-to-speed time for new developers.  It also creates mini “code templates” in your work patterns to speed things up as you develop.

You can take this too far.  Projects where standards are used like a whip are demoralizing and turn action into motion purely for the sake of consistency.  Remember:  Your goal is to ship a finished product that meets the customer’s requirements, on time and under budget.  Following standards is part of that but creating painfully complex standards and then demanding absolute adherence in this fashion is just torturing your developers.

Have standards, but keep them simple.  Standards exist to create consistency, not some absolute right-or-wrong litmus test for code.  Balance is important–shipping a product ad-hoc without any standards is a recipe for disaster during your first bug fix or maintenance release, but following each and every standard down to the comma is just wasting cycles.  Don’t err on the side of extremes either way.

In summary:

A good developer knows that there is more to development than programming.
A great developer knows that there is more to development than development.

Got a habit that I missed?  Sound out below!