Top 11 Software Development Misconceptions

BY

30 July 2021

Software Development

Technology

post-cover-image

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 for you is that you can never have software that is ‘bug-free’. There are so many reasons for this. Technological evolutions, such as a new iOS system update, can affect whether bugs exist.

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 over-optimistic of the future.

Even though contracts are formed from estimations they are still only, at best, a well educated and scientific guess. They are a reflection of what information is known at the time. No two features or software applications are identical, therefore estimations based upon historical velocity aren't set in stone.

Multiple Factors exist outside the developer’s control. For example, many systems integrate with Application Programming Interfaces (API's) from third parties. If the API changes, so does the system receiving it. When one thing changes, everything else needs to accommodate that change. As a project progresses, decisions are made or built that incur technical debt. This debt needs to be addressed in estimation. 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.

An illustration depicting the inputs and risks associated with estimations in software development

#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:

  1. 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.
  2. 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.

An illustrated table depicting the sliders for time scope and wuality being flexible or fixed

#6 Building bespoke is the best solution for me

Now, 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, rather than building a payroll system from scratch for your business, using an existing product like Xero is quick, easy, and best of all, maintained by someone else.

If your budget is under $40,000, this also lends itself to finding an off-the-shelf system. While it may not be a perfect solution, adapting an OTS system, or changing your process to match that system may be better than trying to have something built and maintained for under $40K.

However, if this doesn’t describe you, or you’re looking to base your core business process around the 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 here 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. The use of the checklist ensures a quality assurance process has been undertaken before anything is released.

Similarly, ceremonies like planning and review sessions keep all stakeholders aligned and provide opportunities to review the quality of what is built.

An illustration showing the difference between agile and waterfall methodologies - agile being cyclical and waterfall being linear

#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 products 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

This is a common misconception to easily fall for. Essentially, the difference between a Web Application and a website is that a website is static.

A website is static information presented to the user. Sometimes, websites have certain features such as forms or interactive elements. These are all done on the client-side, which is what you see.

A Web App still has a client-side like a website, but what it shows changes depending on its state and view.

The backend is the database where the logic or code of the application will vary what is shown from the state or requested view. This is accessed from the database in the back end. Try thinking of it as a computer. The Web App’s client-side is what your computer shows you on the screen. The backend is your computer's hard drive where your information is stored.

#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?

In our experience, developers have itchy feet and always want to try the latest and greatest. Whilst it's fun to experiment, in our opinion, it shouldn’t be on your project. You want something modern, popular and well supported.

The 2019 Developer Survey from Stack Overflow called out the following developer preferences:

  • 31.9% like and use C sharp
  • 56.5% like and use SQL
  • 31.3% like and use React.js
  • 10.5% like and use React Native

These technologies are good for a number of reasons:

If the technology is popular, you can get people to work on it.

They have large open source communities that provide frequent updates.

They’re not going anywhere, as they’re backed by industry leaders.

You want to avoid new shiny core technologies that may not be supported in the future or be able to find people to work on.

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.

Book in a free product strategy session (valued at $1600) here.

How we empower departments and enterprises

Government

author-thumbnail
ABOUT THE AUTHOR

Alex Hudson

Digital all-rounder and hater of gluten

squiggle

Your vision,

our expertise

Book a chat