Comment by jdale27 | Hacker News Reader

Comment by jdale27 | Hacker News Reader

Parent Full thread

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.

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.

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.

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

Good point.

The way I use it is to assume certain things, and then consider the consequences of them. I wish I could have discussed this more in the article, but the specific example got long enough that a theory tie-in would have been a lot for a blog post.

But anyway, things like feedback loops (both positive and negative), oscillations, stocks, flows, control points, system boundaries, etc. etc. -- these are all tools for giving both names and operational patterns to different things you'll see happen in a system.

And once you have that, you end up with a better mental model from first principles that lets you anticipate and work with certain aspects of systems before you learn its behavior through trial and error / best practices.

I need to dig deeper myself, but I found "Thinking in Systems" from Donella H. Meadows a good primer on the basics . So far the best benefit systems thinking has given me is a changed perspective on things, but I think it'll help for doing more detailed analysis with a bit more study and practice, too.

Reply on news.ycombinator.com