www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Why software ends up complex

reply Kagamin <spam here.lot> writes:
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.
Dec 14 2020
next sibling parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
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
Dec 14 2020
parent reply Kagamin <spam here.lot> writes:
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.
Dec 15 2020
next sibling parent reply claptrap <clap trap.com> writes:
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.
Dec 16 2020
parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
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
Dec 16 2020
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Dec 18 2020
parent reply Bruce Carneal <bcarneal gmail.com> writes:
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.
Dec 18 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Dec 18 2020
prev sibling parent aberba <karabutaworld gmail.com> writes:
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.
Dec 14 2020