Understanding Custom Software Complexity

Understanding Custom Software Complexity

When weighing options for a software solution, custom development is the most complex to compare. In addition to the different technological alternatives, there are numerous combinations of hybrid options and project plans: Should we start by developing a prototype or a complete working system? Should the most complex parts be split into a separate project? Which features should be implemented immediately versus which ones should be postponed? The complexity of these questions is often exacerbated by the fact that software is not a tangible good that is easily understood by non-practitioners.

The intention of this article is to provide insight into the effort required for custom software development (or even the configuration of existing software). Specifically, I will describe a common progression of software complexity that often translates to increased effort for each feature under development. With this information in mind, you can have a sense of what may be involved in your project and what high-level plans and solutions will work for you.

I will start from the simplest category and work to the most complex. You will immediately notice that the increase in complexity is largely the result of an increase in the number of dependencies and coordination between features. This naturally translates in a higher cost per feature. This is a typical progression of complexity that we have encountered with business software, others are also possible, however.

  • Raw data

The system needs to perform basic data management and reporting operations only. In more technical words, the system only needs basic CRUD (create, read, update and delete) abilities. This typically implies being able to manage and report upon raw data with no other automation necessary.

 

  • Life cycles and/or access control

The next step up tends to either require the management of a life cycle or the need to enforce some level of access control. For some projects where the raw data are already managed in a spreadsheet, this is the starting point. A life cycle adds states to raw data: a movie in a rental database may be in-store or rented, a document to sign may be pending or signed. This means that use cases may have pre- and post- conditions that have to be satisfied to be able to perform an action, therefore increasing complexity and the effort required for development. Different users having different access rights adds another layer of complexity, especially if these rights vary based on the specific state of the data’s life cycle.

 

  • Triggers & automation

This next step of complexity implies that certain actions completed (or not completed) by a user trigger specific behaviours, or that a specific action may be automatically performed by the system at the achievement of the pre-defined value. For example, notifications may be sent to staff, customers or other components of the system when a due date has passed. Having a system complete tasks behind-the-scenes introduces the need for more testing, specifically to make sure the triggers behave under all their possible conditions. The pre-existing user triggered functionalities may also need to account for the fact that changes have been made transparently to the system as well.

 

  • Integration with other business systems

A further layer of complexity is added when the system needs to exchange data with one or more external systems, each with their own set of rules and specific requirements. Security and access control measures become more complex as well as the intricacies of the actions that the data is required to perform internally. Consistently defining the division of responsibilities between systems becomes a new challenge as well (E.g., which system holds the authoritative record for a customer, if any)

 

  • Generic API (Application Programming Interface)

A generic API can be seen as a more formal level of integration where a system is opened to be used by other developers for their applications. This level of complexity is only required if you need to allow other businesses to integrate with your systems.  In this level of complexity the system’s components and modules are so flexible that they can be adapted and modified to accommodate the needs of different applications and users’ data needs. As a rule of thumb, as the distance between the two systems or components increases, so does the cost of the integration.

The five categories described above show a common progression of complexity in custom business software systems. As you can see, it is not only the number of features that determine the effort required to implement a system but the complexity of those features as well. With this in mind, if you are looking at ways to reduce risks or control upfront costs, there are a few options that you may wish to consider.

First, have the items of greatest complexity completed last or postponed to separate projects altogether. For example, staff can print reports and complete checks manually instead of setting up automated behind-the-scenes tasks or complex integrations between systems. Then, when this procedure has become burdensome, automation may be more cost effective. This also has the benefit of reducing project risk and helping build trust in the system since stakeholders will have a better understanding of how the system works. As we have mentioned elsewhere, “” and work your way up as need dictates from least to greatest complexity.

This also applies to situations where a new procedure is introduced. For example, we often recommend our clients who are looking at introducing a new procedure in their operations to first test it with simpler and most flexible means such as with a spreadsheets or Google apps. Once the new procedure has been refined internally to an accepted best practice, then instituting the procedure with a software system often results in a higher quality outcome with less risk. Indeed, systems become further solidified and averse to change as you go up the complexity ladder so it is best to start with the least complex step and grow from there.

Having a sense of where your company’s needs stand in the almost endless range of complexity helps not only in realistic planning but also in being in control of a process that is often perceived as mysterious and difficult to grasp. Building large and intricate systems is naturally complicated; however, that doesn’t mean that you can’t be involved in the process.

Claudia Accardi

Claudia Accardi

Claudia Accardi is a Business Analyst and Partner at Dattivo Software in London, Ontario. With a background in research, economics, and marketing she translates clients’ needs into software requirements.

More Posts

Follow Me:
LinkedIn

Share this post