an overwhelming percentage of software developers imaginethemselves to be far above the norm – they themselves convenientlyfit that top 2% echelon, they believe
Several readers have emailed to ask how my “Optimal SoftwareDevelopment Processes and Practices” entry — which wassurprisingly well received — compared to several better-knownsoftware development guideline papers. For instance Joel Spolsky’ssuperlative “TheJoel Test: 12 Steps To Better Code“.
“Read them all and then adopt what sounds right toyou,” I replied.
To expand upon my answer a bit, my entry is a listing ofhigh-level management practices that apply to virtually any teaminvolved in virtually any type of software project. If you haveaccountable software developers; you’re focusedon solving the right problem, using the right platform, tools,and technologies (given that they’ve done the research, andthey’re not tied up having camelCase/PascalCase wars, developing aredundant GFA Basic solution for the Atari ST); you have a historyof accurate, detailed time information to draw upon forestimates and to really know the capacity of your team — whichusually indicates a grizzled, experienced management that is moreattuned with reality than is the norm; you have fulltransparency of how the project is progressing and what isgetting done; then you have a much betterprobability of success.
Yet these basics — these core fundamentals — are sadly missingfrom many software development teams.
It is, however, fairly typical of papers of this genre to lookfor something seemingly unique — some sort of hook — that’ll grabthe masses as the silver bullet. One which theycan quickly implement in their process (for instance a poorly usedand abused bug tracking application, or a hashed out daily buildscript that has been failing for months but no one has noticedbecause it has no utility, or partnering up developers in pairprogramming, or implementing code reviews, or pursuing test-driven development) and claim success. “We score a 9!Awesome!” they gloat, high fiving and then returning to thecontinuing cycle of project failures.
One common silver-bullet hook these days is the classic”only hire the best!” mantra, and I thought it worthy ofspecial mention.
“Only hire the 2% of software developers!” these advicepapers crow. “We ensure that our software is top notch byrigorously putting our interviewees through 19 interviews, byasking clever brain-teasers from How Would You Move Mount Fuji, and then by having them designand implement an embedded operating system on a whiteboard!“This is usually accompanied by a “how to spot a greatdeveloper!” listing which could better be described as”How the author would find themselves in a pile ofapplicants“.
This arrogance isn’t limited to the authors of suchsilver-bullet recommendations, though. In conversations and forumthreads discussing such a top X% recommendation, one quickly comesto realize that an overwhelming percentage of software developersimagine themselves to be far above the norm — they themselvesconveniently fit that top 2% echelon, they believe, so of coursethey agree: Let the banks and the IT shops take the other 98% (theduds), because the top 2% are too busy making webmail interfacesand bug tracking applications (as ridiculous as that sounds).
The problem with such a “only hire the best!“proclamation, however, is that it’s meaningless from the start –How do you select the top X%, given that the number of attributesof a software development team member is virtually infinite How doyou quantify prospective talent universally like this given thatwhat really matters to you varies dramatically based upon whatyou’re developing, what fit the developer will be in a team, andhow you’re going to manage them?
If you’re a poor manager and you fail to utilize a talentproperly, or if you choose the wrong talent for a particularposition, it can be an absolute disaster, or at least a non-optimalsituation.
The top 2% in one realm was the bottom 2% in the other.
To draw from personal observations, I’ve known some remarkablyintelligent developers who would absolutely storm a path of successin one type of project, in one type of role, basically designing,implementing, and delivering a remarkable project almostsingle-handedly. Yet they would wallow fruitlessly for months whenput on another project. Whether it was because they had nomotivation or passion for the new project, or that they simplycouldn’t adapt to the new requirements — which is remarkablycommon. Great developers, young and old, often have a niche wherethey are remarkably strong, outside of which they falter — theresults were the same: A great developer was being wasted on aproject that didn’t leverage their strengths, and a project had adeadweight superstar that couldn’t catch on. The top 2% in onerealm was the bottom 2% in the other.
There are many projects and situations in which John Carmack andLinus Torvalds would be complete disasters.
There are many who’ll disagree with me. “That’shogwash!” they’ll say. “I can do anything well, it’s justthat IIS is a piece of crap, and the MSDN documentation is allwrong, and Microsoft is evil, and there’s this strange behaviourwith the MSXML Library — that wouldn’t happen on Linux! — andthat really screwed up my timeline, and….“. Sure.
Of course this could be countered by claiming that the “top 2%”refers to whatever pet dogma the speaker subscribes to. “Thetop 2% writes test cases before writing code, comments all code (inRoR of course), and does their timesheets by 4:30pm everyday“.
And thus it is explainedhow every developer can claim to be the top 2%, and how everyelite-herder can claim to hire only the top 2%: They simply adaptthe meaning to describe whatever practices they adhere to, whatevertechniques they use, and their personal skillset, or by simplydescribing the candidates who made themselves available to them,and who accepted the position.
In that way we can all be #1.