Software Development Standards – Subjective Rights and Wrongs

Way back in junior high I had a good friend who was ahuge fan of military aircraft.

His bedroom walls were covered with huge, hard to procure andoften expensive posters of these deadly devices. His desk featuredan actual (albeit non-functional) 20mm shell, of the variety usedin the depleted-uranium spewing gatling gun.

His favourite military fighter jet happened to be the F-15 Eagle.

Feeling a little left out, I started pouring over hisresources, carefully reading his encyclopedia’s offighter aircraft, absorbing all of their attributes. I decidedthat my favourite fighter jet was the F-14 Tomcat: Clearly itsability to land on carriers, its swing-wing engineering, and thelong range phoenix missiles it supported, made it the superioraircraft.

There was no way the F-15 Eagle compared, I argued. The F-14Tomcat was obviously the choice of those in the know. Theenlightened ones, if you will.

Yet the reality — and I think my friend Brian always knew it –is that I chose the F-14 primarily because it wasn’t theF-15. After picking a natural alternative, I started buildinglayers and layers of justifications for my decision.

I see the same sort of thing fairly typically in softwaredevelopment: Big up front design versus agile designs;Getters/Setters versus fields; namespace naming guidelines of typeA or type B; variable naming standards; stored procedure namingstandards (or the religious “stored procedure versus dynamic SQL”argument that rages on in teams across the lands); the sorts oftypes to use for primary keys; the languages and platforms tochoose; whether or not to use XML, and what to use it for.

So many times, it seems, people choose their positions based noton actual analysis and honest beliefs, but rather because they’recountering someone else in their team — especially when attemptingto undermine authority, actual or perceived — or theybattling someone else in their organization (that dastardly team inSector G that’s trying to get kudos by setting the developmentguidelines!), or they’re deriding someone in the industry.

Often They’re just trying to be different anddifficult, and the beauty of software development is thatthere are many, many right ways to do it, and it’s easy to findallies in discussion groups to assure one that everyone elseis idiots, and their new position is the One True Way.

It’s easy to appeal to authority, given that there’s some bigname or organization that, in some form, promotes just about everysoftware development practice and standard imaginable (Microsoft isa particularly good example of this, as throughout the organizationthey follow so many standards and practices, that one can easilyfind an example conforming with their dogma, using it as an examplethat it’s the “Microsoft way”,  ignoring the manyexceptions).

Of course all of this doesn’t preclude disagreement on standardsand processes and techniques — people often truly disagree becausethey legitimately and rationally believe something different. In afull of intelligent, self-directed professionals, such disparatebeliefs and conclusions can be enormously beneficial. The problemis when interpersonal issues materialize as technicaldisagreements.