[HN Gopher] Not Mysticizing System Dynamics
___________________________________________________________________
Not Mysticizing System Dynamics
Author : rolisz
Score : 107 points
Date : 2022-09-25 10:54 UTC (12 hours ago)
(HTM) web link (twitchard.github.io)
(TXT) w3m dump (twitchard.github.io)
| draw_down wrote:
| dr_dshiv wrote:
| Stop mystifying mysticism. This author defines mysticism as
| "appeals to authority." Whatever mysticism is, that ain't it.
|
| https://www.britannica.com/topic/mysticism
| twitchard wrote:
| Merriam-Webster gives a definition "vague speculation : a
| belief without sound basis"
| dr_dshiv wrote:
| Read anything about mysticism and see why that's a lazy
| person definition. In any case, the term is not appropriate
| as a description of "appeal to authority."
|
| https://plato.stanford.edu/entries/mysticism/
| wcarss wrote:
| Properly punctuated, it's actually "Fools! Stop Mysticizing
| System Dynamics"
|
| This is a little like the classic "Free Consultation? No, Money
| Down!"
| spoiler wrote:
| As a fan of SD, I agree that modeling even just very specific
| human attributes is so incredibly difficult, and I'd say even
| impossible. Humans are rarely uniform.
|
| There are some population patterns that can be loosely modelled
| for large sets, but those are also very loose approximations at
| best. And the smaller (eg more individualism breaks through) the
| worse the model performs.
|
| And software teams are generally too small, as any useful model
| would probably have to model individual or at least multiple
| stereotypes (but I'm reluctant to give those too much weight
| anyway)
| philipov wrote:
| System dynamics can tell us _how_ things happened, but they
| struggle to explain _why_ one system took effect and another
| did not.
| marcosdumay wrote:
| In chaotic environments, there isn't any why. There may be a
| reason for a specific alternative not happening, but you can
| never explain all of them.
| zmgsabst wrote:
| Then how can systems design help us predict changes?
|
| If we don't know why a particular model emerged, all
| changes are "turn back to chaos, see results".
| playeren wrote:
| I made this mistake once, albeit with Newtons second law instead.
| I was explaining my estimations for changing some key processes
| in a company. As a kind of mental aid, I used 'F' as the total
| effort needed to make the change, while 'm' represented the size
| of the organization, and 'a' would represent the speed we wanted
| to perform the change with. F = m * a. A simple way of
| illustrating the exponential relationship between these factors.
|
| But it blew their mind. It took on 'mystical' properties, as if
| we had distilled change management into pure Newtonian motion. I
| started seeing not only F = ma in memos on other issues, but also
| other equations like E = mc^2, trying to wrestle management lingo
| into relativistic conservation of energy.
|
| Lesson learned, I guess.
| mjburgess wrote:
| I hope one day to possess an explanation of why that behaviour
| is sometimes good. Since, like you, I am alarmed/concerned by
| it. But clearly, largely, its what makes "a lot of the world go
| round".
|
| This emotion, "wonder", is profoundly suspicious to me; and I'm
| often hostile to it. I am sure I'm missing something...
| philipov wrote:
| Wonder is what drives people to be interested in and want to
| learn about how the world works. It's a very important
| emotion to let thrive. But, like all good things, too much of
| it can become harmful. Wonder is best when tempered with
| rigor. It is a starting point, but it must not also be the
| ending point.
| roenxi wrote:
| People are trying to copy the smartest person in the room,
| but don't themselves have a good way of evaluating how smart
| an idea is. When that strategy produces a miss, it produces a
| rather absurd one (like in this anecdote).
|
| But the strategy itself is good, particularly if the group
| correctly identifies who has the best ideas. Copying smart
| people works if you can find them.
| ouid wrote:
| >The strategy itself is good.
|
| You _cannot_ factor the strategy from its implementation
| here. I think that was trying to be your point but then you
| contradicted yourself. I must encourage you to commit. A
| dumb person who tries to find smart people will find only
| con-artists. Its the law of lemons.
| roenxi wrote:
| A strategy doesn't have to work every time to be good.
| "Dumb people" can and do find people smarter than
| themselves and put in an effort to copy them. Usually
| that is a good idea - better than trying to go it alone,
| any way.
| ouid wrote:
| My brother in christ, most of the people who voted for
| donald trump did so because they think he's smart. Its a
| good goal. its a _terrible_ strategy.
| marcosdumay wrote:
| > Copying smart people works if you can find them.
|
| Well, works more often than not (I hope your downside risks
| are low). While understanding what they are doing works
| almost every time.
|
| Besides, it works more often than not, in a simple setting
| where there is no antagonistic communicator. In a word with
| propaganda and politics, it fails almost every time.
| a1369209993 wrote:
| > understanding what they are doing works almost every
| time.
|
| To be fair, understanding what they are doing requires
| being smart yourself (usualy not as smart as coming up
| with it in the first place, but only usually), and while
| smartness isn't always or completely unlearnable, in
| practice it's usually hard and/or impractical, especially
| if you're not smart to begin with.
|
| Of course, distinguishing (honest) smart people from
| (possibly smart) con artists _also_ generally requires
| being smart, so that doesn 't help much.
| noSyncCloud wrote:
| If you can't experience wonder, that must make you history's
| most recent example of someone who's basically figured
| everything out. That must be very nice for you, but you are
| assuredly wrong about many things that you know you know.
| delusional wrote:
| It could also be depression or just cynicism.
| drewcoo wrote:
| So you claimed "total effort equal orgs size times the speed
| you wanted change in?" And that that was equivalent to F = m *
| a?
|
| That's not mind-blowing so much as jaw-droppingly wrong. Org
| size is an exponential factor for things like that. And speed
| of change isn't the issue for orgs so much as changing
| direction under the current momentum, if we're using a physical
| model. No wonder it wasn't met with widespread acceptance.
|
| It was a vast oversimplification that mapped badly to the
| situation but delivered, no doubt, with confidence, so of
| course it was adopted by copycats. Simplicity and
| overconfidence sells.
| lukifer wrote:
| Accuracy, utility, elegance: pick two.
| bmacho wrote:
| Pick any two and the third comes for free
| cycomanic wrote:
| > I used 'F' as the total effort needed to make the change,
| while 'm' represented the size of the organization, and 'a'
| would represent the speed we wanted to perform the change with.
| F = m * a. A simple way of illustrating the exponential
| relationship between these factors.
|
| Am I missing a certain insight or did you mean the linear
| relationship not exponential?
| wolfram74 wrote:
| No one uses expontential correctly in colloquial contexts, it
| gets slapped on any super linear curve, or in this case even
| a linear equation.
| the_af wrote:
| But using exponential to mean a linear equation is all
| sorts of wrong, even in a colloquial sense.
|
| I would understand a colloquial meaning of "exponential" as
| "it grows faster than linear". Wrong, but it makes informal
| sense. But using is as a synonym for linear makes no sense
| whatsoever.
| colechristensen wrote:
| What is your definition of exponential then?
| kittiepryde wrote:
| y=x^a would be an example of an exponential equation;
|
| I guess applied to the metaphor, F=a^m
| orbital223 wrote:
| f(x) = x^a is a polynomial of degree a.
|
| f(x) = a^x would be an exponential function.
| kittiepryde wrote:
| You are right. Thanks for correcting me.
| igorkraw wrote:
| Your variable goes into exponent position. If X is your
| variable, a^x is exponential, x^a is a-tic
| fsckboy wrote:
| humans learn words through contextual exposure to them.
|
| exponential has two meanings depending whether you
| studied and understood what exponentials are in a math
| class, or did not.
|
| if you did not but you've learned the word through
| repeated verbal contexts, it means "bigly"
|
| also, in the example given of F=ma, the "a" is
| characterized as "speed" (per second) which it is not;
| but rather "acceleration" (per second per second) which
| is related to speed via an integration over time
| (seconds), but that's a f(unctional) relationship as is
| exponentiation, so from context I think people pick up
| that exponential means something like biglyly
|
| (When I read the Mysticization title I was prepared for a
| pun on the game Myst, but it didn't show up. Myst and
| SimCity date from the same period of time, and SimCity is
| a system dynamics game. I was disappoint.)
| rzzzt wrote:
| Exponential: f(x) ~ n^x ("n" is constant, "x" is the
| exponent)
|
| Parabola: f(x) ~ x^m ("x" is the base, "m" is constant)
| glass_of_water wrote:
| A function f(x) whose growth rate at x is proportional to
| f(x). So anything where growth rate is proportional to
| the current value.
| marginalia_nu wrote:
| f(x) = 0 is the rarest exponential function of them all.
| crdrost wrote:
| It grows in every way, because it grows in no way. Does a
| dog have the Buddha nature?
| mcphage wrote:
| Mu.
| crdrost wrote:
| There were a bunch of answers, but this is the one that
| is the most handy in my toolkit.
|
| Linear growth of A on B: For every new B, _k_ new As
| emerge, for some _k_ (could be and often is fractional).
|
| Quadratic growth of A on B: A grows approximately
| linearly with the number of _handshakes_ in B, so that in
| the above language, for every new B, _k_ x B new As
| emerge, one _k_ for every existing B that the new B could
| interact with.
|
| On this basis one would say that the number of bugs is
| quadratic in the lines of source code. Each line has some
| small probability of interacting with some distant line
| in some non-negligible buggy way.
|
| Exponential growth of A on B: A grows approximately
| linearly with the number of connections between A and B,
| so that in the above language, for every new B, _k_ x A
| new As emerge, one _k_ for every A that the new B could
| interact with.
|
| So for "knowledge increases exponentially," the precise
| technical claim is that it increases exponentially with
| time, and this means (somewhat dubiously for long scales)
| that in a given period of time, every every fact you know
| has a constant probability of generating a new fact which
| you now also know. This holds when you don't know very
| much about a new scenario but tends to be tempered out
| rapidly, the phenomenon of "low hanging fruit" etc. A
| meme similarly has an approximately exponential region
| where the number of folks exposed to the meme drives
| further exposure to the meme, but this dries up as the
| probability of "already shared it!" rises and curtails
| that "I must share it with friends" impulse.
| bsilvereagle wrote:
| I suspect F was fixed and the curves were showing how m/a
| varied in that case, in a similar fashion to these plots for
| momentum: https://frdmtoplay.com/on-a-researchers-momentum/
| programmarchy wrote:
| Point of clarification: the original title has an exclamation
| point after "Fools". Might want to at least add a comma ;)
| ClumsyPilot wrote:
| seems to apply to markets equally
| scottfr wrote:
| I created a fairly popular system dynamics modeling application
| back when I was a grad student [0].
|
| When using modeling tools like system dynamics, it's useful to
| keep in mind George Box's quote that "All models are wrong, but
| some are useful".
|
| When using a modeling tool to describe any form of social system
| you're creating an imperfect copy of it. This imperfect copy
| embeds what the modeler (rightly or wrongly) views to be
| important and how they believe the system to work.
|
| The resulting model, though always wrong to some extent, may be
| useful. It may help you obtain a better understanding of a system
| and cause positive change in an organization. On the other hand
| it may not be useful, it may even mislead you.
|
| You can think of modeling a lot like various software engineering
| practices like Agile. Sometimes these help teams, sometimes they
| don't. At the end of the day though, it's really about the teams
| using them not the specific techniques.
|
| [0] https://insightmaker.com
| marcosdumay wrote:
| This article is not a complaint about system dynamics. The
| complaint is about the "mysticizing" part.
|
| If you look at the first example, it's a person that mimicked
| all the procedures and jargon of system thinking, while
| ignoring all of the most fundamental knowledge of the area. In
| particular, the most fundamental insight about humane systems -
| that the system reacts to the optimization - goes so over the
| person's head that there isn't even a whoosh.
|
| System dynamics is good, and very useful. But you have to
| understand it to apply it.
| KaiserPro wrote:
| A while back there was a post that said in essence: "queues grow
| to inifinte size when the consumer is approaching 100%
| utilisation"
|
| However it went deep into lots of theory, which made it all sound
| very sciency and clever. However it failed to get across the
| simplicity, which even a 9 year old can grasp:
|
| Queues are like sinks, if you put water in at close to the rate
| that the drain lets it out, the water level of the sink doesn't
| drop, any slight imperfection makes the level rise.
|
| animated gif, and be done.
|
| Instead it dressed up queues as some complex and difficult to
| predict beast, that only big companies with very clever people
| can use.
| whatshisface wrote:
| I don't think your analogy is actually right. If the water
| pouring into the sink delivered more water in a second than the
| drain could handle, that'd be more than 100% utilization.
|
| It's actually kind of surprising that you can end up with an
| queue going to infinity when you can process N events per
| second, and _fewer than N events per second, on average, are
| occurring._ I think it has something to do with gambler 's ruin
| and the fact that continuing to bet $1 on a fair 50/50 game
| will eventually bankrupt you, every time, even though the
| game's "fair."
| zmgsabst wrote:
| I think it's similar to that, with some critical point at
| which the behavior makes a discontinuous change -- as seen
| from the examples:
|
| - the gambler goes broke
|
| - a sink carrying over 100% capacity can jam
|
| In general, if you have some kind of system where there's a
| "critical threshold" and a discontinuous (or even non-linear)
| result for crossing it, then approaching that boundary will
| be increasingly dominated by that effect, as the distribution
| of events starts to cross into that regime.
|
| For the example of a queue, the odds of a packet failing due
| to delay suddenly spikes as you approach "full capacity"
| because the variation in packet timings causes it to "cross
| over" that boundary for brief periods, the closer the mean of
| the distribution moves to the critical threshold.
| KaiserPro wrote:
| > If the water pouring into the sink delivered more water in
| a second than the drain could handle, that'd be more than
| 100% utilization.
|
| this is where the sink bit comes in. For small amounts,
| queues are great at absorbing load. for example, you can dump
| two or three who glasses at once into a sink, and the drain
| will be fully utilised. (try doing that by pouring the
| glasses concurrently into the drain pipe at once.)
|
| > fewer than N events per second, on average, are occurring
|
| average is doing a lot of work here! unless you are very
| lucky, an average can hide a lot of variance. If we go back
| to the sink analogy, pure water flows away more or less at a
| constant rate (if we ignore whatever the spinny whirlpool
| effect is) The variance in processing time is very little.
|
| However, if we start dumping washing up water in there, lumps
| of food will start to clog the drain. on average, assuming no
| blockages, processing time increases a little bit. but when
| we get close to peak capacity, a blockage will cause an
| overflow thats very difficult to clear. This is because there
| is no extra capacity to get through the backlog.
|
| the rule of thumb is that as you get close to 80-90% of your
| consuming capcity, your queues will begin to expand.
|
| when you are designing your stuff two things might save you:
| expiring keys, and bounded queues.
|
| The first one means dataloss that you need to handle
| yourself. the worst part is, you might not get informed that
| your message is lost. So that needs careful thought
|
| the second one means that things pushing into the queue need
| to check the state of it before pushing. Back pressure is
| always good. At least the client knows _before_ the data is
| sent.
| kqr wrote:
| Also known as "queueing theory is just discrete fluid
| dynamics".
| sarchertech wrote:
| The author makes the point that it's not more engineers (and the
| corresponding resource contention problems) causing slower
| delivery at large companies, but complexity.
|
| However one of the driving forces behind complexity is the amount
| of engineers. Microservices largely exist as a way of enforcing
| boundaries to allow more people to work together.
| iknownothow wrote:
| I agree with the author that applying systems dynamics to
| software teams and organizations might be too rigid and
| inevitably fails when you treat humans as static and
| unchangeable. I personally despise single metric optimization.
|
| However there is value in applying systems dynamics to software
| teams and treating humans as probabilistic variables. And instead
| of maximazation, one can do expectation maximization i.e. finding
| the average outcome. Modelling such a system is hard and
| intutions play more of a role here because our brains are well
| suited to probabilistic thinking (to a degree for simple
| systems).
|
| But I can see why leadership gurus don't prefer the probabilistic
| dynamics. Because it involves "luck" and asking leaders to do the
| optimal thing i.e. sticking to the expected maximum (average
| outcome) isn't sexy and doesn't lead to winners and losers.
| Instead, in a capitalistic system, all leaders are expected to
| engage in risky decision making and every once in a while one
| leader wins, standing on the shoulders of a good software
| development team which also happened to be on a hot streak that
| quarter, whereas other leaders who didn't win are blamed for the
| poor performance of their equally good software development teams
| who happened to be in a slump that quarter.
| naasking wrote:
| > And instead of maximazation, one can do expectation
| maximization i.e. finding the average outcome.
|
| Or perhaps failure minimization.
| darkerside wrote:
| > Engineering leaders, in my view, are gardeners, not bottleneck-
| clearers. As I wrote above, the priority of leaders should be
| culture - psychological safety, pride of workmanship, compelling
| narratives, and such.
|
| I've seen this sentiment go way too far at times. A leader's job
| is to make the organization more effective. Sometimes that means
| clearing a bottleneck, sometimes it is building a culture. If you
| think your job is that specific, you're one situation away from
| losing it.
| thinkingkong wrote:
| I might be applying my own mysticism about the original authors
| of the posts that this article speaks; but I think people are
| missing the point.
|
| Yes. 100%. The map is not the territory here. The models
| presented in these examples are not perfect representations of
| the teams that people have built at all companies. It is easy and
| fun to poke holes in them as we're prone to do.
|
| But for whatever it's worth, software delivery absolutely _is_ a
| system. The level of understanding about how that system operates
| is all over the place. Some managers have absolutely zero idea
| about how their software goes from "issue open" to "its running
| in production" and they need to. Engineers need to as well. If
| it's informally occurring or informal knowledge, it should be
| made explicit. The part where we all get our back up is when a
| manager goes "improve this metric" _without_ understanding system
| dynamics. The example about constraints stands out to me. If you
| 're going to optimize a hot path in your software, you don't
| throw your hands up and go "All models are wrong!" You can
| actually instrument the way it works and see which method or
| areas require attention and thought. If we take these as
| _analogies_ and apply them to how we eliminate variability then
| life is generally better for everyone.
|
| I do tend to agree however, that these things are not leadership.
| But leadership requires situational awareness. Situational
| awareness is only acquired over time by "intuition" (which is
| often wrong) or by explicitly writing it down. Intuition is very
| difficult to explain to other executives, managers, and yes even
| software engineers. People like tangible things that reduce the
| resolution of the objects they represent and that's not going to
| change any time soon.
| musingsole wrote:
| > software delivery absolutely is a system
|
| A system/organization with a sufficient number of members will
| create emergent behaviors that no individual leader (or
| engineering leader) can account for. That's the domain of
| culture. See religion for examples of successful ones. A key
| characteristic is that the individual is meaningless and at
| best only a channel through which the greater-than-individual
| interactions play out.
|
| So, when an individual applies system modelling to the
| situation -- they will necessarily overemphasize the portions
| they understand and believe while FAILING to incorporate
| anything representing the behaviors they aren't aware of.
|
| People like comfort blankets. System modeling is a particularly
| powerful one. The actual applicability of the practice is a
| question to be left to evolution.
| OrvalWintermute wrote:
| > I understand the appeal. We're engineers. We like building
| things. System dynamics lets you construct an argument by
| building a model. Provocative title aside, I do appreciate this
| style of argument. Some very thoughtful writing is done this way.
| It is explicit and engaging; it can even be visual or
| interactive.
|
| No. You're not engineers, you are software developers.
|
| While both may require a certain amount of skill and expertise,
| you're throwing around titles casually where it doesn't make
| sense. In most cases, engineers deal with the physical world and
| the laws around it, and the product in terms of an engineering
| solution is normally physical/materiel.
|
| Software development particularly when it does not include a
| physical component is intrinsically different because the
| fabrication aspect of the physical world applies a great deal
| less. For example, if you are at a critical design review of a
| jet engine, the refabrication and fixes of components may require
| huge amounts of time. In software development the output is code,
| and although person hours and work is involved in
| modifying/changing it, it has inherent plasticity.
|
| This is why more iterative methodologies make a great deal more
| sense in software than do engineering oriented development
| processes.
| wpietri wrote:
| Is it just me, or is the author making a lot of soup from very
| little meat?
|
| E.g., the first bit:
|
| > > For example, if you don't have a backlog of ready commits,
| then speeding up your deploy rate may not be valuable.
|
| > Does this mean speeding up deploys to 1 minute is valueless?
| That's crazy talk!
|
| That looks to me like a blatant straw man. The quoted author said
| "may", meaning there may well be other reasons that faster
| deploys is better. And there are, for a different model which the
| article's author suggests but doesn't bother to explain with the
| rigor that he's expecting from people talking system dynamics.
|
| For any intellectual tool, some people apply it blindly and some
| put in the work to use it contextually. Can you use SD approaches
| blindly? Sure. But in my experience it's way less common than the
| the person using an implicit model (e.g., the tiresome "software
| is a factory" analogies).
| divan wrote:
| While agreeing with post, I wish SD software was more affordable.
| Major players (Stella, for example), charge 4K$ for a single
| license. With that entry barrier, it's no surprise that SD is
| still a niche thing for nerds that tend to fall in love with
| their models.
|
| Imagine that in any govt, non-profit or commercial organization,
| people use some sort of well-known extra user-friendly and smart
| SD tool for quickly building and visualizing their mental models
| (not just about software teams, but on any problem domain).
| Instead of clumsy drawings on whiteboards we'd have SD
| visualizations that anyone in the room can argue about and
| collaborate.
___________________________________________________________________
(page generated 2022-09-25 23:01 UTC)