Top 11 Software Development Misconceptions


You’re here be­cause you’ve heard so many dif­fer­ent things about soft­ware de­vel­op­ment, and you can’t seem to find a straight an­swer. Lucky for you, we’ve writ­ten this ar­ti­cle to set the record straight. We’re go­ing to bust right open the top 11 mis­con­cep­tions of soft­ware de­vel­op­ment.

Prefer to watch or lis­ten in­stead?

Check out this video sum­mary:

Top 11 Misconceptions About Software Development from WorkingMouse on Vimeo.

#1 - Software is never re­ally ‘finished’

The truth is, soft­ware has never been a ‘set and for­get’ kind of in­vest­ment. In or­der to suc­ceed, you want your busi­ness and soft­ware to stay rel­e­vant. That’s how your users con­tinue to be sat­is­fied and en­gaged, and bring in rev­enue.

So if this is true (and it is!) soft­ware must al­ways re­ceive sup­port, es­pe­cially af­ter you launch it. Once your soft­ware hits the app store you can be­gin to gather feed­back from your users, and in turn, you can then use that in­for­ma­tion to im­prove your prod­uct. It’s the mech­a­nism in place for main­te­nance, im­prove­ment and up­keep.

Another thing we want to clear up for you is that you can never have soft­ware that is ‘bug-free’. There are so many rea­sons for this. Technological evo­lu­tions, such as a new iOS sys­tem up­date, can af­fect whether bugs ex­ist.

One of the main rea­sons why we be­lieve that soft­ware is never truly ‘finished’ comes from legacy soft­ware. Because legacy soft­ware op­er­at­ing sys­tems are out­dated and no longer sup­ported, most of these sys­tems are due for tech stack up­grades or patch­ing for newer sys­tems.

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

You might be guilty of this mis­con­cep­tion, and that’s okay. It’s nor­mal to hear when you’re new to the world of soft­ware de­vel­op­ment. 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 in­dus­try se­cret: when soft­ware is ‘simple’ or used in a sim­ple enough way, it’s ac­tu­ally any­thing but, be­cause many un­der­ly­ing com­plex­i­ties have been worked through in-depth to reach that out­come. We could write a whole other ar­ti­cle just on this topic, but put sim­ply, every soft­ware pro­ject is just so dif­fer­ent.

Here’s an­other pill that might be hard to swal­low: your users de­ter­mine if your prod­uct is good, not you!

Don’t get trapped into fo­cus­ing only on the re­quire­ments you want your soft­ware to have. Instead, fo­cus on the prob­lems you solve for your users. They are the rea­son you are cre­at­ing your soft­ware, af­ter all.

#3 - Estimations are firm

Magne Jørgensen, from the Simula Research Laboratory, has been pub­lish­ing on the topic of soft­ware es­ti­ma­tions since 1995. He found that we hu­mans have a cog­ni­tive bias and tend to be over-op­ti­mistic of the fu­ture.

Even though con­tracts are formed from es­ti­ma­tions they are still only, at best, a well ed­u­cated and sci­en­tific guess. They are a re­flec­tion of what in­for­ma­tion is known at the time. No two fea­tures or soft­ware ap­pli­ca­tions are iden­ti­cal, there­fore es­ti­ma­tions based upon his­tor­i­cal ve­loc­ity aren’t set in stone.

Multiple Factors ex­ist out­side the de­vel­op­er’s con­trol. For ex­am­ple, many sys­tems in­te­grate with Application Programming Interfaces (API’s) from third par­ties. If the API changes, so does the sys­tem re­ceiv­ing it. When one thing changes, every­thing else needs to ac­com­mo­date that change. As a pro­ject pro­gresses, de­ci­sions are made or built that in­cur tech­ni­cal debt. This debt needs to be ad­dressed in es­ti­ma­tion. This means we need to fac­tor in con­sid­er­a­tions not pre­vi­ously thought of. All of these el­e­ments mean that es­ti­ma­tions are never firm.

If a con­tract is formed from es­ti­ma­tions, they need to be vari­able, or fac­tor in enough risks to with­stand the test of a pro­jec­t’s time. You can find more in­for­ma­tion 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’ ap­pli­ca­tion

We may all be guilty of it, but un­der­selling the com­plex­ity of the soft­ware is not help­ful for any­one in­volved.

