I've only ever built something that worked by first building a couple of things that didn't. No amount of theory or specification can replace what you learn by actually building and interacting with a system. Accept that there will be a version 2.
Systems Thinking
111–120 of 123 posts
Re: Systems Thinking
#112> 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…
>> 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. I am one of those "battle-scarred twenty-year+ vets" mentioned in the article, currently working on a large project for a multinationa…
pretty crazy that shit like this is still happening in 2026
Re: Systems Thinking
#113> 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…
> 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’m the same. Often the first step is a time-boxed exploration, just trying to make the key pieces work in any way to encounter major blockers as early as possible. No planning, no design, not following any best practices, often all in a single file. Then from there, either refactor/rewrite or just use it as input for planning.
Of course, it requires some discipline to not just yolo the prototype into production when that’s not appropriate.
Re: Systems Thinking
#114Earlier quoted context omitted.
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.)
What's considered chaotic? Multiple causes, hard to track?
Re: Systems Thinking
#115> 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…
> 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…
Exactly. On a yuuge project, I first identify the Risks. Then, evaluate the risks -- can actually be done? In XX time? For YY dollars? with acceptable bugs on 1st version?
It's sort of the old General Eisenhower quote: "In preparing for battle I have always found that plans are useless, but planning is indispensable."
Re: Systems Thinking
#116Earlier quoted context omitted.
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.
Are you trying to add anything to this conversation, or is this a joke?
Re: Systems Thinking
#117Earlier quoted context omitted.
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.
Are you trying to add anything to this conversation, or is this a joke?
I'm saying that you just have to start, even if it's a single line of throw-away code. The learnings along the way will guide you. That's it.
Re: Systems Thinking
#118Earlier quoted context omitted.
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.)
What's considered chaotic? Multiple causes, hard to track?
Consider systems that require continuous active stabilization to not fail because the system has no naturally stable equilibrium state even in theory. Some of our most sophisticated engineering systems have this property e.g. the flight control systems that allow a B-2 bomber to fly. In a software context you see these kinds of design problems in large-scale data infrastructure systems.
The set of system designs that exhibit naturally stable behavior doesn't overlap much with the set of system designs that deliver maximum performance and efficiency. The capability gap between the two can be large but most people choose easy/simple.
There is an enormous amount of low-hanging opportunity here but most people, including engineers, struggle with systems thinking.
Re: Systems Thinking
#119Re: Systems Thinking
#120> 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…
[deleted]