Complexity Multipliers: What’s Raising Software Project Risk
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. 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.
.png)