When you tell a de­vel­oper it’s sim­ple, this raises a red flag for two rea­sons:

  1. It’s never sim­ple. Even a sim­ple form has a com­pli­cated ar­chi­tec­ture and logic that is not seen by the user. This is the magic of a great user ex­pe­ri­ence. Software is process au­toma­tion. Think of any form you have ever filled out. Now imag­ine dig­i­tal­is­ing one ques­tion from that form. Are the in­puts in­te­gers, dec­i­mals or a string of text? Is it re­quired or not? Does the an­swer re­quire ad­di­tional logic? Where will the data be stored and how will it be ac­cessed or used? Simple, it is not.
  2. It shows the de­vel­oper that you don’t know this. In this in­stance, elab­o­rat­ing on the com­plex­ity will be half their job.

#5 Fixing the time and the scope will lead to a pos­i­tive out­come

Some peo­ple see fixed time and fixed scope as a way of mit­i­gat­ing their risk. They know what they’re pay­ing for and know when they’ll get it.

Unfortunately, this type of wa­ter­fall en­gage­ment rarely leads to a pos­i­tive out­come for two rea­sons.

Firstly, there are trade-off slid­ers that are true for every soft­ware pro­ject. These slid­ers show us that only two cat­e­gories are pos­si­ble at a time.

By fix­ing time and scope, you are ac­tu­ally trad­ing off on qual­ity. As soon as the pro­ject looks like it will run over time, the de­vel­op­ment agency will take short­cuts in or­der to meet the dead­line. This will have a sig­nif­i­cant im­pact on the qual­ity and us­abil­ity of the soft­ware built.

Secondly, it does­n’t al­low you to utilise feed­back gained dur­ing de­vel­op­ment. If the build takes 20 weeks and a new com­peti­tor sur­faces in week 5, there’s no op­por­tu­nity to pivot or fo­cus on what the com­peti­tor lacks.

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

#6 Building be­spoke is the best so­lu­tion for me

Now, build­ing be­spoke soft­ware is­n’t al­ways the best so­lu­tion for every­one, nor will it be ap­pro­pri­ate for every busi­ness prob­lem. Sometimes an off-the-shelf (OTS) so­lu­tion will of­fer a bet­ter fit for your busi­ness. For ex­am­ple, rather than build­ing a pay­roll sys­tem from scratch for your busi­ness, us­ing an ex­ist­ing prod­uct like Xero is quick, easy, and best of all, main­tained by some­one else.

If your bud­get is un­der $40,000, this also lends it­self to find­ing an off-the-shelf sys­tem. While it may not be a per­fect so­lu­tion, adapt­ing an OTS sys­tem, or chang­ing your process to match that sys­tem may be bet­ter than try­ing to have some­thing built and main­tained for un­der $40K.

However, if this does­n’t de­scribe you, or you’re look­ing to base your core busi­ness process around the soft­ware, then build­ing cus­tom will be a bet­ter fit.

#7 - Adding a sec­ond de­vel­oper dou­bles ve­loc­ity

This is one of the biggest mis­con­cep­tions in the soft­ware in­dus­try. Simply adding more de­vel­op­ers does­n’t mean the prod­uct is built 2 or 3 times faster.

Time is needed to align on other com­po­nents of the ap­pli­ca­tion. If Developer A builds Feature A, then Developer B needs to know how that was done in or­der to build Feature B. Our in­ves­ti­ga­tions have found that while adding a sec­ond de­vel­oper to a pro­ject does im­prove ve­loc­ity, it does not dou­ble ve­loc­ity. It im­proves it at a rate of 0.6. The im­prove­ment of ve­loc­ity then con­tin­ues to de­crease as more de­vel­op­ers are added to a pro­ject. Ever heard of the say­ing, ‘too many cooks in the kitchen’? We’ve found 2 de­vel­op­ers is the sweet spot.

#8 - Agile is undis­ci­plined

The ag­ile man­i­festo states peo­ple and in­ter­ac­tions over process and doc­u­men­ta­tion. This has led to the mis­con­cep­tion that ag­ile is undis­ci­plined, and in par­tic­u­lar, anti-doc­u­men­ta­tion and anti-plan­ning. While it is de­signed to be more fluid than the older wa­ter­fall ap­proach, ag­ile is still a dis­ci­plined frame­work.

Within an ag­ile process here are cer­e­monies and check­lists that cre­ate a frame­work for pro­jects to be de­liv­ered suc­cess­fully. For ex­am­ple, be­fore any re­lease, there is a check­list that an ap­pli­ca­tion must pass through. The use of the check­list en­sures a qual­ity as­sur­ance process has been un­der­taken be­fore any­thing is re­leased.

