Let's point the elephant in the room: you won't be able to create any relevant system by specializing in "systems thinking".
Systems Thinking
101–110 of 123 posts
Re: Systems Thinking
#102Earlier quoted context omitted.
The definition of a complex system is the qualifier for the quote. Many systems that are designed, implemented and found working are not complex systems. They may be complicated systems. To paraphrase Dr. Richard I. Cook’s ”How Complex Systems Fail” where he claims that complex systems are inherently hazardous, operate near the edge of failure and cannot be understood by analyzing individual components. These systems…
Then what precisely is the definition of complex? If "complex" just means "not designed", then the original quote that complex systems can't be designed is true but circular. If the definition of "complex" is instead something more like "a system of services that interact", "prone to multiple, coincidental failures", then I don't think it's impossible to design them. It's just very hard. Manufacturing lines would be…
A complex system is one that has chaotic behavior.
(And no, this is not "my" definition, it's how it's defined in the systems-related disciplines.)
Re: Systems Thinking
#103Earlier quoted context omitted.
I've seen some issue with this approach is that management will want to sell the prototype, bypassing the "rewrite from the lesson learned" step, and then every shortcut took into the prototype will bite you, a lot .. And things like "race conditions"/lack of scalability due to improper threading architecture aren't especially easy to fix(!)..
You don't ever make the prototype public. Also, there's a certain point where you can't avoid management sabotaging things.
Sometimes you don't know what needs to be built until you build it. These end-to-end prototypes are how to enhance your understanding and develop deeper intuition about possibilities, where risks lie, etc.
Re: Systems Thinking
#104“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” Gall’s Law
Some systems require a total commitment to the complexity because it is intrinsic. There is no "simple" form that also works, even if poorly. In many contexts, "systems thinking" is explicitly about the design of systems that are not reducible to simpler subsystems, which does come up in many types of engineering. Sometimes you have to eat the whole elephant. There is a related phenomenon in some types of software wh…
This is the point we are at now with wide-scale societal technologies; combining the need for network effects with the product being the prototype, and no option but to work on the system live.
Some projects have been forced so far, by diverting resources (either public-funded or not-yet-profitable VC money), but these efforts have not proven to be self-sustaining. Humans will be perpetually stuck where we are as a species if we cannot integrate the currently opposing ideas of up-front planning vs. move fast and break things.
Society is slowly realizing the step-change in difficulty between projects in controlled conditions that can have simplified models to these irreducibly complex systems. Western doctors are facing an interesting parallel, now becoming more aware to treat human beings in the same way--that we emerge as a result of parts which can be simplified and understood, but could never describe the overall system behavior. We are good examples of the intrinsic fault-tolerance required for such systems to remain stable.
Re: Systems Thinking
#105Earlier quoted context omitted.
People misinterpret this and think they can incrementally build a skyscraper out of a shed.
That's what happened though? First humans built sheds, then we built 2-story buildings, then taller and taller, until we built skyscrapers. Obviously it wasn't a single structure, but we did have to evolve our thinking on how to build things, we didn't just start building a skyscraper before we built a shed.
to put it in another way than the other replies: you will have 100x more pushback to an arguably-necessary ground-up rewrite instead of "just add this new feature to the existing codebase", even when you (as an engineer) know full well why "just adding a feature" is probably a bad idea.
Re: Systems Thinking
#106Earlier quoted context omitted.
> A lot of software people like to jump in and I see them portray the planning people as trying to figure everything out first. My approach, especially for a project with a lot of unknowns, is usually to jump in right away and try to build a prototype. Then iterate a few times. If it's a small enough thing, a few iterations is enough to have a good result. If it's something bigger, this is the point where it's worth…
I've seen some issue with this approach is that management will want to sell the prototype, bypassing the "rewrite from the lesson learned" step, and then every shortcut took into the prototype will bite you, a lot .. And things like "race conditions"/lack of scalability due to improper threading architecture aren't especially easy to fix(!)..
The Anna Karenina principle looms large in software engineer projects. Basically there are an infinite failure modes that can occur due to small actions or wrong thinking by one or more influential people, but there is only one way to make large projects successful. Basically the team has to have sufficient expertise to cover the surface area, and those individuals need enough trust from leadership to navigate the million known and unknown pitfalls that await.
Re: Systems Thinking
#107Earlier quoted context omitted.
It’s actually the opposite - you actually can. The feel I'm getting reading anti-AI sentiment is people are expect one shot results out of limited context.
I'm pretty sure that you can't gradually upgrade a shed into a skyscraper unless you pour a skyscraper-ready foundation before even starting on the shed. But if you're doing that, why start with a shed and not with a skyscraper? Not sure why you're trying to bring AI development into this.
You can, start by clearing and grading the site - get a shed up over your head. Then you can start then start the skyscraper next to it and work out of the shed.
Re: Systems Thinking
#108[deleted]
Re: Systems Thinking
#109you don’t build specifications, you build models like you would in model-based systems engineering, and then you follow the V-model process.
In fact, this is how you build an aerospace program, satelite, and more.
It is even possible to develop software with agile processes in such a framework, even though strictly speaking it’s not fully agile.
Re: Systems Thinking
#110> you lay out a huge specification that would fully work through all of the complexity in advance, then build it. This has never happened and never will. You simply are not omniscient. Even if you're smart enough to figure everything out the requirements will change underneath you. But I do still think there's a lot of value into coming up with a good plan before jumping in. A lot of software people like to jump in a…
Indeed. And writing out a design is actually a good method for thinking through the design. It helps uncover assumptions, including those that are flawed. It allows you to weigh various design options explicitly. It provides a place for identifying and resolving ambiguity and lack of clarity in the requirements. Contracts can be distilled in the process. Such design docs can also focus and direct implementation; you have a clearer picture of the parts and contours of your system. In a way, it is like programming, but at a conceptually higher, architectural level, where you work through and chew on the thing to flesh out and validate it in the very act of specifying.
And by doing this sort of exercise, you can avoid wasting time on dead ends, bad design, and directionless implementation. It's okay if requirements change or you discover something later on that requires rethinking. The point is to make your thinking more robust. You can always amend a design document and fill in relevant details later.
Furthermore, a mature design begins with the assumption that requirements (whether actual requirements or knowledge of them) may change. That will inform a design where you don't paint yourself into a corner, that is flexible enough to be adapted (naturally, if requirements change too dramatically, then we're not really talking about adaptation of a product, but a whole new product).
How much upfront design work you should do will depend on the project, of course. So there's a middle way between the caricature of waterfall and the caricature of agile.