A brain dump of my thoughts on this follows:

http://www.thinking.net/Systems_Thinking/OverviewSTarticle.p...

Kind of gets at what I'm wanting to convey to people. Often (especially with technical people) we focus on a narrow thing. I have a problem, I will fix it. We don't examine the environment in which the problem exists to actually understand its causes and impacts. Maybe my problem is actually not a problem for the organization, it may actually be a benefit. Example:

A friend works in aircraft maintenance. They do something called "bonded repair", using adhesives to apply patches rather than other techniques. It's remarkably effective. But when the patch is later removed during a big maintenance effort, the technicians have to remove the remaining adhesives. They've been given a plastic (consumable) tool, it's slow and breaks but they're cheap and ultimately effective. The technicians look at the "problem" (too slow, breaks) and go find a metal tool. It's faster, doesn't break, they can get the whole area cleared by lunch. Great!

No! The metal tool introduces scratches. Scratches become failure points in the future so they have to be repaired before the aircraft is released. The local optimum introduced a 2-week delay in releasing every aircraft while damage detection and repair was conducted. And potentially worse failures in the future if the scratches aren't detected.

A systems thinker would examine the whole of the operation before solving their local problem. This is the thing I want to convey to my colleagues.

For developers, the locally (to you or maybe even your team) optimal decision to use language X may seem great. But then it turns out you aren't the one maintaining it in 5 years. Your choice to use Rust in 2011 was ok. But now in 2018 none of your code compiles because of changes to the language in the intervening 7 years [0]. Now the maintainers have to rewrite things, or stick with a now very outdated and potentially unstable compiler and tool suite. C++ may have been unpleasant to use, but it may have been a better choice within the environment of the decision.

Other times, by not applying systems thinking, you find yourself solving the same or similar problems over and over. Perhaps your code review process is incomplete, or your use of version control is non-existent or haphazard. Have you ever been in a shop where the same damn bug showed up every second or third build? Why? Because they solved the problem (the bug) but failed to understand the process and systemic problems that permitted the regression in the first place. And if that regression-permission-failure isn't addressed, other regressions will happen in the future and may go undetected.

=====

Long story short: Systems engineering applies systems thinking to the design and development of, well, systems. Software engineers should definitely study it, at least if they want to be called engineers. But systems thinking is a component of systems engineering that can go way beyond that one area in terms of applications. The more people can view things this way, the better off your team, your office, your company, your world can be. My problem is not just conveying the value of it (I have anecdotes galore), but actually bringing people up to the level where they can do it themselves, independent of my prodding and guiding.

=====

[0] Not a dig on Rust. They've stabilized the language specification, but this is a thing that can and does happen.