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

A significant amount of programming is done by superstition

utcc.utoronto.ca

Post reply on HN
Print view View original

91–100 of 214 posts

Re: A significant amount of programming is done by superstition

#91

Post by prawn »

Gravityloss wrote: post #59
anon4 wrote: post #14

I'll have to admit something about myself -- I've never been able to learn how to do anything from just reading its first principles. I need to have a working example that I can then adapt and change and observe changes in the result. This has been especially true in programming. I've been writing programs in some capacity for 18 years now and not once in that time have I been able to simply read the reference manual…

Gall's law is related to this. I think it's reasonable that people want to create software components that have been proven to work and then just forget about their internal details and copy-pas... apply them. It's also what Bret Victor has been getting at. Very often the component's input-output mapping is much more relevant than implementation details. And you can get a feel for that by fiddling with the components…

Gall's Law for anyone who didn't know or couldn't remember it:

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." – John Gall (1975)

Re: A significant amount of programming is done by superstition

#92

Post by ThrustVectoring »

Gravityloss wrote: post #59
anon4 wrote: post #14

I'll have to admit something about myself -- I've never been able to learn how to do anything from just reading its first principles. I need to have a working example that I can then adapt and change and observe changes in the result. This has been especially true in programming. I've been writing programs in some capacity for 18 years now and not once in that time have I been able to simply read the reference manual…

Gall's law is related to this. I think it's reasonable that people want to create software components that have been proven to work and then just forget about their internal details and copy-pas... apply them. It's also what Bret Victor has been getting at. Very often the component's input-output mapping is much more relevant than implementation details. And you can get a feel for that by fiddling with the components…

A microwave oven's input-output mapping is much more relevant than how it works. And you can get a feel for that by plugging it in and pressing the buttons.

It's a very general point - how to interact with things is often dependent on the surface, not the volume. This is the generative insight for the systems approach to engineering.

Re: A significant amount of programming is done by superstition

#93

Post by Swizec »

avmich wrote: post #84
Swizec wrote: post #68

Earlier quoted context omitted.

Anyone can build a bridge that stands up, but only an engineer can build a bridge that barely stands up. Good Enough is our main design goal. Anything more than good enough means you're wasting resources.

And that applies not only to engineers, but to managers - i.e., task definers. Managers aren't interested to ask engineers to build something which will withstand the test of time unless they are sure that time will be actually needed - and with limited information (and high speed of changes) you have today managers tend to think short term. So the whole civilization works along the principle of dog chasing the rabbi…

It sounds like a good task definer (or engineer) should be able to know when thinking a bit further ahead matters and when it doesn't.

For instance, you probably need to take a bit more care with defining your core database structure, than you do with positioning a button 20px to the left or right.

Re: A significant amount of programming is done by superstition

#94

Post by vacri »

nicpottier wrote: post #5

I actually really like the content of the article, but I'm not convinced superstition is the right word here. Yes, absolutely I have copied an init script / makefile or whatnot and if it worked after I tweaked it then I went on my business. But I didn't use it as is because of superstition, but rather because it now worked I believed it correct. Yes, quite often that came without a perfect knowledge of every single o…

I had the same issue. 'Superstition' wasn't the right word. Perhaps 'pragmatism' or even 'science': "This has been observed to work, I shall use it again. I will abandon it for a better one should I find one, or if it should fail".

Pragmatism doesn't need to draw a cause/effect link like superstition does, and superstition doesn't generally lend itself to abandoning faulty beliefs.

Re: A significant amount of programming is done by superstition

#95

Post by danbruc »

This does not resonate with me at all. I can not stand having things in my code I don't fully understand. Without reading the source code of libraries, without reading relevant standards, without understanding the mathematics behind algorithms, there is always this feeling I may make really dumb mistakes. Really understanding all the bits and pieces obviously does not make your code bug free, but I am usually pretty confident that I did not do something horribly wrong.

Re: A significant amount of programming is done by superstition

