https://alexgaynor.net/2020/nov/30/why-software-ends-up-complex/
I will just copy it at length:

Complexity in software, whether it’s a programming languages, an API, or a user interface, is generally regarded as a vice. And yet complexity is exceptionally common, even though no one ever sets out to build something complex. For people interested in building easy to use software, understanding the causes of complexity is critical. Fortunately, I believe there is a straightforward explanation.

The most natural implementation of any feature request is additive, attempting to leave all other elements of the design in place and simply inserting one new component: a new button in a UI or a new parameter to a function. As this process is repeated, the simplicity of a system is lost and complexity takes its place. This pattern is often particularly obvious in enterprise software, where it’s clear that each new feature was written for one particularly large customer, adding complexity for all the others.

Every feature request has a constituency – some group who wants it implemented, because they benefit from it. Simplicity does not have a constituency in the same way, it’s what economists call a non-excludable good – everyone benefits from it. This means that supporters can always point to concrete benefits to their specific use cases, while detractors claim far more abstract drawbacks. The result is that objectors to any given feature adition tend to be smaller in number and more easily ignored. Leading to constant addition of features, and subtraction of simplicity.

Escaping this viscious cycle is not easy. One can easily say, “so reject all feature requests”, but a project that does so will eventually find itself unable to serve its users’ needs at all! Our approach must be more measured: we need to spend as much time thinking about how a new feature will burden all of our users, as we spend thinking about how it will benefit some of our users. We should also spend time thinking about how to design new features in a way that maintains what Fred Brooks’ called the “conceptual integrity” of a system, rather than by merely tacking something new on.

On 14 Dec 2020 at 16:21:59 CET, "Kagamin" <spam@here.lot> wrote:

> https://alexgaynor.net/2020/nov/30/why-software-ends-up-complex/

I don't want to be too picky but there is a very important difference between complexity and complication.

You can't reduce complexity. If you need a switch with two positions, you have complexity 2, with three positions 3, etc. You can't get rid of it.

But there are simple 2 way switches and complicated. The end result (leaving other aspects aside) is exactly the same.

Most software is way too complicated for the complexity it handles. A very useful complication KPI for GUI applications is "clicks to result". When you start counting these... you will see how bad a lot of GUI software is.

IMO to handle complexity in a simple way the gap between "possible" and "just works" is key. The biggest value forms the closer you get to the „just works“ state. I would even bet, it’s exponential.

That's a key success factor for all "infrastructure level" technology, where I count D in.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Monday, 14 December 2020 at 15:21:59 UTC, Kagamin wrote:
> https://alexgaynor.net/2020/nov/30/why-software-ends-up-complex/
> I will just copy it at length:
>
> The most natural implementation of any feature request is additive, attempting to leave all other elements of the design in place and simply inserting one new component: a new button in a UI or a new parameter to a function. As this process is repeated, the simplicity of a system is lost and complexity takes its place. This pattern is often particularly obvious in enterprise software, where it’s clear that each new feature was written for one particularly large customer, adding complexity for all the others.

We kind of know but we don't seem to find a solution to this.

>... we need to spend as
> much time thinking about how a new feature will burden all of our users, as we spend thinking about how it will benefit some of our users. We should also spend time thinking about how to design new features in a way that maintains what Fred Brooks’ called the “conceptual integrity” of a system, rather than by merely tacking something new on.

In practice, it's almost impossible to avoid that level of complexity that comes from adding new features (glued together parts that are nothing like the originally intended design). Unless there's a complete/gradual rewrite.

On Monday, 14 December 2020 at 17:58:17 UTC, Robert M. Münch wrote:
> On 14 Dec 2020 at 16:21:59 CET, "Kagamin" <spam@here.lot> wrote:
>
>> https://alexgaynor.net/2020/nov/30/why-software-ends-up-complex/
>
> I don't want to be too picky but there is a very important difference between complexity and complication.
>
> You can't reduce complexity. If you need a switch with two positions, you have complexity 2, with three positions 3, etc. You can't get rid of it.

