Why Does Simplicity Escape Programmers?

An experiment, posted on LessWrong.com that led to a further diatribe on rationality and rational thinking traps got me thinking too.  Here’s the problem:

Once upon a time, there was an instructor who taught physics students.  One day she called them into her class, and showed them a wide, square plate of metal, next to a hot radiator.  The students each put their hand on the plate, and found the side next to the radiator cool, and the distant side warm.  And the instructor said, Why do you think this happens? Some students guessed convection of air currents, and others guessed strange metals in the plate.  They devised many creative explanations, none stooping so low as to say “I don’t know” or “This seems impossible.

And the answer was that before the students entered the room, the instructor turned the plate around.

This is Occam’s Razor at its finest.  But these unwitting physics students are no different than the average programmer out there when confronted with a bug report.  Take this example of a guy who had a strange logic error in a core Linux package:

A few weeks ago, though, I encountered some bizarre behavior on my desktop, that honestly just didn’t make sense. I spent about half an hour digging to discover what had gone wrong, and eventually determined, conclusively, that my problem was a single undetected flipped bit in RAM.

This guy admirably spent a long, painful session tracking his error to a faulty location in RAM.  But his most likely rationale for why?

For me, bitflips due to cosmic rays are one of those problems I always assumed happen to “other people”. I also assumed that even if I saw random cosmic-ray bitflips, my computer would probably just crash, and I’d never really be able to tell the difference from some random kernel bug.

Cosmic rays!  Now, the possibility exists, that’s true.  But is it the most likely explanation?  No, not by a long shot. More likely:  faulty RAM due to manufacturing defects.  More RAM failures are documented as problems than cosmic ray defects.

Why do we have some perverse belief that all our problems are exotic, unusual and outside of normal?

When you discover a bug in your code, is your response:

  1. Hmmm, I wonder what simple thing I did wrong here?
  2. I wonder if there’s a kernel bug in Linux causing that?

Simplicity isn’t just a goal in optimization, but in finding the source of bugs too.  Never let the truth interfere with a good story, I always say.

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.