
The critical role of systems thinking in software development - signa11
https://www.oreilly.com/ideas/the-critical-role-of-systems-thinking-in-software-development
======
jdale27
Can someone point me to an actual, real, significant, practical outcome that
has been achieved via so-called "systems thinking" or "systems theory"?

It seems to make intuitive sense. Yet ultimately it feels like a sort of
"generalized abstract nonsense", a way of "saying less and less about more and
more until you are saying nothing at all about absolutely everything".

I can see how it can be used, at least at a metaphorical level, to explain
things (like "how small flaws can compound to create big problems", as in this
article). But it has never been clear to me how it can actually be used in
practice in a positive way -- determining a small intervention that can be
used to push a complex system in a _desirable_ direction, rather than a
problematic one.

Otherwise, of what use is it other than to convince us that in the real world,
even the smallest mistakes we make can balloon way out of proportion? So...
what are we supposed to do?

1\. Keep our systems simple so that these things can't happen? (Then how do we
build interesting things?) 2\. Formally specify everything so that we
understand every possible error mode? (Seems like just an indirect way of
forcing ourselves to do #1.) 3\. Add enough belts and suspenders and other
layers of redundancy that the probability of a truly catastrophic error is
reduced to the level that you feel comfortable with?

None of those seem very practical, except in the obvious domains where failure
results in loss of human life or massive amounts of money.

~~~
fulafel
I think 1 and 3 are pretty practical, and you can get part way to 2.
Appreciation of simplicity, transparency, robustness etc can be good inputs to
your design without crippling it. There are lots of situations where there is
a better practical solution but you just stop looking for it because you don't
have a reason to say "not good enough" to the inferior solution.

~~~
jdale27
1 and 3, however, are in conflict.

As Tony Hoare said, there are two ways to write software: one is to make it so
simple that there are obviously no bugs; the other is to make it so
complicated that there are no obvious bugs. Clearly the former is much more
difficult and expensive; hence in practice (again, except in those critical
domains) we end up doing the latter, because the economic incentive to do the
former just isn't there, even if we know the customer (and we as developers)
would be happier with it.

~~~
fulafel
I think there are simplicity friendly suspenders, look at eg how the Erlang
school of engineering does it.

~~~
jdale27
Good point.

