Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systems Thinking

theprogrammersparadox.blogspot.com

Post reply on HN
Print view View original

61–70 of 123 posts

Re: Systems Thinking

#61

Post by sph »

jackblemming wrote: post #27
bestham wrote: post #3

“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

People misinterpret this and think they can incrementally build a skyscraper out of a shed.

That's exactly why software is so bad. No one ever knows their shed would ultimately have to become a skyscraper, and management doesn't allocate any budget to lay stronger foundations when expectations change; you make do with what you have.

See also: "there is nothing more permanent than a temporary solution"

Re: Systems Thinking

#62

Post by samiv »

"It’s not that you could cut the combined complexity in half, but more likely that you could bring it down to at least one-tenth of what it is today, if not even better. It would function better, be more reliable, and would be far more resilient to change. It would likely cost far less and require fewer employees as well. All sorts of ugly problems that they have now would just not exist."

Incidentally this highlights a problem when using chatbots to build large software projects that are intended to be used for a long period of time.

The key is not how much code you can add but how little you can get away with.

Chatbots only solution ever is to ADD code. They're not good at NOT writing code or even deleting it because after all the training set for the lines of code that do not exist is an empty set. Therefore it's impossible to train a robot to not write code.

What's better than generating 10kloc really fast? Not having it in the first place.

Re: Systems Thinking

#63

Post by t43562 »

Big upfront designs are obviously based on big upfront knowledge which nobody has.

When they turn out to be based on false assumptions of simplicity the fallout is that the whole thing can't go forward because of one of the details.

Evolutionary systems at least always work to some degree even if you can look after the fact and decide that there's a lot of redundancy. Ideally you would then refactor the most troublesome pieces.

Re: Systems Thinking

#64

Post by globalnode »

Borrowing from mechanical/electrical etc. Limit the number of things you can build with. An example in the comments here was a gear. You make a new gear based on examples of gears that work. So whats the software equivalent of a gear? an axle, a bearing, etc.. Using OO or some ABI, you specify an object is a gear and behaves like a gear and magically you know how it does or doesnt fit together with other objects. I know this idea has been used before but im wondering if theres a well known software framework or library. We have things like the stl in cpp or built in libraries in python but im thinking of a higher level abstraction.

Re: Systems Thinking

#65

Post by zingar »

I disagree with most of this article, but this part stood out:

> the size of the iterations matters, a whole lot. If they are tiny, it is because you are blindly stumbling forward. If you are not blindly stumbling forward, they should be longer, as it is more effective.

You are not blindly stumbling forward, you're moving from (working software + tiny change) to (working software including change). And repeat. If there's a problem, you learn about it immediately. To me that's the opposite of moving blindly.

> you really should stop and take stock after each iteration.

Who is not taking stock after every iteration? This is one of the fundamental principles of agile/lean/devops/XP/scrum. This one sentence drastically lowers my impression of the author's ability to comment on the subject.

> The faster people code, the more cleanup that is required. The longer you avoid cleaning it up, the worse it gets, on basically an exponential scale.

Unsafe tempo is as likely to happen in big-spec design projects as in small iterations. In fact, working in careful small iterations helps us manage a realistic tempo because we know we can't move faster than we can get things into production and evaluate.

The terrible outcomes listed in the same paragraph are linked to unwise practice and have nothing to do with small iteration size.

Re: Systems Thinking

#67

Post by sigbottle »

zppln wrote: post #22
readthenotes1 wrote: post #2

A major factor supporting evolution over big up-front design is the drift in system requirements over time. Even on large military like projects, apparently there's "discovery"--and the more years that pass, the more requirements change.

This isn't my experience. Requirements tend to settle over time (unless they're stupidly written). Users tend to like things to stay the same, with perhaps some improvement to performance here and there. But if anything, all development is the search for the search for the requirements. Some just value writing them down.

Completely irrelevant but this exchange reminded me of two Greek philosophers saying "everything is change" versus "nothing ever changes" LOL

Re: Systems Thinking

#68

Post by zingar »

qznc wrote: post #33

I find the title misleading. While the author is "thinking about systems", this is not about https://en.wikipedia.org/wiki/Systems_thinking

100%. I came here to find something new from a field that I don't know but imagine has some good lessons for software. Instead I found someone commenting on small iterations vs big design which is quite ho-hum by comparison.

Re: Systems Thinking

#69

Post by t43562 »

jonathanlydall wrote: post #36

Lots of wisdom in this post about some of the realities of software development. The core point they're trying to make is that agile (or similar) practices are the incorrect way to approach consolidation of smaller systems into bigger ones when the overall system already works and is very large. I agree with their assertion that being forced to address difficult problems earlier on in the process results in ultimatel…

> "writing code" is one of the easiest parts of the job. The hard part is knowing what code needs to be written.

I highly applaud this idea. IMO this is why big upfront design is so risky.

Re: Systems Thinking

#70

Post by skydhash »

globalnode wrote: post #64

Borrowing from mechanical/electrical etc. Limit the number of things you can build with. An example in the comments here was a gear. You make a new gear based on examples of gears that work. So whats the software equivalent of a gear? an axle, a bearing, etc.. Using OO or some ABI, you specify an object is a gear and behaves like a gear and magically you know how it does or doesnt fit together with other objects. I k…

> if theres a well known software framework or library

Those are called data/structures and design patterns (not only the ones in the GoF book). If you have a good understanding of those and you know your data and the operation you will apply to it, it’s easy to model your data using those structures. Software are state machines specifications. Knowing how to model states and thus figuring the transitions is helpful. And there’s a lot of samples out there.

Post reply on HN