The Difference Between Complex and Complicated Software + Download Estimation Sheet

When delving into software development and management, the distinction between 'complex' and 'complicated' software is crucial. Both terms may seem similar but refer to significantly different aspects of software dynamics.

Why these differences are important? Because making the distinction between the two helps to make better impact and effort analyses. Software engineering is a craft - that can be based on clear rules, principles, guardrails and criteria to make it more rationalized and standardized practice leading to more control during the realization of the software product and eventually to better software.

Let's explore these differences a bit more in depth, focusing particularly on the internal versus external factors influencing software systems. At the end of this article I will introduce a smart but simple spreadsheet (including a download link so you can get the template) that will help you to make better software development estimates, taking into consideration the internal complexity and external complications that play a role for the software you want to develop.

"Controlling complexity is the essence of computer programming" (Brian Kernighan)

Understanding Complexity in Software

Complexity in software refers to the internal scope of a software product. It encompasses the depth and intricacies of a software system's architecture, including its codebase, algorithms, data structures, and the interdependencies among them - but within the specific scope of the software product itself. A complex system is characterized by a sophisticated internal mechanism, which often involves multiple components or modules working in harmony.

Key attributes of how complex software is built include:

• A Robust Internal Architecture: An intricately connected system that can should be able to handle diverse internal operations efficiently.
• High Scalability: A need to efficiently manage increases in size or volume, be it data, users, or transaction capacity.
• Inherent Modularity: Composed of independent but interconnected modules that should allow for easier maintenance and scalability.

An example of complex software could be a high-frequency trading platform that processes millions of transactions per minute, relying on its internal algorithms and data processing capabilities to function effectively without significant external influences.

Decoding Complication in Software

On the flip side, complicated software primarily deals with the external scope of a software product. It involves the interactions and dependencies the software has with other systems, which often introduces a variety of external forces and unknowns into the software environment. Complicated software can be prone to issues stemming from these external interactions, which can make predictability and stability challenging.

Features of complicated software often include:

• Extensive External Dependencies: Heavy reliance on other systems for data, functionality, or services.
• Vulnerable to External Changes: Susceptibility to disruptions caused by changes in connected systems or interfaces.
• Integration Complexity: Difficulties in ensuring seamless interaction between different software systems or components.

For instance, a business intelligence tool that integrates data from various external databases and SaaS platforms might be considered complicated due to its dependency on these external systems and the challenges associated with managing such integrations.

Complex vs. Complicated Software: A Comparative Analysis

The main challenge in developing complex software lies in managing its internal complexity to ensure that the system is both effective and manageable. The complexity should be inherent but well-organized, ensuring that internal operations are smooth and maintainable.

In contrast, complicated software deals with the challenges of external dependencies. Developers must ensure that the software can reliably interact with other systems, which may be unpredictable and outside the direct control of the software's internal mechanisms. The focus is on creating robust interfaces, losely-coupled design patterns, circuit-brakers, abstraction layer, semantic shells and capabilities for handling external data and service integrations efficiently.

Striking the Right Balance

To effectively manage both complex and complicated software systems, developers need to:

• Enhance robustness: Strengthen internal architectures for complex systems while fortifying integration capabilities for complicated systems.
• Improve monitoring and testing: Implement comprehensive monitoring and testing strategies to handle both internal complexities and external dependencies, as well as ways to automate end-to-end testing, across the full internal and external scopes of the software product.
• Focus on user experience: Despite internal or external challenges, ensuring that the end user has a smooth and effective experience should remain a priority

“The function of good software is to make the complex appear to be simple” (Grady Booch)

Use Case Point Analysis - A Holistic Way For Higly-Reliable Software Development Estimations

To translate the theoretical understanding of internal and external complexities into actionable insights for project estimation, use case point analysis offers a structured approach. This methodology systematically quantifies the intricacies of software's internal scope and the unpredictable variables of external interactions.

The internal complexities, encompassing the architecture, algorithms, and data structures, are assessed through a weighted analysis of technical factors - each representing a facet of the system's internal interactions and processing needs.

External complications, on the other hand, stem from the software's reliance on and interaction with outside systems, user dynamics, and environmental contingencies. These are captured in environmental factors that consider the team's expertise, the stability of requirements, and the technological landscape, among others.

By assigning weights and values to each factor and use case, the estimation sheet becomes a nexus where the abstract concepts of complexity and complication concretely can influence the resource allocation, timeline forecasting, and budget planning of a software development project.

It’s a confluence point that encapsulates the software project's multifaceted and diverse-complex nature, ensuring a comprehensive estimation that accounts for every element (internal - complex, and external - complicated) that could impact the development journey.

"Simplicity does not precede complexity, but follows it" (Alan Perlis)

Using the Use Case Point Estimation Sheet

First, download the estimation sheet here. It contains the template (tab 1) as well as an example with data (tab 2).

Actors and use cases: In the estimation sheet, actors are classified into simple, average, and complex categories, with corresponding weights of 1, 2, and 3 respectively. Use cases are similarly classified and weighted as 5 for simple, 10 for average, and 15 for complex. The unadjusted actor weights and unadjusted use case weights are then summed to provide an initial quantification of the system's scope.

Technical factors: Technical factors account for internal complexities related to the software's development. This includes aspects like distributed system architecture, performance issues, code reusability, and data access. Each factor is assigned a weight and an applied value to reflect its expected impact on the project's complexity. The sum of these weighted values contributes to the Technical Complexity Factor (TCF), which is used to adjust the use case points, accounting for the internal complexity of the software product.

Environmental factors: Environmental factors address the external complications and involve considerations such as the team's experience with digital platforms, the maturity of the organization in project management, and the stability of requirements. These factors also receive weights and applied values, affecting the Environmental Factor (EFactor), which modifies the use case points further, reflecting external influences on the project.

Calculating Total Workload: The sum of the Unadjusted Use Case Points (UUCP) is adjusted by the TCF and EFactor to determine the adjusted Use Case Points. Then, by multiplying this number by the 'Hours per Use Case Point' the sheet estimates the total hours required to develop the software product.

Risk and Project Management: Additionally, risk and project management are accounted for as percentages of the total estimated hours, reflecting the understanding that these aspects can influence the overall project duration and workload. These factors are specific as practices by the project management team. Generally speaking, an additional 15% to cover for risks and 20% for project management overhead are good rules of thumb.

Financial Estimation: The sheet translates the estimated hours into financial terms by applying an average hourly cost (again specific per team), leading to a total cost estimation of software development.

Here's the download link once again. I hope it's of value - give it go. Please reach out to me in case you have questions or suggestions.