Top 11 Software Development Misconceptions

You’re here because you’ve heard so many different things about software development, and you can’t seem to find a straight answer. Lucky for you, we’ve written this article to set the record straight. We're going to bust right open the top 11 misconceptions of software development. 

Prefer to watch or listen instead? 

Check out this video summary: 

Top 11 Misconceptions About Software Development from WorkingMouse on Vimeo. 

#1 - Software is never really ‘finished’ 

The truth is, software has never been a ‘set and forget’ kind of investment. In order to succeed, you want your business and software to stay relevant. That’s how your users continue to be satisfied and engaged, and bring in revenue. 

So if this is true (and it is!) software must always receive support, especially after you launch it. Once your software hits the app store you can begin to gather feedback from your users, and in turn, you can then use that information to improve your product. It’s the mechanism in place for maintenance, improvement and upkeep. 

Another thing we want to clear up is that you can never have software that is ‘bug-free’. Technological evolutions, such as a new iOS system update, can affect whether bugs exist. In 2024, advancements in automated testing, AI-driven bug detection, and continuous integration (CI) practices help manage software support more effectively. These tools can identify bugs earlier and streamline the support process, but software still requires regular updates and attention. 

One of the main reasons why we believe that software is never truly ‘finished’ comes from legacy software. Because legacy software operating systems are outdated and no longer supported, most of these systems are due for tech stack upgrades or patching for newer systems. 

#2 - You already know what you want to build so you can ‘just build it’ right away 

You might be guilty of this misconception, and that’s okay. It’s normal to hear when you’re new to the world of software development. So, if you’ve ever thought, “I know what I want to build, so why can’t we just build it?”, we want to let you in on an industry secret: when software is ‘simple’ or used in a simple enough way, it’s actually anything but, because many underlying complexities have been worked through in-depth to reach that outcome. We could write a whole other article just on this topic, but put simply, every software project is just so different. 

Here’s another pill that might be hard to swallow: your users determine if your product is good, not you! 

Don’t get trapped into focusing only on the requirements you want your software to have. Instead, focus on the problems you solve for your users. They are the reason you are creating your software, after all. 

#3 - Estimations are firm 

Magne Jørgensen, from the Simula Research Laboratory, has been publishing on the topic of software estimations since 1995. He found that we humans have a cognitive bias and tend to be overly optimistic about the future. 

While contracts are formed based on estimations, they are still only, at best, a well-educated and scientific guess. No two features or software applications are identical, so estimations based upon historical velocity aren’t set in stone. 

In 2024, there are more advanced AI-enhanced project management tools that use historical project data and real-time adjustments to improve estimation accuracy. However, multiple factors still exist outside the developer’s control. For example, many systems integrate with Application Programming Interfaces (APIs) from third parties. If the API changes, so does the system receiving it. As a project progresses, technical debt is incurred that needs addressing in estimations. This means we need to factor in considerations not previously thought of. All of these elements mean that estimations are never firm.  

If a contract is formed from estimations, they need to be variable or factor in enough risks to withstand the test of a project’s time. You can find more information on this in our Way of Working. 

 

#4 - It’s just a 'simple' application 

We may all be guilty of it, but underselling the complexity of the software is not helpful for anyone involved. 

When you tell a developer it’s simple, this raises a red flag for two reasons: 

It’s never simple. Even a simple form has a complicated architecture and logic that is not seen by the user. This is the magic of a great user experience. Software is process automation. Think of any form you have ever filled out. Now imagine digitalising one question from that form. Are the inputs integers, decimals or a string of text? Is it required or not? Does the answer require additional logic? Where will the data be stored and how will it be accessed or used? Simple, it is not. 

It shows the developer that you don’t know this. In this instance, elaborating on the complexity will be half their job. 

#5 Fixing the time and the scope will lead to a positive outcome 

Some people see fixed time and fixed scope as a way of mitigating their risk. They know what they’re paying for and know when they’ll get it. 

Unfortunately, this type of waterfall engagement rarely leads to a positive outcome for two reasons. 

