Complexity, if it can be reduced to a single measurable dimension, is only one of several factors in a solution space.

There are other properties such as, maintainability, scalability, reliability, resilience, anti-fragility, extensibility, versatility, durability, composability. Not all apply.

Being able to talk about tradeoffs in terms of solution spaces, not just along a single dimension, is one of what I consider the differentiator between a senior and staff+ developer.

▲

bonesss 2 hours ago | parent | next [-]

“Complexity” understood as the immediate first impression a junior gets looking at some arbitrary facet is always bad and too much and bad.

“Complexity” understood as what’s gonna make development on this system fly easy and fast for the next 10 man-years de facto means side steps when naive approaches would charge straight ahead.

Tortoise and the Hare… the urge to hurry up and burn hard the first two weeks (low hanging fruit, visible wins, MVP!), resulting in ever decreasing momentum due to immature design and in-dev maintenance needs is befuddling to me. So much “faster” for weeks, and it just meant the schedule slipped 6 months.

▲

t43562 an hour ago | parent | prev | next [-]

TRADEOFFS! I think this is IT. Non programmers imagine there aren't tradeoffs. As a programmer one should eventually realise that every possible aspect of design is a tradeoff.

▲

lwhi 2 hours ago | parent | prev | next [-]

Many of these factors are directly influenced by complexity.

▲

hosh an hour ago | parent [-]

They all influence each other to one extent or another.

And, the Cynefine Framework defines “complexity” a bit differently than the intuitive way it’s often used.

The simple domain is a single dimension. The complicated domain is a system of factors. I think when most people say “complex”, they are really talking about what Cynefine labels as “complicated”.

The Cynefine complex domain is not so easily solved or reduced. It has emergent behaviors. The act of measuring tends to perturb the system. No single solution will ever solve something in the Cynefine complex domain, because the complex system will shift behavior, making solutions that worked before start working against it.

Examples are ecosystems and economies. Software systems tend not to be complicated, not complex, until you start getting into distributed systems.

One of the key insights of Cynefine is understanding that each of the domains has its own way of solving things and that often times, people use solutions and methods from one domain to solve problems characterized by a different domain.

You don’t solve problems in the complicated domain with methods from the simple domain. And you don’t solve problems in the complex domain with methods that work for complicated domains.

	▲	chrisweekly 27 minutes ago \| parent [-]
		Interesting and salient comment. But > "Software systems tend not to be complicated, not complex, until you start getting into distributed systems." these days so much software is "distributed systems".

▲

nomel 2 hours ago | parent | prev [-]

You missed one of the most important ones: usability

	▲	hosh an hour ago \| parent [-]
		I was not trying to be exhaustive. I am sure you can come up with more characteristics.