Similarly, cer­e­monies like plan­ning and re­view ses­sions keep all stake­hold­ers aligned and pro­vide op­por­tu­ni­ties to re­view the qual­ity of what is built.

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

#9 - Successfully de­vel­oped prod­uct = suc­cess­ful prod­uct

The next com­mon mis­con­cep­tion in the soft­ware de­vel­op­ment world is that a suc­cess­fully de­vel­oped prod­uct equals a suc­cess­ful prod­uct.

There are so many more ex­ter­nal vari­ables that go into launch­ing a suc­cess­ful prod­uct that need to be con­sid­ered in ad­di­tion to the ini­tial de­vel­op­ment. Some of these are listed be­low.

  • Custom soft­ware so­lu­tions need to be main­tained and up­dated pe­ri­od­i­cally af­ter you launch your prod­uct - this might in­clude bug fixes which, as men­tioned be­fore, can oc­cur fre­quently, or the in­clu­sion of ad­di­tional fea­tures as your busi­ness or of­fer­ings ex­pand. Consider how the apps you reg­u­larly use (I’m look­ing at you, Instagram) re­quire fre­quent up­dates to keep them func­tion­ing at their best!
  • The train­ing of staff is also in­stru­men­tal to the prod­ucts on­go­ing suc­cess. Well trained staff pro­vide bet­ter cus­tomer ser­vice and there­fore con­tribute to bet­ter out­comes.
  • Marketing, sales and le­gal sup­port also con­tribute to the on­go­ing suc­cess and longevity of your prod­uct and are out­side of de­vel­op­ment. When con­sid­er­ing cus­tom soft­ware, make sure you keep them in mind!

#10 - A web app is a web­site

This is a com­mon mis­con­cep­tion to eas­ily fall for. Essentially, the dif­fer­ence be­tween a Web Application and a web­site is that a web­site is sta­tic.

A web­site is sta­tic in­for­ma­tion pre­sented to the user. Sometimes, web­sites have cer­tain fea­tures such as forms or in­ter­ac­tive el­e­ments. These are all done on the client-side, which is what you see.

A Web App still has a client-side like a web­site, but what it shows changes de­pend­ing on its state and view.

The back­end is the data­base where the logic or code of the ap­pli­ca­tion will vary what is shown from the state or re­quested view. This is ac­cessed from the data­base in the back end. Try think­ing of it as a com­puter. The Web App’s client-side is what your com­puter shows you on the screen. The back­end is your com­put­er’s hard drive where your in­for­ma­tion is stored.

#11 - Newer is al­ways bet­ter

As you will know from the con­sumer smart­phone mar­ket, tech­nol­ogy moves fast. This can lead to a co­nun­drum when se­lect­ing a tech­nol­ogy stack. Do you choose the lat­est and great­est, or some­thing tried and tested?

In our ex­pe­ri­ence, de­vel­op­ers have itchy feet and al­ways want to try the lat­est and great­est. Whilst it’s fun to ex­per­i­ment, in our opin­ion, it should­n’t be on your pro­ject. You want some­thing mod­ern, pop­u­lar and well sup­ported.

The 2019 Developer Survey from Stack Overflow called out the fol­low­ing de­vel­oper pref­er­ences:

  • 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 tech­nolo­gies are good for a num­ber of rea­sons:

If the tech­nol­ogy is pop­u­lar, you can get peo­ple to work on it.

They have large open source com­mu­ni­ties that pro­vide fre­quent up­dates.

They’re not go­ing any­where, as they’re backed by in­dus­try lead­ers.

You want to avoid new shiny core tech­nolo­gies that may not be sup­ported in the fu­ture or be able to find peo­ple to work on.

Phew! That was a lot to get through!

If you’ve made it this far, you’re al­ready miles ahead of your com­peti­tors that are still only think­ing about build­ing their cus­tom soft­ware, and that only means one thing: you’re ready to take the next step in build­ing your cus­tom soft­ware.

Book in a free prod­uct strat­egy ses­sion (valued at $1600) here.

Discover Software


Alex Hudson

Digital all-rounder and hater of gluten

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Migration vs Rebuild

12 November 2018

The top tech­nol­ogy frame­works you can use to build a mo­bile app

21 January 2020

How does end of life soft­ware im­pact you?

10 November 2020

Your vi­sion,

our ex­per­tise