10 Myths in Software Development to Debunk Now

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.

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.

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.

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.

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?

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.

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.

Find the bonus myths here.


Stay tuned for the next article where we discuss how to increase the success rate of software development.