Firstly, there are trade-off sliders that are true for every software project. These sliders show us that only two categories are possible at a time. 

By fixing time and scope, you are actually trading off on quality. As soon as the project looks like it will run over time, the development agency will take shortcuts in order to meet the deadline. This will have a significant impact on the quality and usability of the software built. 

Secondly, it doesn’t allow you to utilise feedback gained during development. If the build takes 20 weeks and a new competitor surfaces in week 5, there’s no opportunity to pivot or focus on what the competitor lacks. 

 

#6 Building bespoke is the best solution for me 

Building bespoke software isn’t always the best solution for everyone, nor will it be appropriate for every business problem. Sometimes an off-the-shelf (OTS) solution will offer a better fit for your business. For example, using an existing product like Xero for payroll is quick, easy, and maintained by someone else. 

In 2024, advancements in technology and more efficient development practices may have shifted the budget threshold for building custom solutions. While a budget under $40,000 may still suggest using an OTS system, it is possible that you might find more cost-effective custom solutions today, especially with low-code/no-code platforms gaining popularity. 

However, if you’re looking to base your core business process around software, then building custom will be a better fit. 

#7 - Adding a second developer doubles velocity 

This is one of the biggest misconceptions in the software industry. Simply adding more developers doesn’t mean the product is built 2 or 3 times faster. 

Time is needed to align on other components of the application. If Developer A builds Feature A, then Developer B needs to know how that was done in order to build Feature B. Our investigations have found that while adding a second developer to a project does improve velocity, it does not double velocity. It improves it at a rate of 0.6. The improvement of velocity then continues to decrease as more developers are added to a project. Ever heard of the saying, 'too many cooks in the kitchen'? We’ve found 2 developers is the sweet spot. 

#8 - Agile is undisciplined  

The agile manifesto states people and interactions over process and documentation. This has led to the misconception that agile is undisciplined and, in particular, anti-documentation and anti-planning. While it is designed to be more fluid than the older waterfall approach, agile is still a disciplined framework.  

Within an agile process, there are ceremonies and checklists that create a framework for projects to be delivered successfully. For example, before any release, there is a checklist that an application must pass through. This ensures a quality assurance process has been undertaken before anything is released. 
 

 

#9 - Successfully developed product = successful product 

The next common misconception in the software development world is that a successfully developed product equals a successful product. 

There are so many more external variables that go into launching a successful product that need to be considered in addition to the initial development. Some of these are listed below. 

Custom software solutions need to be maintained and updated periodically after you launch your product - this might include bug fixes which, as mentioned before, can occur frequently, or the inclusion of additional features as your business or offerings expand. Consider how the apps you regularly use (I'm looking at you, Instagram) require frequent updates to keep them functioning at their best! 

The training of staff is also instrumental to the product's ongoing success. Well-trained staff provide better customer service and therefore contribute to better outcomes. 

Marketing, sales and legal support also contribute to the ongoing success and longevity of your product and are outside of development. When considering custom software, make sure you keep them in mind! 

#10 - A web app is a website 

A common misconception is that a web app is just a website. Essentially, the difference lies in the functionality. In 2024, Progressive Web Apps (PWAs) are more prevalent, offering a seamless, app-like experience directly through the web browser. This has blurred the lines between websites and apps even further, but fundamentally, a website remains static information, while a web app changes dynamically based on the user’s interactions. 

#11 - Newer is always better 

As you will know from the consumer smartphone market, technology moves fast. This can lead to a conundrum when selecting a technology stack. Do you choose the latest and greatest, or something tried and tested? 

Developers always want to try the latest tech. However, you want something modern, popular, and well-supported. In 2024, the technology landscape has shifted, and you might find new names topping the charts in developer surveys. For instance, languages like Rust, TypeScript, and frameworks like Next.js have gained more traction. The key is to look for technologies with large open-source communities that provide frequent updates and those backed by industry leaders. 

Phew! That was a lot to get through! 

If you’ve made it this far, you’re already miles ahead of your competitors that are still only thinking about building their custom software, and that only means one thing: you’re ready to take the next step in building your custom software.