Build a simple database, a simple interpreter, and a simple web application (backend and frontend). Read about “distributed systems”, “devops”, “Conway’s Game Of Life”, and “fractals”. Read about these technologies/techniques (in whatever order is comfortable), how they work, their pros and cons, why they were created, how they compare to alternatives: “TCP”, “Open Sound Control”, “Plan9”, “REST”, “Lisp”, “Erlang”, “Smalltalk”, “Forth”, “Datomic”, “event sourcing”, “reactive programming”, “communicating sequential processes”, “APL”/“J”/“K”, “Ansible”, “jq”, “graph databases”, “Apache Kafka”
The idea is not to become an expert in any of these, but to digest the wisdom that lies in their design and surrounding literature. Each was created after lots of careful thought by brilliant people about how to build sustainable systems.
This is how it worked out for me. I tried to build the system myself and note the abstractions, edge case. It didn't make me an expert in all things but gave me the right questions to ask. As you do enough of these your expertise will crystallise in a particular domain.
Started by building my own build system, monitoring solutions, taking at stab orchestration problems, graph databases etc.
The problem statement would be super simple like how do I install my application on 100 servers? And I will start off with bash, tar, ssh and work my way up.
The goal isn't too finish. You want to discover the problems first hand, decide upfront how you would evaluate an acceptable solution, attempt a naive solution, and then look at an open source system, note the family of algorithms + data structures then loop back and move onto the next set of problems in the domain.
Ideally the system you're building is distributed.
Mostly I work from the outside going in and counterintuitively I start with the two non-functional requirements, as questions: how fast do you want it to go, secondly how badly can the system fail. I find that I'm peculiar in this approach.
This won't work for everyone. It has for me because it's allowed me to build a handy library of interrogative and evaluative heuristics and develop strong understanding system architectures and design
Huh? I currently work with some of the technologies you mention, but fail to see the connection to systems theory. Can you elaborate why e.g. jq or Erlang are relevant here?
- There is general systems theory [0] and within that systems engineering[1] where you will find software systems [2]
- OP is most likely talking about how to use of general theory of systems in different domains and not specifically software systems.
- If one considers JQ, SED and "One input stream, one output stream" and then compares that to a model of a system using a CLD (Causal Loop Diagram). A CLD is effectively "An input, followed by an output"
- Another word that could be used for "input stream" would be 'flow' from system dynamics [3]
- One could apply general systems theory (the abstract concept) to just about anything
Yes this is how every Unix command line utility works.
There is nothing unique about jq in this regard, and there is nothing particularly “systems thinking” about any of them. You can and people have used them for decades without doing any special “systems thinking”.
The Unix model is really useful in my systems thinking precisely because thousands of components all use the stream in/out approach. This made then reliable within a system to be used together in many different combinations and interactions.
Also a good example of loose coupling that allows for good thinking of systems.
I took your "e.g." to mean inclusive of jq and Erlang, but extensive to the entire list. What I said applies to Erlang, OSes, and LISP, but maybe not to jq (I wouldn't know).
Missing the thing that has had the single biggest impact on how I personally think about programming: Learning a properly typed language (e.g. Haskell).
I'd also substitute Ansible with Nix/NixOS because the conceptual takeaways are much greater there.
An absolutely _fantastic_ book. It was also one of the scariest books I've read recently. Made me realize just how much I don't know (and don't know that I don't know!) about the failure modes of distributed systems.
Careful with that word ("ACID"), it's ridiculously easy to get screwed by the filesystem arbitrarily lying about things like the order of system calls: https://queue.acm.org/detail.cfm?id=2801719
To me, systems thinking is all about accepting that _most_ thinking that isn't physics contains interactions that wouldn't pop naturally in the mind during analysis.
So the first step to thinking in systems is the acceptance that there are more interactions out there in the world than what can fit in our mind or what jumps to us through intuition.
I find sketching diagrams helps. I also try to see feedback loops and bottlenecks.
My recommendation would be to try breaking down systems. For example, I do that on my blog:
Gerald Weinberg has several books on the topic [0, 1]. Dorner [2] has a short, sharp, thoughtful book on our biases in analyzing complex systems.
[0] 'An Introduction to General Systems Thinking', Gerald Weinberg
[1] 'General Principles of Systems Design', Gerald Weinberg
[2] 'The Logic Of Failure: Recognizing And Avoiding Error In Complex Situations', Dietrich Dorner
A few cool reads in this area that are varyingly-related to software:
* Architecture of Open Source Applications (http://aosabook.org/en/index.html): always a nice reference for brief overviews of how various OSS projects are architected.
* Counterintuitive Behavior of Social Systems (https://ocw.mit.edu/courses/sloan-school-of-management/15-98...): primarily an argument by Jay Forrester (the "father" of system dynamics) for using computer models to test social policy changes, but also serves as a primer for how systems are complicated, and how to approach reasoning about complex systems.
I find the visibly distinct split in recommendations to be fascinating.
Of the books I've read, Sterman's Business Dynamics: Systems Thinking and Modeling for a Complex World is the best all-round introduction to both the theory and practice of systems thinking.
There are a lot of books and as a family of related fields, systems have historically attracted creative and iconoclastic thinkers. That can be fun, but also frustrating. I think Sterman strikes the right balance.
It can be surprisingly difficult to lay your hands on a copy; Amazon tends to list 2nd-hand copies at high prices ($200+). I waited several years before seeing one on sale for $90.
As an aside, I see that while amazon.com currently lists them quite highly priced right now, alibris.com can find some much cheaper versions. Second hand prices on amazon are sometimes surprisingly high, and sometimes, their new prices too - I routinely check bookdepository, wordery, booksplea.se, agreatread, thriftbooks, abebooks and alibris - each of them bests the others and Amazon frequently enough to keep checking them all. My list of sites to check is UK focused, but I expect there are US equivalents.
Looks like alibris will do a copy of the book in question for a bit under 20 USD as I type, with some searching around.
I can only support the recommendation. It not only has good insights on systems thinking, it also pays a lot of attention on communicating systems thinking and recommendations based on it to others since, as a rule, to get any meaningful changes done at least half of the work is convincing other people.
Abebooks lists several copies in the 20-25 USD price range though. Some even with CD-Rom... they all seem to be “International Edition” whatever this means.
"International Edition" generally means printed significantly more cheaply, and not intended for sale within "rich countries"; generally countries where they can realistically push the expensive version. International Editions often say on them "Not for sale in the US" or some such, depending on the publisher; they sell in poorer countries at a lower price.
The quality is often, in my experience, significantly lower; the paper is thinner, the ink cheaper, sometimes the alignment of the printing is a little off. Colour plates are missing or decoloured, hardbacks become softbacks, and so on. But, the words are the same, and sometimes the International Edition is actually pretty reasonable quality. I've got some that are clearly pretty shoddy, and some that you wouldn't actually know were Internationals. I suspect that sometimes publishers don't reprint it cheaply; they just stamp some of them "International Edition, not for sale in countries <x y z>" on it and ship them abroad to sell, much as some semiconductor manufacturers' cheaper chips actually come off the same line as the expensive ones, and then get tweaked (or even just labelled down). A sale is a sale.
Much of the pioneering work in systems theory was done in the 1930-40's by different (but related) groups of academics in the fields of Systems Theory, Cybernetics, as well as Operational Research. Bertalanffy and Wienberg are progenitors of those fields, but I would stick to people like Ashby, who are much better writers. The work they produced is profound and laid the foundation for much of our modern academic disciplines and industrial practices.
There are a lot of fascinating people and fascinating work that came out of those academic groups during that period. They are too many to list, but I would give William Grey Walter and his robotic tortoise's as an example: https://www.youtube.com/watch?v=lLULRlmXkKo
The Santa Fe Institute[0] has some courses, tutorials, and publications[1] mainly, it seems, around complexity science. Complexity science isn't the same as systems theory/science, but most (all?) systems are complex so systems thinking usually necessitates some grasp of complexity. It's probably a good place to start.
They also have short courses on information theory, differential equations, and such.
So, what is a system? A system is a set of things-people, cells, molecules, or whatever-interconnected in such a way that they produce their own pattern of behavior over time. The system may be buffeted,constricted, triggered, or driven by outside forces. But the system's response to these forces is characteristic of itself, and that response is seldom simple in the real world.
Donella H. Meadows. Thinking in Systems: A Primer (Kindle Locations 89-90). Kindle Edition.
This is one of the most important books I've ever read, if you want the way you think about the world to change read it. It's a very short read to.
Yes. So it is systems theory applied in multiple domains, can be used as a framework to understand or model the world around you.
See my other posts.
It is a way of thinking about the world, and contrasts with traditional linear thinking. It is where interaction and interrelationships are understood to drive outcomes and behaviours of the system under study.
In addition to reading about systems thinking, I would recommend actively practicing it. I’ve found that looking for and cataloging abstract patterns has developed my ability to recognize and reason about real-world systems.
Perhaps this would interest only EU hackers .. but I think it’s going to be extremely interesting as a “system design/theory” problem.
There is the GDPR regulation going to kick off in May 2018. Simply put it regulates how an organization has to handle personal data. And that is a huge deal.
The task is: Make the organization GDPR compliant.
Does anyone has a suggestion how to approach such a task from the most general “system design/theory” perspective?
GDPR interests US hackers too. I'm currently working on a SAAS that helps companies manage their data privacy, with GDPR being the main driver. I can't say much about our approach just yet as we're in stealth mode still, but imho the approach should be centered around awareness of what, where, and how data is stored. That's the very first step.
I'd read books that contain case studies of systemic phenomena. Like books on evolution (I'd recommend those by Dawkins and Dennett) or economics (even something like the Planet Money podcast). Reading about specific cases is good for honing your intuitions about systems, which is important for being able to think in systemic terms.
I don't know your background but I also think learning programming is valuable.
It is an introduction to NetLogo (a free simulation software and a Programming Language), but in hindsight I think the couse and the book teach some useful concepts.
I recommend looking into anything around processes or process-building/management, project management, how incentives work, and how the brain works. The natural world and the corporate world are great examples of systems in action.
Checklist Manifesto is a great (and short/easy) read that I also recommend, but I don't think it's going to be especially helpful to someone looking for techniques to develop new systems thinking models.
At most, it's a recounting of someone else's very specific systems work that has some unexpectedly strong outcomes from surprisingly simple drivers.
Science, Strategy and War covers the OODA loop which has a lot of similarities with systems thinking which I found useful in terms of orienting business and attacking problems.
I highly recommend this now free book: https://www.gilb.com/p/competitive-engineering
A metric-based approach to systems engineering focused on continuous improvement and adding value.
- design a QA process for a software product. How important is "blame" vs team learning? What are the tradeoffs of a blame-oriented approach vs a systems oriented approach?
- build something using AWS or App Engine infrastructure that makes you have to work around the various constraints imposed by the system designers. Consider how to make a system reliable when building it using "unreliable" services.
- consider a Marxist interpretation of the US legal system. I'd argue that it constitutes a reasonable systems oriented critique, and makes it clear how (at least for me) pre-existing biases made it at first seem absurd. I suggest this mainly to highlight how biases can impact systems thinking. The QA process example is also deeply emotionally charged for many engineers but should not be.
I don't have any specific links, but ISTR that INCOSE has a lot of publications & recommended practices, etc. However, nothing beats working with an experienced Systems Engineer (as in: someone with a degree in Systems Engineering who has practiced it for many years) if you have the opportunity. I learned something every day working with those guys.
This is a bit of a non answer, but there was an early MOOC delivered on this topic. I remember this was back in 2010/2011 and the topic was System Thinking.
The course was delivered by a political scientist, but focused entirely on systems thinking.
I will look for it and return;
But for now I don't have the name of the course, or the university. I can remember is the year :).
A lot of folks liked Just Enough Structured Analysis by Yourdon. Yourdon's methods date back to the 1970's with a lot of real-world application. That approach was also used in at least one high-assurance system (Tenix Data Diode).
Honestly, play a bunch of videogames and pay attention to the mechanics and optimal play strategies. They're doing a fantastic job of giving even young children an extremely deep intuitive understanding of system thinking concepts. Stay away from twitchy multiplayer competition-based games, though, those teach nothing.
Some video games, like SimCity 4, can't be played well without being a systems thinker. Everything connects to everything else in the game. If you change a factor (such as a residential tax property tax rate, or the number of roads in a neighborhood) there will be cascading effects on other game factors (such as city revenues for police, or neighborhood air pollution).
Read 'Domain driven design'. Read about product development and talk to non-technical product owners, CEOs, and so on. One of the major challenges in building functional systems is to understand the domain as that's what going to constrain you in the real life.
Along with Meadows' Thinking in Systems I read Mitchell's Complexity: A Guided Tour, which is just that - a reasonably superficial tour over many examples. It's a very good starting point since it's got a long bibliography.
Do object oriented programming. On the way you'll create systems of objects and with ongoing experience you'll also learn to move the abstraction layer around.
I think while doing this for some time it's a little easier to think about other (real world) problems as systems and you may find parallels between software development and this real world.
- You could spend an entire lifetime learning in this field as many have done.
Types of systems:
Systems can be broken down by multiple dimensions:
- Complex
- simple
- unitary
- pluralist
- coercive
Systems thinking approaches:
- Hard systems thinking
- Systems dynamics
- Cybernetics
- Complexity Theory
- Soft Systems
- Emancipatory systems thinking
- Postmodern systems thinking
Learning More about Systems Thinking:
- A great website is the systems thinker, that covers quite a bit of topics. The articles are actually archives of a newsletter called "The systems thinker" https://thesystemsthinker.com/
- To get an overview of various approaches to systems thinking from an organizational perspective:
I looked up Fisker and it appears he is someone who combined personal austerity with a decent income in order to retire early. A couple of books, a blog, and several interviews, but that's literally all they're about. How are you interpreting "systems thinking"? What's the difference between "systems thinking" and "analysing and making informed decisions according to one's goals"?
Honestly you'd have to read his book or some of his posts on the forum or blog to get a sense of his system thinking. I can't immediately point out any good links though, the book is a good start. It's not so much a personal finance book but about systems and models, I highly recommend it. At least you'd get the sense of what it looks like when a physicist writes a "personal finance book"
Step 1: get out of the habit of thinking “systems” means “computers”. People and processes (not Unix processes!) are the major components of systems in this context.
The box-and-arrows paradigm for systems, built in the 50s and enjoying popularity briefly in the 80s, is overrated, and has been outmoded by the likes of complexity theory. This is due to the fact that box-and-arrows systems like those made by Club of Rome to predict civilizational collapse carry strong assumptions as to the nature and structure of underlying variables and as such become very brittle as the size of the system scales. The norm is not the closed-loop circuit models that initially inspired systems thinking, but open-loop energetic models where any structural element is more like a rarified pattern than an ontological atom.
The result is a discipline that has transformed into managing uncertain outcomes in large heterogeneous models, i.e. complexity theory, rather than reducing everything to balls-and-sticks. Meadows was famous for devising "12 basic places to intervene in a system", nowadays the focus is on hedging bets adequately such that interventions don't catastrophically fuck up.
That said, some of the basic tooling is still flexible enough for basic business problems and some of the old gems are able to explain important concepts found in other fields without getting bogged down in the math.
As much as I love NECSI and Santa Fe Complexity Institute, the way the science is taught is a bit of a grab bag. Way too much emphasis on models that aren't widely applicable to engineering problems, like cellular automata.
Nassim Taleb's collaborations with NESCI are worth their weight, though, and W Brian Arthur out of SFI produces works that I consider actionable for CTOs to get a conceptual handle on their craft. UoM's Scott E Paige is also a good resource on Complex Adaptive Systems in a way that is more unified.
Came here to post Dynamics of Complex Systems. Just the information on renormalization groups and multi-scale behavior makes it worth the time. And it's Free!
Philosophy and Design, I wanted to understand the world in the most general way possible to be flexible enough to adopt to any problem. I also like thinking clearly and being right
If you are a software engineer:
Build a simple database, a simple interpreter, and a simple web application (backend and frontend). Read about “distributed systems”, “devops”, “Conway’s Game Of Life”, and “fractals”. Read about these technologies/techniques (in whatever order is comfortable), how they work, their pros and cons, why they were created, how they compare to alternatives: “TCP”, “Open Sound Control”, “Plan9”, “REST”, “Lisp”, “Erlang”, “Smalltalk”, “Forth”, “Datomic”, “event sourcing”, “reactive programming”, “communicating sequential processes”, “APL”/“J”/“K”, “Ansible”, “jq”, “graph databases”, “Apache Kafka”
The idea is not to become an expert in any of these, but to digest the wisdom that lies in their design and surrounding literature. Each was created after lots of careful thought by brilliant people about how to build sustainable systems.