Once complexity is there, nothing can be done with it, so there's no problem to solve. But you can reduce complexity by not having the feature in the first place, that's the difficult part.

On Wednesday, 16 December 2020 at 07:51:14 UTC, Kagamin wrote:
> On Monday, 14 December 2020 at 17:58:17 UTC, Robert M. Münch wrote:
>> On 14 Dec 2020 at 16:21:59 CET, "Kagamin" <spam@here.lot> wrote:
>>
>>> https://alexgaynor.net/2020/nov/30/why-software-ends-up-complex/
>>
>> I don't want to be too picky but there is a very important difference between complexity and complication.
>>
>> You can't reduce complexity. If you need a switch with two positions, you have complexity 2, with three positions 3, etc. You can't get rid of it.
>
> Once complexity is there, nothing can be done with it, so there's no problem to solve. But you can reduce complexity by not having the feature in the first place, that's the difficult part.

I think he's making a distinction between complexity that is inherent to the problem and unnecessary complexity due to a poor solution.

Unnecessary complexity is mostly down to lack of orthoginality I think. If you have a bunch of small independent parts its' much easier to reason about how the code you're looking at will behave. But if the parts change how they behave based on the context, or have exceptions or corner cases, then you have to hold a lot more in your head at one time to understand whats going on.

I think the point is complexity is less about how much stuff you have, and more about how it all interacts.

On 16 Dec 2020 at 11:59:37 CET, "claptrap" <clap@trap.com> wrote:

> I think he's making a distinction between complexity that is inherent to the problem and unnecessary complexity due to a poor solution.
> 
> Unnecessary complexity is mostly down to lack of orthogonality I think. If you have a bunch of small independent parts its' much easier to reason about how the code you're looking at will behave. But if the parts change how they behave based on the context, or have exceptions or corner cases, then you have to hold a lot more in your head at one time to understand whats going on.
> 
> I think the point is complexity is less about how much stuff you have, and more about how it all interacts.

Yes, thanks for the extended explanation.

The other dimension is complication: For a necessary complexity you can come up with a smart & simple solution or with a complicated one.

And if you now have non-value complexity (many things to handle) due to poor design, combined with a complicated implementation due to a poor solution, you are doomed.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Wednesday, 16 December 2020 at 07:51:14 UTC, Kagamin wrote:
> Once complexity is there, nothing can be done with it, so there's no problem to solve. But you can reduce complexity by not having the feature in the first place, that's the difficult part.

Programming languages are different. What matters most is what they underlying language looks like (when you remove syntactical sugar). If the underlying language is clean then you can always set up a new syntax that can be used together with the old one.

On Friday, 18 December 2020 at 15:10:18 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 16 December 2020 at 07:51:14 UTC, Kagamin wrote:
>> Once complexity is there, nothing can be done with it, so there's no problem to solve. But you can reduce complexity by not having the feature in the first place, that's the difficult part.
>
> Programming languages are different. What matters most is what they underlying language looks like (when you remove syntactical sugar). If the underlying language is clean then you can always set up a new syntax that can be used together with the old one.

Yes.  What matters is simplicity as accurately perceived by the reader of the language and, to a lesser extent, simplicity as perceived by the compiler writers.

Language augmentations, unarguably, make a language implementation more complex but they can also make the language simpler to use correctly.

On Friday, 18 December 2020 at 16:39:39 UTC, Bruce Carneal wrote:
> Yes.  What matters is simplicity as accurately perceived by the reader of the language and, to a lesser extent, simplicity as perceived by the compiler writers.
>
> Language augmentations, unarguably, make a language implementation more complex but they can also make the language simpler to use correctly.

Indeed. Like, any aspect of the type checker that doesn't affect code gen could be defined to be outside the core language (e.g. a borrow checker, sanitization). And as we start to see with more and more advanced IDEs, that aspect of the language does not have to be embedded in the compiler, but yet the programmer may perceive that the feedback they get from the IDE does contribute to the experienced language (as they see it). The boundary is not as clear as it once was.