Select Page

For as much as we like to imagine the world of software development as one of utter logic and reason, it’s hardly immune from unfounded and often harmful myths. These offenders are among the worst and should be avoided at all costs.

  1. More People Means Faster Development

One member of a team of programmers is pregnant, and she asks her friends for advice. The manager overhears and suggests getting three developers to help the pregnancy go “three times as fast.”

That popular programming joke shows the inherent absurdity of this myth. Having more people doesn’t always mean something gets done quicker, not least because there are certain things which can’t be sped up for what should be obvious reasons! 

What’s more, while more developers certainly won’t speed up a pregnancy, as the saying goes, “too many cooks spoil the broth.” Far from speeding things up, having more developers involved can mean having more and potentially conflicting ideas and instructions, thus slowing development.

  1. Better Tools Mean Better Results

Of all the myths on this list, this is the most understandable. After all, as tech people, we have a natural inclination to think that tech can solve our problems. That said, sci-fi aside, no amount of tech can, at present, fully counteract “the human equation.” Superior tools won’t mean superior results if the people using them give a substandard effort or are unclear as to what to do.

  1. Release Means an End to Development

Far from the end, release is often the beginning of a whole new phase of development, from patching bugs to developing add-ons to conceiving follow-up programs. In reality, development never truly ends. Such is the nature of working in the industry.

  1. Outsourcing Doesn’t Work

We tend to think we’re the best at our jobs, and that outsourcing them to others will lead to a poorer quality of work. On the one hand, that bias is understandable – we have a vested interest in choosing ourselves over outsourced labor, after all. On the other hand, outsourcing is always dependent on the quality of the team doing it. They may be terrible, or they may be terribly good – just like you and your team.

Dispel these myths and make your software development team a facts-first organization.