You Aren't Special

Jared Richardson Morrisville, North Carolina, USA

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 “special” are always behind when judged by how well they meet their software project metrics. Because they think they're special, they have a strong inclination 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 finish 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 they ever got them written.

To hear this unique group of developers tell it, there are no existing build systems that can handle their “one of a kind” requirement needs. So, they must write a new one for each new project. Instead of re-using 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.

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 in 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 towards high-quality open source or commercial tools.

The "Not invented here" syndrome derails so many great teams. Don't let it derail yours.