Complexity Multipliers: What’s Increasing the Risk of Your Software Project


In the tech­nol­ogy world, speed to mar­ket is es­sen­tial. There’s a say­ing that “if you’re happy with your first ver­sion, you’ve waited too long to launch.” This ar­ti­cle is not in­tend­ing to out­line the im­por­tance of find­ing es­sen­tial fea­tures for a min­i­mum vi­able prod­uct through epics and users. You can read more on that here. Rather, this is aimed at out­lin­ing the type of func­tion­al­ity that will add com­plex­ity and risk dur­ing soft­ware de­vel­op­ment.

Offline Sync

A re­quire­ment that is be­com­ing less nec­es­sary, of­fline sync had to com­bat the re­al­ity that we may not be con­nected at all times. As a re­sult, cloud ap­pli­ca­tions must cache the data lo­cally and sync to the cloud server when re-con­nected to the in­ter­net. Depending on the amount of data be­ing cached and the way it is stored, this type of func­tion­al­ity can carry a sig­nif­i­cant amount of com­plex­ity and risk. It is not un­com­mon for of­fline sync alone to take 3-5 weeks of de­vel­op­ment time.

With con­nec­tiv­ity be­com­ing eas­ier and faster, there is a strong case for avoid­ing of­fline sync. Of course, this de­pends on the ap­pli­ca­tion it­self and your unique value propo­si­tion.

Third Party Integrations

Many prod­uct own­ers re­alise that when it comes to cer­tain el­e­ments, it’s bet­ter to reuse what oth­ers have al­ready done rather than re-in­vent the wheel. This is where in­te­gra­tions can play an im­por­tant role. The trade off is that in­te­grat­ing with third party ap­pli­ca­tions can carry risk and time im­pli­ca­tions. Sure, you don’t have to spend 6-12 months de­vel­op­ing a new pay­ment gate­way, but in­te­grat­ing with an ex­ist­ing one does­n’t trans­late to a 10 minute task. Again, the length of de­vel­op­ment is de­pen­dent on the gate­way it­self and the doc­u­men­ta­tion avail­able. We gen­er­ally see pay­ment in­te­gra­tions take 3-6 days.


Security is es­sen­tial for every ap­pli­ca­tion. By not­ing it as a pos­si­ble com­plex­ity mul­ti­plier I am not rec­om­mend­ing an open ap­pli­ca­tion with no se­cu­rity scheme. The point to make here is that there are con­sid­er­a­tions that will im­pact com­plex­ity and cost. For ex­am­ple a se­cu­rity scheme with 1-2 user groups is quite ba­sic (a user group is a type of user that can in­ter­act and ac­cess an ap­pli­ca­tion). Complexity grows when we start adding 5-8 dif­fer­ent user types, all with dif­fer­ent per­mis­sion lev­els. Again, this may be nec­es­sary for the ap­pli­ca­tion to work, but the re­al­ity is that it adds com­plex­ity.


Multitenancy is com­mon in many SaaS plat­forms. The im­age be­low is a vi­sual rep­re­sen­ta­tion of mul­ti­te­nancy. It al­lows for mul­ti­ple or­gan­i­sa­tions to keep sep­a­rate data­bases. It even al­lows for dif­fer­ent ‘skins’ to per­son­alise the ap­pli­ca­tion ex­pe­ri­ence at a greater level. The key ad­van­tage is sep­a­ra­tion of data and per­son­al­i­sa­tion. But the ar­chi­tec­ture of the ap­pli­ca­tion be­comes sig­nif­i­cantly more com­plex. Mulltitenancy has be­come in­creas­ingly pop­u­lar along­side a mi­croser­vices ar­chi­tec­ture.


Dynamic Reporting

Analytics and re­ports are crit­i­cal for data in­ter­ro­ga­tion. This leads to a strong de­mand for dy­namic re­port­ing. The com­plex­ity comes when com­par­ing a range of dif­fer­ent in­puts over dif­fer­ent his­tor­i­cal pe­ri­ods. There are tools like Cognos or Power BI that can sit over the top of an ap­pli­ca­tion and pro­vide the re­port­ing layer (but re­fer to third party in­te­gra­tions for com­plex­ity). My rec­om­men­da­tion is if pos­si­ble to be­gin with ba­sic re­port­ing and al­low data to be ex­ported in a CSV for­mat. This means that if more com­plex data ma­nip­u­la­tion is re­quired it can be done in an ex­ist­ing pro­gram like Microsoft Excel.


Multiple plat­forms means de­ploy­ing mul­ti­ple ver­sions of your ap­pli­ca­tion. For ex­am­ple Facebook has a web ap­pli­ca­tion that you can ac­cess through your desk­top through a Chrome browser as well as a iOS ver­sion and Android ver­sion. By cre­at­ing mul­ti­ple ver­sions of your ap­pli­ca­tion, it may ei­ther re­quire na­tive pro­gram­ming (meaning mul­ti­ple code­bases) or con­fig­u­ra­tion with a web wrap­per (like Cordova or Xamarin). Either way, this can sig­nif­i­cantly im­pact the time of de­vel­op­ment and com­plex­ity.

How WorkingMouse cap­tures com­plex­ity

In our es­ti­ma­tions process there are a num­ber of fac­tors that when com­bined, form the time es­ti­mate for each piece of func­tion­al­ity. One po­ten­tial trap that soft­ware de­vel­op­ment com­pa­nies fall into is fail­ing to cap­ture risk in their time es­ti­ma­tions. This leads to missed dead­lines and blown bud­gets. WorkingMouse’s es­ti­ma­tion process cap­tures risk through com­plex­ity and un­fa­mil­iar­ity. Some pos­si­ble ex­am­ples of what may lead to a higher com­plex­ity score have al­ready been pro­vided above.

If you’re look­ing to gauge com­plex­ity and pos­si­ble soft­ware de­vel­op­ment risks, con­tact us.

Discover Software


Yianni Stergou

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

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion