Live data from Hacker News

Systems that defy detailed understanding

blog.nelhage.com

21–30 of 65 posts

Re: Systems that defy detailed understanding

#21
post #19
post #2

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

> 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 compl…

> 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.

Re: Systems that defy detailed understanding

#22
I often wonder if things would be better if systems were less forgiving. I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS. This forgiveness seems to encourage a culture of sloppiness which tends to spread out. I have the displeasure of looking at quite a bit of PHP code. When I point out that they should fix the hundreds of warnings the usual answer is “why? It works.” My answer usually is “are you sure? “.

On the other hand maybe this forgiveness allowed us to build complex systems.

Re: Systems that defy detailed understanding

#23

I often wonder if things would be better if systems were less forgiving. I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS. This forgiveness seems to encourage a culture of sloppiness which tends to spread out. I have the displeasure of looking at quite a bit of PHP code. When I point out that they should fix the hundreds of warnings the usual answer is…

This often devolves into extremely fragile systems instead. For instance, let's say you failed to load an image on your web site. Would you rather the web site still work with the image broken or just completely fail? What if that image is a tracking pixel? What if you failed to load some experimental module?

Being able to still do something useful in the face of something not going according to plan is essential to being reliable enough to trust.

Re: Systems that defy detailed understanding

#24
post #19
post #2

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

> 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 compl…

> 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.

Re: Systems that defy detailed understanding

#25

I often wonder if things would be better if systems were less forgiving. I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS. This forgiveness seems to encourage a culture of sloppiness which tends to spread out. I have the displeasure of looking at quite a bit of PHP code. When I point out that they should fix the hundreds of warnings the usual answer is…

To me this kind of thing is the difference between furniture you buy from a decent store or from IKEA. It's craftsmanship, not complexity.

Re: Systems that defy detailed understanding

#26

What a long winded article on what has been known to scientists for decades as "emergence". Emergent properties are systems level properties that are not obvious/predictable from properties of individual components. Looking and observing one ant is unlikely to tell you that several of these creatures can build an anthill.

Yes, but to a lot of people that sounds like a lot of woo-woo. What this article does is explain it in a clear and persuasive way to the people in a particular field.

The fact that you didn't pick this up leads me to think you are more interested in being smart than helpful, but perhaps I am wrong about that.

Re: Systems that defy detailed understanding

#28
post #19

Earlier quoted context omitted.

> 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 compl…

> 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.

This lines up with a principle from the Toyota Production System (TPS) in manufacturing--reduce complexity.

In TPS, they found that a focus on reducing complexity leads to improvements in the metrics you'd want to measure: better quality, reduced costs, and customer satisfaction.

Re: Systems that defy detailed understanding

#29

I often wonder if things would be better if systems were less forgiving. I bet people would pay more attention if the browser stopped rendering on JavaScript errors or misformed HTML/CSS. This forgiveness seems to encourage a culture of sloppiness which tends to spread out. I have the displeasure of looking at quite a bit of PHP code. When I point out that they should fix the hundreds of warnings the usual answer is…

XHTML tried to do this after the webmasters (loosely defined) had fled the barn, and then it fell out of the world and the WHATWG ate everything.

Re: Systems that defy detailed understanding

#30
post #19

Earlier quoted context omitted.

> 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 compl…

> 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.

I wish this process was called 'factoring' and you had to be able to name the concept that was being isolated. Often 'refactoring' just means moving code around or isolating code for it's own sake. If a factor was properly isolated you shouldn't have to do that one again. Sometimes you choose different factors, but that's much less common.
Post reply on HN