#96

Post by rwallace »

tjradcliffe wrote: post #23
dandelany wrote: post #20

Earlier quoted context omitted.

I don't think this is about abstraction. Abstraction implies having a deep understanding of the problem domain and encapsulating it in such a way that the implementation details can be ignored and the domain can be reasoned about at a higher level. I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors".

So an even better alternative title would be "The Author of This Essay Does Not Understand Engineering, Software, Technology, Medicine, Or Any of the Other Practical Arts Which Have Always Involved Shipping Imperfectly Understood Machines".

If you read the full text of the original post, it becomes clear that the author does understand the practical arts because he acknowledges that it has to be this way even if it's not what we would ideally like.

Re: A significant amount of programming is done by superstition

#97

Post by Dewie »

GauntletWizard wrote: post #46
anon4 wrote: post #14

I'll have to admit something about myself -- I've never been able to learn how to do anything from just reading its first principles. I need to have a working example that I can then adapt and change and observe changes in the result. This has been especially true in programming. I've been writing programs in some capacity for 18 years now and not once in that time have I been able to simply read the reference manual…

Almost nobody can. Some people think they can, and charge forward with it, but rarely do they produce something that actually works. Usually, they bang on it and test it and cargo-cult it until it works, then convince themselves that it's from 'first principles'. Even if it were a common ability to produce engineering work from written design principles, I'm not certain that's what we want. Experimentation is the key…

> Experimentation is the key to science.

A sort of humanitarian science, since almost everything we touch have been made by other humans. But somehow STEM people are famous for looking down their nose on the non-hard sciences.

Re: A significant amount of programming is done by superstition

#98

Post by chipsy »

Gravityloss wrote: post #59
anon4 wrote: post #14

I'll have to admit something about myself -- I've never been able to learn how to do anything from just reading its first principles. I need to have a working example that I can then adapt and change and observe changes in the result. This has been especially true in programming. I've been writing programs in some capacity for 18 years now and not once in that time have I been able to simply read the reference manual…

Gall's law is related to this. I think it's reasonable that people want to create software components that have been proven to work and then just forget about their internal details and copy-pas... apply them. It's also what Bret Victor has been getting at. Very often the component's input-output mapping is much more relevant than implementation details. And you can get a feel for that by fiddling with the components…

I think it's crucial to the maintenance of our superstition that we don't know which parts of the system are actually important, and we keep misleading ourselves into the wrong assumption.

For example - style considerations. Important? Yes? Maybe? Not at the moment when it reaches the computer, but important when humans have to grok it.

So then should we "lead" development by promoting style? Will that get us somewhere? Probably not as much as some other strategy. But it's still sort of important and this blogger made a nice post the other day about style, so...

Re: A significant amount of programming is done by superstition

#99

Post by svisser »

danbruc wrote: post #95

This does not resonate with me at all. I can not stand having things in my code I don't fully understand. Without reading the source code of libraries, without reading relevant standards, without understanding the mathematics behind algorithms, there is always this feeling I may make really dumb mistakes. Really understanding all the bits and pieces obviously does not make your code bug free, but I am usually pretty…

But what does it mean to fully understand your own code? Everyone relies on millions of lines of code that they didn't write themselves.

Re: A significant amount of programming is done by superstition

#100

Post by Dewie »

Swizec wrote: post #68
nostrademons wrote: post #62

Earlier quoted context omitted.

"A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors" Of course. Time spent fully understanding the code before it's shipped is time that it's not shipped. This is sort of a Gresham's-Law situation, where "bad code drives out good code". The code that is fully tested & debugged with all situations understood isn't available to the user at first. As a result, the…

Anyone can build a bridge that stands up, but only an engineer can build a bridge that barely stands up. Good Enough is our main design goal. Anything more than good enough means you're wasting resources.

Today's "good enough" is tomorrow's technical debt. But that works perfectly, if you know the exact lifetime of your codebase.
Post reply on HN