Software people have significantly-different understandings of what complexity is. Regardless of what software people believe complexity to be, the perception of complexity affects most software developers in the same way: it influences the choices we make about how to build software. What a software developer, development manager, or even a stakeholder believes about complexity might determine whether the project is put in harm’s way.
Complexity isn’t subjective. It’s a hard measure of the number of inputs into a system, the number of moving parts in the system, and the number of decisions that the system makes that lead to different execution paths. But we often use “complexity” to describe what it like getting our heads around something unfamiliar, which can be a purely emotional response.
Two people saying “I don’t want to do it that way, it’s too complex” can have utterly different perspectives of complexity. If so, then they likely have utterly different and likely incompatible approaches to software development. It’s more likely that people who typically use incompatible approaches will not find themselves agreeing on complexity.
Between the start and finish of a project, a lot of things happen. Software is created, and more software is created. Some of that software interacts with other bits of itself. And more software is created and more interconnections are made. The natural increase in code and interconnections during a project while the software gains more features creates real complexity.
With more code, more natural complexity is added to the system. Complexity is going to accrete, the issue is: how fast? And the single most influential factor in how fast complexity increases is the approach we choose based on what we think complexity is. When we don’t make the right decision, we end up with more complexity than we need. Understanding how complexity is created and how it affects software and projects is a essential part of software physics and helps us to understand how to keep projects healthy.
Complexity isn’t an expression of discomfort with approaches that we have no meaningful experience with. Certainly lack of experience can put a project at risk, and some of that risk might manifest from accidental complexity that results from inexperience, but inexperience itself isn’t complexity.
Ultimately, the point of dealing with complexity isn’t the elimination of complexity, it’s the elimination of accidental and unnecessary complexity. Some forms of complexity are desirable and we choose to add some essential complexity in order to improve other desirable design qualities, and even real complexity isn’t the differentiator between software efforts that succeed and software efforts that fail.
When a developer complains of complexity, it's a sign of something that likely needs to be given some attention. It not entirely uncommon, though, to find that what has been called out as complexity isn’t a reflection of the software or the approach itself, but of the programmer’s emotional content. It’s still a matter of concern, but it might not be a technical concern.
Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience
Learn more about my work and how I can help you at ampgt.com
