Anyone here read the "Thinking in Systems" book? systems thinking seems to be surprisingly absent from many professional developers and engineers. Or, they lack the ability to abstract properly beyond their specific domains. I'm trying to improve this in my office and would like to find some books to hand out to people (particularly some of the more promising young folks, influence them before they get stuck in a bad mode of thought).
Based on the Amazon reviews it seems like it might be the sort of book I'm looking for, I'll continue to check through those and for other reviews later.
It's an excellent book for folks who haven't been exposed to this stuff [1] before, but it could be called "Cybernetics for Dummies" (I don't mean that in a bad way!)
I can recommend "Feedback Control for Computer Systems" by Philipp Janert [2], but the real underlying treasure is understanding Cybernetics. For that, try "Introduction to Cybernetics" by W. Ross Ashby [3].
I quite liked it. To be honest, I read it either before or after Gerry Weinberg's systems book and really enjoyed them both. Unfortunately their content is now jumbled in my brain and I don't remember who said what.
I'll pick it up (based on your and others' comments here as well as reviews I've been able to find). It seems like it might be the sort of material I'm looking for.
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.
Get you a copy of "Permaculture: A Designer's Manual" by Bill Mollison.[1] Never mind that it's technically about farming. It's the finest manual of abstract design I've ever encountered.
Based on the Amazon reviews it seems like it might be the sort of book I'm looking for, I'll continue to check through those and for other reviews later.