5 ms·

Great article. Recalls Gall's Law[1]. "A complex system that works is invariably found to have evolved from a simple system that worked." Also, TFA invites a

Great article. Recalls Gall's Law[1]. "A complex system that works is invariably found to have evolved from a simple system that worked." Also, TFA invites a question: if handed a big ball of mud, is it riskier to start from scratch and go for something more triumphant, or try to evolve the mud gradually? I favor the former, but am quite often wrong. [1] https://en.m.wikiquote.org/wiki/John_Gall https://en.m.wikiquote.org/wiki/John_Gall

deleted 7y ago
[deleted]
MisterTea 7y ago
One of my favorites: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. — C.A.R. Hoare, The 1980 ACM Turing Award Lecture
smacktoward 7y ago
Yep, my first thought upon reading this was that no discussion of this subject is complete without a perusal of Gall's Systemantics (https://en.wikipedia.org/wiki/Systemantics https://en.wikipedia.org/wiki/Systemantics).
- deleted 7y ago
  [deleted]
- gentleman11 7y ago
  > It is offered from the perspective of how not to design systems, based on system engineering failures. The primary precept of treatise is that large complex systems are extremely difficult to design correctly despite best intentions, so care must be taken to design smaller, less-complex systems and to do so with incremental functionality based on close and continual touch with user needs and measures of effectiveness. I am working on my first game using unity right now and I wholeheartedly agree. Almost all of my effective refactoring is turning interacting systems into standalone chunks that don’t care about the rest of the system It’s very hard to do. I imagine my 4th game will go far smoother after I figure out what works and what doesn’t
ssivark 7y ago
> if handed a big ball of mud, is it riskier to start from scratch and go for something more triumphant, or try to evolve the mud gradually? Reminiscent of Chesterton’s fence. But then, we end up in such a “complex” situation only when one thing can have multiple causes & effects — which is difficult to model correctly in a clean slate formulation. The simplest solution seems to be to avoid making software that complex in the first place (we can exert far more control than in the physical world). But then if we think about Peter Naur’s perspective about programming as a mode of theory building (of the domain) (unsurprising, given the basic cybernetics principles such as the law of requisite variety & the good regulator theorem), then the answer seems to be — unless your domain is really complex, think hard before you implement, and keep refactoring as your understanding improves (and truly to pick problem formulations / frameworks / languages which make that feasible. Of course, easier said than done.) The key point is to keep refactoring “continuously“ to match our understanding of the domain, rather than just “adding features”. Aside: In my experience, software built on a good understanding of the domain will function well, untouched, for a long time — so long as it is suitably decoupled from the less-well-understood parts. The latter kind, though, generates constant churn, while also being an annoying fit. Really brings home the adage “A month in the laboratory can save a day in the library.”
- heavenlyblue 7y ago
  > But then, we end up in such a “complex” situation only when one thing can have multiple causes & effects — which is difficult to model correctly in a clean slate formulation. This is why you should keep paying your employees that worked for the company for years, having written all of the mediocre code when they still could not program well at all.
- BurningFrog 7y ago
  > The key point is to keep refactoring “continuously“ to match our understanding of the domain, rather than just “adding features”. This is also what I wanted to say. One important part of that is that refactoring is a pretty difficult skill, and many programmers do not have it. So... for those people, some other advice is probably better.
h_r 7y ago
With respect to evolving balls of mud, the only thing that mostly worked for me is to try to find those boundaries where you can apply the [Strangler Pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler https://docs.microsoft.com/en-us/azure/architecture/patterns...)

deleted 7y ago

[deleted]

MisterTea 7y ago

One of my favorites: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. — C.A.R. Hoare, The 1980 ACM Turing Award Lecture

smacktoward 7y ago

Yep, my first thought upon reading this was that no discussion of this subject is complete without a perusal of Gall's Systemantics (https://en.wikipedia.org/wiki/Systemantics https://en.wikipedia.org/wiki/Systemantics).

deleted 7y ago
[deleted]
gentleman11 7y ago
> It is offered from the perspective of how not to design systems, based on system engineering failures. The primary precept of treatise is that large complex systems are extremely difficult to design correctly despite best intentions, so care must be taken to design smaller, less-complex systems and to do so with incremental functionality based on close and continual touch with user needs and measures of effectiveness. I am working on my first game using unity right now and I wholeheartedly agree. Almost all of my effective refactoring is turning interacting systems into standalone chunks that don’t care about the rest of the system It’s very hard to do. I imagine my 4th game will go far smoother after I figure out what works and what doesn’t

ssivark 7y ago

> if handed a big ball of mud, is it riskier to start from scratch and go for something more triumphant, or try to evolve the mud gradually? Reminiscent of Chesterton’s fence. But then, we end up in such a “complex” situation only when one thing can have multiple causes & effects — which is difficult to model correctly in a clean slate formulation. The simplest solution seems to be to avoid making software that complex in the first place (we can exert far more control than in the physical world). But then if we think about Peter Naur’s perspective about programming as a mode of theory building (of the domain) (unsurprising, given the basic cybernetics principles such as the law of requisite variety & the good regulator theorem), then the answer seems to be — unless your domain is really complex, think hard before you implement, and keep refactoring as your understanding improves (and truly to pick problem formulations / frameworks / languages which make that feasible. Of course, easier said than done.) The key point is to keep refactoring “continuously“ to match our understanding of the domain, rather than just “adding features”. Aside: In my experience, software built on a good understanding of the domain will function well, untouched, for a long time — so long as it is suitably decoupled from the less-well-understood parts. The latter kind, though, generates constant churn, while also being an annoying fit. Really brings home the adage “A month in the laboratory can save a day in the library.”

heavenlyblue 7y ago
> But then, we end up in such a “complex” situation only when one thing can have multiple causes & effects — which is difficult to model correctly in a clean slate formulation. This is why you should keep paying your employees that worked for the company for years, having written all of the mediocre code when they still could not program well at all.
BurningFrog 7y ago
> The key point is to keep refactoring “continuously“ to match our understanding of the domain, rather than just “adding features”. This is also what I wanted to say. One important part of that is that refactoring is a pretty difficult skill, and many programmers do not have it. So... for those people, some other advice is probably better.

h_r 7y ago

With respect to evolving balls of mud, the only thing that mostly worked for me is to try to find those boundaries where you can apply the [Strangler Pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler https://docs.microsoft.com/en-us/azure/architecture/patterns...)