Accountants see things in numbers. Lawyers scrutinise every word you say. Rock stars do drugs. We have a set of expectations that are sometimes stereotypical, or even unfounded, for each profession.

Although we can’t speak on behalf of accountants, lawyers and rock stars, we can for software developers. Read on for an insider’s view of how “nerdy and geeky code crunchers” really work.

Myth 1: Software development is a predictable process

When we find something difficult to understand (because it’s abstract or vague), we tend to think about it in more tangible terms.

People might think building software is similar to building a house from a plan, which is a linear process. The purpose of software development is creating something people have never seen before, especially with custom software. Hence, it is almost impossible to give 100% accurate estimates. You need to account for uncertainty, e.g. feature creep, external market factors, technology change.

For instance, Microsoft’s Windows Vista took 5 years to develop, even though it was only intended to be a minor upgrade from Windows XP.

software development myths DILBERT © 2016 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Myth 2: Adding more people will speed production up

Although we can’t see, touch or smell software, people sometimes assume a normal supply chain would apply.

Following from the first myth, people use common economics principles to manage software development projects.

The famous Brooks’ law (from The Mythical Man-Month) states software projects are “complex engineering endeavours” and it takes time for people added later to a project to become truly productive.

The purpose of software development is creating something people have never seen before

myths software development DILBERT © 2010 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Myth 3: It’s all about coding

This goes for both people hiring software developers as employees and those engaging with developers as service providers.

Having highly skilled programmers with vast experience in their trade is great, but don’t overlook other important non-tech criteria. Time management, communications skills, and a bit of commercial awareness never hurt.

About programming as a whole, people think it only requires mathematical/logical skills. In fact, software development can be an art, especially at high-level architecture. Thus, developers can experience writer’s block or moments of inspiration, just like novelists and artists.

myths software development DILBERT © 2010 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Myth 4: There is a silver bullet software development methodology

Beware of anyone who reinforces this myth. The four most common software development approaches are:

  • Waterfall: traditional sequential production flow which is more rigid but also more predictable than agile.
  • Agile: focuses on flexibility and incremental improvements by delivering functional bits as soon as they’re ready.
  • Lean: borrowed from lean manufacturing which means fast delivery, optimised efficiency with minimal waste.
  • Scrum/Kanban: specific practices within Agile rather than a methodology in themselves.

In reality, you always have to balance the triangle: time – money – functionality. That means the best way to minimise trade-offs is to apply the best bits from each methodology/practice.

myths software development DILBERT © 2007 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Myth 5: Certificates (badges) prove high quality

As with various professions, people sometimes measure credibility by the number of certificates individuals or organisations hold. This conventional way of thinking doesn’t translate very well into the software realm.

One, it might be very easy to get such certificates without having to prove proficiency.

Two, real project examples are better indicators of quality.

Three, when already excellent in their craft, developers find it hard to justify the amount of time spent on getting certified instead of doing actual work.

Myth 6: Adding extra features at any point isn’t a big deal

People equate changing a few things here and there every so often during the development process, to simply changing a few lines of code.

Too many changes could mean there was no good plan before any development started, or the reasons behind such changes are not solid.

Some questions to consider before dragging resources further:

  • User experience: Will this truly benefit end-users?
  • Technology: Will this require significant changes on an architectural level?
  • Business: Will the benefits outweigh the costs?

myths software development DILBERT © 2011 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

Myth 7: You should strive to get the most superior technology

The best technology is desirable to many, as it seems to guarantee success. But there is a risk of over-serving your customers.

If they only need a Toyota Camry, and you spend efforts developing them a Ferrari, there is no real value added after all.

To succeed, there are other factors to consider besides technology, e.g. user needs, interaction & user experience design, business return.

Myth 8: Releasing the software product means that the project has come to an end

Have you ever experienced the frustration of not being able to continue using your favourite app/software because it is no longer compatible with your device/operating system?

That means loss of potential revenue and other unrealised opportunities for the company behind the product.

Software development provides the most value when it is treated as a living project.

  • Long-term strategy: suitable roadmap should be put together in the first place
  • After-release support: consider updates as technology, the business and users evolve

Myth 9: Using common KPIs will result in better performance

This is yet another example of applying conventional business principles to manage software development.

Using the wrong KPIs to motivate programmers can hurt over the long run. For instance, measuring the amount of support tickets resolved will just result in problems being created in the first place.

You might also end up with programmers who compete instead of collaborating and helping each other grow.

We’ve also written a post about what to look for when choosing software developers here.

Software development provides the most value when it is treated as a living project.

Myth 10: Software can be bug-free

To put things in perspective, consider the rocket launching software:

  • Each software version contained 420,000 lines of code and had just one error
  • It was built by 260 people

Unless you have the scale and budget of NASA, there will be at least some bugs in your software. Ideally, those bugs would not be mission critical and could be reduced over time.

Bonus myths:

You don’t need automated testing

The cost of not doing them soon exceeds the cost of doing them. Later on, people will thank you for having already deployed built-in diligence.

You have to get it perfect in the first attempt

Lots of small regular updates to a solid foundation is better than developing a monolithic large piece of software and releasing it all at once.

Using the lean approach, it is better to get a Minimum Viable Product (MVP) out in the market, collect feedback and improve on it. After all, you don’t know what “perfect” looks like till people start using the software.


Read the next article in this series where we discuss how to increase the success rate of software development.

myths software development