In the technology world, speed to market is essential. There's a saying that "if you're happy with your first version, you've waited too long to launch." This article is not intending to outline the importance of finding essential features for a minimum viable product through epics and users. You can read more on that here. Rather, this is aimed at outlining the type of functionality that will add complexity and risk during software development.

Offline Sync

A requirement that is becoming less necessary, offline sync had to combat the reality that we may not be connected at all times. As a result, cloud applications must cache the data locally and sync to the cloud server when re-connected to the internet. Depending on the amount of data being cached and the way it is stored, this type of functionality can carry a significant amount of complexity and risk. It is not uncommon for offline sync alone to take 3-5 weeks of development time.

With connectivity becoming easier and faster, there is a strong case for avoiding offline sync. Of course, this depends on the application itself and your unique value proposition.

Third Party Integrations

Many product owners realise that when it comes to certain elements, it's better to reuse what others have already done rather than re-invent the wheel. This is where integrations can play an important role. The trade off is that integrating with third party applications can carry risk and time implications. Sure, you don't have to spend 6-12 months developing a new payment gateway, but integrating with an existing one doesn't translate to a 10 minute task. Again, the length of development is dependent on the gateway itself and the documentation available. We generally see payment integrations take 3-6 days.

Security

Security is essential for every application. By noting it as a possible complexity multiplier I am not recommending an open application with no security scheme. The point to make here is that there are considerations that will impact complexity and cost. For example a security scheme with 1-2 user groups is quite basic (a user group is a type of user that can interact and access an application). Complexity grows when we start adding 5-8 different user types, all with different permission levels. Again, this may be necessary for the application to work, but the reality is that it adds complexity.

Multitenancy

Multitenancy is common in many SaaS platforms. The image below is a visual representation of multitenancy. It allows for multiple organisations to keep separate databases. It even allows for different 'skins' to personalise the application experience at a greater level. The key advantage is separation of data and personalisation. But the architecture of the application becomes significantly more complex. Mulltitenancy has become increasingly popular alongside a microservices architecture.

Dynamic Reporting

Analytics and reports are critical for data interrogation. This leads to a strong demand for dynamic reporting. The complexity comes when comparing a range of different inputs over different historical periods. There are tools like Cognos or Power BI that can sit over the top of an application and provide the reporting layer (but refer to third party integrations for complexity). My recommendation is if possible to begin with basic reporting and allow data to be exported in a CSV format. This means that if more complex data manipulation is required it can be done in an existing program like Microsoft Excel.

Multi-Platform

Multiple platforms means deploying multiple versions of your application. For example Facebook has a web application that you can access through your desktop through a Chrome browser as well as a iOS version and Android version. By creating multiple versions of your application, it may either require native programming (meaning multiple codebases) or configuration with a web wrapper (like Cordova or Xamarin). Either way, this can significantly impact the time of development and complexity.

How WorkingMouse captures complexity

In our estimations process there are a number of factors that when combined, form the time estimate for each piece of functionality. One potential trap that software development companies fall into is failing to capture risk in their time estimations. This leads to missed deadlines and blown budgets. WorkingMouse's estimation process captures risk through complexity and unfamiliarity. Some possible examples of what may lead to a higher complexity score have already been provided above.

If you're looking to gauge complexity and possible software development risks, contact us.