What an interesting and strange article. The author barely offers a definition of "systems thinking", only names one person to represent it, and then claims to refute the whole discipline based on a single incorrect prediction and the fact that government is bad at software projects. It's not clear what positive suggestions this article offers except to always disregard regulation and build your own thing from scratch, which is ... certainly consistent with the Works In Progress imprint.
The way I learned "systems thinking" explicitly includes the perspectives this article offers to refute it - a system model is useful but only a model, it is better used to understand an existing system than to design a new one, assume the system will react to resist intervention. I've found this definition of systems thinking extremely useful as a way to look reductively at a complex system - e.g. we keep investing in quality but having more outages anyway, maybe something is optimizing for the wrong goal - and intervene to shift behaviour without tearing down the whole thing, something this article dismisses as impossible.
The author and I would agree on Gall's Law. But the author's conclusion to "start with a simple system that works" commits the same hubris that the article, and Gall, warn against - how do you know the "simple" system you design will work, or will be simple? You can't know either of those things just by being clever. You have to see the system working in reality, and you have to see if the simplicity you imagined actually corresponds to how it works in reality. Gall's Law isn't saying "if you start simple it will work", it's saying "if it doesn't work then adding complexity won't fix it".
This article reads a bit like the author has encountered resistance from people in the past from people who cited "systems thinking" as the reason for their resistance, and so the author wants to discredit that term. Maybe the term means different things to different people, or it's been used in bad faith. But what the article attacks isn't systems thinking as I know it, more like high modernism. The author and systems thinking might get along quite well if they ever actually met.
I didn't feel like he was refuting the whole discipline. Rather, he seems to admire Forrester and the whole discipline. The argument just seems to be, even with great systems thinking, you can't build a complex system from scratch and that existing complex systems are often hard to fix.
Couldn't one interpret "magical systems thinking" as a fallacy that people may commit when applying systems thinking? More broadly, I find some of the comments here rather harsh, also considering that many observations in the article are intuitively true for anyone whose ever been exposed to bureaucracy on the meta-level.
One could interpret the title that way, but not consistently with the rest of the article, which includes assertions like "in the realm of societies, governments and economies, systems thinking becomes a liability".
I think there's plenty to agree with in the article's descriptions of failure and hubris. What the critical commenters are taking issue with is that the article blames those symptoms on a straw man. It's a persuasive article, not a historical review, so it's reasonable to debate its conclusion and reasoning as well as its supporting evidence.
Exactly, it's a fallacy of systems thinking but it's not intrinsic to it. In fact, system thinkers tend to understand that complex systems, are, well, complex and not easy to reason about.
There is something about Club of Rome to systems thinking that is similar to the Dijkstra's observation about Basic and programming.
Articles debunking them are always full of fundamental misunderstandings about the discipline. (The ones supporting them are obviously wrong.) And people focusing on understanding the discipline never actually refer to them in any way.
Yeah, what they are attempting mg to do in the span of one short essay is equivalent to trying to discredit an entire field of inquiry. Even if you don't think the field is worth anything, it should be obvious that it will take a lot of research and significant argumentation to accomplish that goal, this essay is lacking in both departments.
Maybe anecdotal, but in solution design I have often encountered designs that try to be generic for the sake of generality, also designs that complicate a simple repeatable task to accommodate arbitrary potential complications. I would argue that in many cases we like to introduce complexity to feel like we are doing something advanced. I like to design systems with a view that they do one thing only and that thing right but there is, to your point, arbitrariness and art and judgement in deciding the thing.
Applying the idea of "starting with a simple system that works"̀ to Factorio, Shapez (and now Shapez 2) is like Factorio for abstract geometric shapes and colors.
It's got all the essential elements of Factorio that make it so interesting and compelling, which apply to so many other fields from VLSI design to networking to cloud computing.
But you mine shapes and colors and combine them into progressively more complex patterns!
> The author barely offers a definition of "systems thinking", only names one person to represent it, and then claims to refute the whole discipline based on a single incorrect prediction and the fact that government is bad at software projects.
All valid criticisms, but somehow it sounds exactly like something a member of inept bureaucracy would say.
This seems lazy. It's ad hominem but not even, since you don't know what inept bureaucracy I am defending. Is there any argument that you couldn't level this accusation at?
Apologies. It wasn't intended as ad hominem. I was just describing general vibe of your comment, at least how I perceived it.
When inept bureaucracy is put in the spotlight usually someone pops up to defend how much of important work they are doing and how the things they deal with are just so complicated. And how criticisms are unfair and unfounded.
> assume the system will react to resist intervention
Systems don't do that. Only constituents who fear particular consequences do.
Systems also don't care about levels of complexity. Especially since it's insanely hard to actually break systems that are held together by only the "what the fuck is going on, let's look into that" kind. Hours, days, weeks, later, things run again. BILLIONS lost. Oh, we wish ...
At the end of the day, the term Systems Thinking is overloaded by all the parts that have been invented by so called economists and "the financial industry", which makes me chuckle every time now that it's 2025 and oil rich countries have been in development for decades, the advertisement industry is factory farming content creators and economists and multi-billionaires want more tikktoccc and instagwam to get into the backs of teen heads.
If you are a SWE, systems architect or anything in that sphere, please, ... act like you care about the people you are building for ... take some time off if you can and take care of must be taken care of, ... it's just systems, after all.
You make a fine point. My simplified version of it is that there is no such thing as an isolated system. Things change. A system optimized for one environment is likely to fail when things change. Most of the hugely successful firms of today focus more on controlling their environment than on developing a capacity to adapt to unforeseeable consequences of unforeseen changes in their environment, even the ones that they cause themselves.
I think we were not using the same definition of “system” :)
> there is no such thing as an isolated system.
Very true.
Look no further than evolutionary biology, you see this all the time where extinctions occur because the environment changes such that the system is no longer optimal.
> where extinctions occur because the environment changes such that the system is no longer optimal
What if we looked at the extinct species as constituents that have been removed because they were obsolete in the system? That way, the system remains optimal, without resisting change.
The system of humanity requires a lot. We used to say "survival of the fittest", which meant survival of the fittest and the "most aware", meaning being able to distinguish which survival strategy is the most viable for a given organism.
Fight, flight, freeze, dominance, independence, submission, DIY, DOBUY; the latter are especially interesting given how reduced information about the requirements and the sensitivities of the individual body can cripple your organs to a point that is more beneficial for some interest group than it is to you; in other words: someone can make sure you are stupid enough to be abused for some specific task until you can be discarded of. At this point we don't know if the system will survive more than one period because of the interest group or suffer within one or more periods because of that interest group.
In evolutionary biology, more symbiotic organisms and systems survived a lot longer that those who were less symbiotic, on scales that modern humans can't put into adequate numbers yet.
Isolated systems do exist. They can be isolated and they can self-isolate for various reasons and by various means. This happens even in species/systems we mostly consider mostly unconscious while definitely sentient and aware.
Wear and tear and maintenance, leeching and seeding, putting info and questions into words and lurking; none of these really attach a system to another by default, by design or via behavior, reward and punishment. The rules go beyond that and stretch longer time frames than we account for.
The article seems to think that systems thinking only applies at a certain lower scale. Even bringing up the bullwhip effect, and talking about it in certain kinds of systems is itself systems thinking, just not at the subcomponent level which doesn't show it. Systems thinking is about interactions and context.
Where are the limits of optimization? There are no such things as "systems", these are arbitrary concepts. Where does any system end? Odum learned the hard way and I suspect CS is simply models of models that hide the interconnected nature as a way of isolating values, making money, and claiming the system works.
The deeper question is why create models of a reality in which all models are wrong, but some extract value long enough to create both ecological collapse and poverty? These are the end states or even goals of models in a universe with limited resources to surfaces of planets.
Each optimization is designed to create dystopic conditions. This is obvious.
I'm sorry this is happening to you and to your friend. I have some similar experience and want to share some advice I wish I had heard earlier.
It sounds to me like you did the right thing - situations like this can get worse if left unchecked and have serious consequences for the person in question and those around them. I'm not diagnosing your friend - I'm no expert, and various disorders can have those symptoms - but there are resources out there about (e.g.) mood disorders [1] that might give you some perspective and advice.
Treatment can help, and can make a huge difference. Hospitals are unpleasant but can sometimes be the only way for someone who needs treatment to receive it. I am certainly no legal expert, but I think if he was forcibly committed to a hospital and police were involved, he's unlikely to be released without accepting treatment.
You might find it helpful to join a support group for caregivers (e.g. [2]). In my experience it's common for friends as well as family members to attend those. People will offer resources and advice, as well as just sharing their experience, which can provide perspective and help with feeling lost.
Also consider (if you're not already) finding a therapist of your own. People in one of these episodes can push boundaries, say things to you they wouldn't normally mean, and generally be hard to be around while maintaining your own health and boundaries - particularly if you're invested in trying to help them.
That is the part I do not understand. I have never agreed with any health professionals to be part of his ongoing care. I suspect his family may have done so, but are abandoning their responsibility?
He had agreed to let me visit him in hospital very shortly, before he is discharged. I intend to make it very clear to the staff that I have not agreed to have any official role in his ongoing help.
You're right, you're not his caregiver, or obliged to be. Sorry if it sounded like I was suggesting that.
I doubt the staff would expect or pressure you to take responsibility for him. If anything you might have trouble getting them to even discuss his case with you - different states vary but in some cases they won't share case details without explicit permission from the patient. (If that sounds frustrating given your first hand experience of his symptoms and their progression - I sympathise.)
The support groups in particular may be useful despite that, just because you mentioned he's a housemate, so he may continue to be in your life. When I attended there were spouses, parents, but also just friends who wanted to help out their friend and understand what they were going through, without adopting responsibility for them.
This makes some good points about misuses of these AWS services, but the title is misleading. The article is actually more like "tempting but inadvisable use cases for AWS services".
My employer uses three of these heavily (ElastiCache, Kinesis and Lambda) and we get quite a bit of leverage out of them.
ElastiCache in particular surprised me. At first glance I mistook it for a transparent (and expensive) wrapper around sticking Redis on an EC2 instance, but if your usage is heavy enough to need multi-node clusters (e.g. read replicas or full Redis Cluster), its orchestration features are pretty useful. We can resize instances, fail over to a replica, and reshard clusters, with zero downtime, by clicking a button (or a one-line Terraform change). And never having to install security patches is nice too.
It certainly is expensive, though. (But if you're not willing to pay a premium for managed infra, what are you doing on AWS in the first place?)
I may have lost people with lower confidence in their abilities and a greater fear of failure.
That HBR article I linked in the other thread actually addresses that. Their survey indicates that people are deterred less by lack of confidence in their abilities, and more by lack of confidence in your process to assess their abilities in the absence of a credential. The top-given reason (from both women and men) for not applying was “I didn’t think they would hire me since I didn’t meet the qualifications, and I didn’t want to waste my time and energy.”
Now maybe you're actively looking for people who hustle and won't take no for an answer (which isn't quite the same thing as "confident in their abilities"). Maybe that's your team culture, or your company culture. That's certainly your choice if so.
There is a lot of projection going on here. The simple statement that the requirements are not always (or even often) hard factors that can never be overridden should not be controversial in the least. That's true in all aspects of life.
So if you don't have a degree, you probably shouldn't let that hold you back. And maybe because you don't have a degree you should hustle a bit more than those who do. Again, that shouldn't be controversial.
In case you're not aware, there is evidence [1] that this sort of "required but not really" job posting deters a lot of people, and especially women, from applying even if they would actually meet the (unstated) actual requirements.
Making it explicit that you will accept "experience and a good resume" in place of a CS degree might increase the diversity of your applicant pool.
Why would I waste my time applying if it specifically states a CS degree is required? If you don't REQUIRE it, state that. It's not encouraging at all.
Last time I was applying for work, I sent out 150 applications/resumes, every single one I look at the list of requirements, if I don't meet one of them, I don't apply because it's a waste of my time.
I telling you exactly why! Certainly anyone who doesn't meet the requirements might not necessarily be considered. But if you meet 90% of the requirements and that last 10% is not having a degree, so what? Why not let the company decide not to hire you instead of you deciding for them in advance?
Sending in a resume or filling out an application is pretty low risk. If a company absolutely won't hire you without a degree, you just won't hear back. Big deal.
It's good advice, but I think the reverse advice is also true. As much as people are missing good opportunities because they don't apply for jobs they think they might not be qualified for, you are missing good candidates by not asking for what you actually want.
I would just say, "Degree in CS related area or related experience highly desirable".
I asked for what I want -- if the candidate doesn't have that, it's up to them to sell me on why they'd be a good choice anyway. I want $100 but I might be willing to settle for $90 and a really nice cookie. I might even prefer that cookie but I don't know what cookie you have. It could be fantastic and worth way more than $10. Or maybe not.
I once got a job with zero qualifications for it -- in fact, the interview was almost entirely just me asking the interviewers how to do the job! They had other applicants but I guess my total and complete lack of experience didn't scare them off. The job was initially daunting but otherwise a fantastic experience overall.
Because HR and recruiters were involved what gets posted is a very rough approximation to the real requirements. Heck many places I've worked we would invent a job for someone who applied for a different one for which they weren't a good fit.
Confidence in one's job skills and confidence in other people’s willingness to disregard what they describe as “requirements” are not necessarily linked.
I have 2 fortune 500 companies, one of which is fortune 100, and many large companies including fintech on my resume. I don’t have a fear of my skills or anything, but I do know I don’t have a degree. Guess what, you state that you need a degree, I will skip your job.
You were a little more direct than I would have been, but I was thinking the same thing. Basically ignore the job posting/resume process, or just work with it only as much as you need to in order to get in front of someone with hiring powers.
Also, remember that the people who actually decide who to hire are often as frustrated with the process and its artificiality as the applicants.
And kudos for doing that - but what about candidates who don't read Hacker News (or happened not to see this exact thread)? HN isn't exactly the most welcoming environment for women either.
There's a balance point. When I did interviewing at FANG.Co I would occasionally just get people that were severely under qualified for the role. It might be a large swatch filter but the degree requirement does reduce the number of those applicants and time lost by devs doing technical interviews.
technical interviews are the worst thing ever. They prove nothing except that a candidate crammed for you exam and/or work well while being watched. I can't imagine either of those are useful.
I did an interview with one of the FAANG.Co once and ended up arguing with the technical interviewer because he was a douche. When I found out he would have been on my team I told the recruiter I wasn't interested anymore. They ended up turning me down anyway because I didn't get along with the guy. Basically he was asking me to implement a JSON parser in brainfuck, not a legit use for either of our time.
That's a myopic and emotionally charged way of looking at it.
When I interview people, I ask straight forward, probing questions looking for how the candidate approaches the problem and the path they take to the solution. I don't ask trick questions, I don't mislead the candidate, and I help them as much as I can to get to a solution on their own. However, I look for and probe for information throughout the process. It's relatively easy to discern whether someone knows what they're talking about and can apply it versus someone who crammed for the interview. Moreover, if someone did cram for the interview and was able to apply the knowledge that quickly - great, I want to work with people like that.
Had someone asked me to implement a JSON parser in brainfuck - I would have got up and left. More generally - if someone asks me to use a _specific_ language in an interview; it's not someplace aware enough to know that 99% of the time the language is unimportant and not somewhere I want to work.
With all that being said - technical interviews are not "the worst thing ever". They serve a vitally important task of ensuring I work with competent and personable people.
> That's a myopic and emotionally charged way of looking at it.
sure is emotionally charged, but I don't know that it is myopic. I have thought many many years about the contents of a technical interview. Taking a step back from the argument I recall decades ago noticing that, I believe it was the bureau of labor statics, software programmers are considered "unskilled technical labor." I was initially offended by this. I have now come to the realization that this is generally true. Skill is not required to make software, nearly anyone can do it. Leading back to the argument though, what makes someone good at being a software developer is not technical skills. It is general competency, critical thinking, and being a good communicator.
> Had someone asked me to implement a JSON parser in brainfuck - I would have got up and left. More generally - if someone asks me to use a _specific_ language in an interview; it's not someplace aware enough to know that 99% of the time the language is unimportant and not somewhere I want to work.
to be fair that wasn't the exact request. It was more along the lines of "using whatever (approved) language you'd like, implement x with that assumption that your base language can only loop and increment." x in this case was something like do division. Which I know is possible, but also something I would never need to do and as such the solution wasn't immediately available to my brain.
> With all that being said - technical interviews are not "the worst thing ever". They serve a vitally important task of ensuring I work with competent and personable people.
was definitely hyperbole, but my point is that a technical interview doesn't serve the purpose that you lay out for them being vitally important. A non-technical interview is far better and easier to evaluate a persons competency, problem solving, communication, and "personable people".
Point being an entry level person with competency and problem solving skills can be taught technical skills very quickly and/or learn as they go. Non-entry level, well, their resume should tell you they have the technical skills assuming their references check out. So I really think we should stop wasting time and talent on "technical interviews"
> to be fair that wasn't the exact request. It was more along the lines of "using whatever (approved) language you'd like, implement x with that assumption that your base language can only loop and increment." x in this case was something like do division. Which I know is possible, but also something I would never need to do and as such the solution wasn't immediately available to my brain.
This sounds like a great interview question. It calls on the candidate to show they understand what a turning complete system is and then put that knowledge into practice to create the fundamental building blocks that are normally given to you.
You used hyperbole to make it out to be something it definitely wasn't.
> Which I know is possible, but also something I would never need to do and as such the solution wasn't immediately available to my brain.
In fact, you do need to do it, you needed to do it for an interview. The fact that you see it that way might underscore a personality trait that the interviewers might not have liked. Thus giving credence to the interview process immediately.
> A non-technical interview is far better and easier to evaluate a persons competency, problem solving, communication, and "personable people".
No it's not. It's far better at providing a "comfortable" place for someone to chat without actually proving anything. A good technical interview is problem solving _with_ time to chat and prove understanding of concepts.
> Point being an entry level person with competency and problem solving skills can be taught technical skills very quickly and/or learn as they go.
This is clearly false otherwise we wouldn't be starved for competent technical candidates. There're thousands of companies looking for qualified candidates and they can't find them.
> their resume should tell you they have the technical skills assuming their references check out. So I really think we should stop wasting time and talent on "technical interviews"
Resumes are worthless - doubly so now that politicians have made lying OK. The majority of people I've interviewed lied on their resumes, either as small white lies, or as large ones. And personal references are also garbage - there was a recent radio host that called random numbers and asked for a "reference" for a candidate they were interviewing. People went out of their way to talk up the fictional candidate.
> Leading back to the argument though, what makes someone good at being a software developer is not technical skills. It is general competency, critical thinking, and being a good communicator.
Yes to critical thinking and communication. You just aren't going to get a good read on a candidate without asking thought-invoking questions. You've either never had a good interview or you don't interview well and disparage the process to feel better.
That's the "monitor from the customer's point of view" approach the OP alludes to. If you use tools like Honeycomb [1] that can easily and routinely answer questions like "show me the 95th percentile latencies for each of the 10 customers experiencing the worst latencies", then situations like you're describing are a lot easier to discover.
>That's the "monitor from the customer's point of view" approach the OP alludes to.
...but now you're in a recursive problem: Who watches the watcher? If the watcher goes down, your insights are gone. Do you devote your entire engineering staff to monitoring, then?
A two-pronged approach would be better: Customer Touch-Point monitoring built into your product and external monitoring should your CTP monitoring go down. If your external monitoring goes down, you still have the CTP, so not all visibility is lost.
The glowing tower contains molten salt, used to store the focused solar energy. [1] I never knew that was a thing until I too drove past it. It was one of the more memorable sights on a 3000 mile road trip.
The way I learned "systems thinking" explicitly includes the perspectives this article offers to refute it - a system model is useful but only a model, it is better used to understand an existing system than to design a new one, assume the system will react to resist intervention. I've found this definition of systems thinking extremely useful as a way to look reductively at a complex system - e.g. we keep investing in quality but having more outages anyway, maybe something is optimizing for the wrong goal - and intervene to shift behaviour without tearing down the whole thing, something this article dismisses as impossible.
The author and I would agree on Gall's Law. But the author's conclusion to "start with a simple system that works" commits the same hubris that the article, and Gall, warn against - how do you know the "simple" system you design will work, or will be simple? You can't know either of those things just by being clever. You have to see the system working in reality, and you have to see if the simplicity you imagined actually corresponds to how it works in reality. Gall's Law isn't saying "if you start simple it will work", it's saying "if it doesn't work then adding complexity won't fix it".
This article reads a bit like the author has encountered resistance from people in the past from people who cited "systems thinking" as the reason for their resistance, and so the author wants to discredit that term. Maybe the term means different things to different people, or it's been used in bad faith. But what the article attacks isn't systems thinking as I know it, more like high modernism. The author and systems thinking might get along quite well if they ever actually met.