You Aren’t Special

梦里梦外; 2022-08-09 02:23 11阅读 0赞

## You Aren’t Special ##

Jared Richardson Morrisville, North Carolina, U.S.

REMEMBER WhAT yoUR MoM TolD yoU? “You’re special! You’re unique!” Right, just like every other boy or girl who had a mom! Believing that loving lie leads to common software project problems.  
I coach many different teams. Without fail, the teams who believe they’re “spe- cial” are always behind when judged by how well they meet their software project metrics. Because they think they’re special, they have a strong inclina- tion to reinvent everything. They think, “No other team could have possibly developed usable software, or at least not as outstanding as what we create among ourselves.” Instead of learning from the mistakes of other developer teams, they insist on making their own mistakes. Over and over and over. At company expense.  
They spend so much time rewriting, debugging, and putting their own twist on software and tools\* that are already industry standard that they never fin- ish customer projects. The ones they should sell to people for money. Those mythical, magical products that would be as special as the team, if only it ever got them written.  
To hear this unique group of developers tell it, there are no existing build sys- tems that can handle their “one of a kind” requirements. So, they must write a new one for each new project. Instead of reusing an existing object-database mapping tool, they write their own. Web application framework? We can do that, they profess. Continuous integration? Check. Testing harnesses? Let’s write those, too. The vainest and most disillusioned of them will even attempt to write their own programming languages.  
\* Tools: Simple programs that software developers use to create, debug, test, analyze, track, or other- wise support quality software development.  
  
So how do these teams spend their day? Solving the problems they’ve created by substituting the untested code they built themselves for the fully functional software tools usually available to them for free. When they write their own database layer, they spend the days tracking down obscure performance bugs and caching issues. Handling the edge cases† ends up consuming more time than they ever would have spent learning, or even modifying, existing tools.  
The reason less “special” (but more successful) teams use existing tools is because the problems they’re setting out to solve are hard problems. They need reliable tools so their attention is focused on the solution to their software project, not on trying to refill an already brimming toolbox.  
What does this have to do with effective software project management? Don’t let your programmers reinvent the wheel. When they come to you explaining how special their problems are, point out that their mothers may have stretched things when they made that “you’re special” assessment. Be knowledgeable about what’s available and guide your team toward high-quality open source or commercial tools.  
The “not invented here” syndrome derails so many great teams. Don’t let it derail yours.