6 ms·

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 imple

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

rjbwork 12y ago
Perhaps. One could argue that one of these init file templates is just a base class with parts of the implementation overridden. :D
tjradcliffe 12y ago
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".
- rwallace 12y ago
  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.
betenoire 12y ago
I agree: layers of something != abstraction
- Sir_Substance 12y ago
  I might keep that one.
nostrademons 12y ago
"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, they go with the "good enough" solution, build stuff off of it, and by the time "the right thing" comes along, all the momentum has shifted to its crappy competitor. A bunch of crappy software gets built on top of that, and as a result, we end users get the worst thing that could possibly work. But work it does. Maybe it's worth a shift in perspective to be grateful for the stuff that works rather than worry about the stuff that doesn't quite work right.
- Swizec 12y ago
  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.
  - avmich 12y ago
    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 rabbit running from left to right - instead of predicting where rabbit will be in 10 seconds, let's run straight towards the rabbit and in half a second update the course. We win since rabbits don't usually run predictably along the straight line.
    - Swizec 12y ago
      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.
engi_nerd 12y ago
I don't think it's about the act of creating an abstraction, but rather, about using these abstractions with a deficient understanding of the limitations and implications of these abstractions. I agree with you that a significant amount of code is not fully understood by its authors. I see similar phenomena at work in many engineering projects. Relatively few engineers work at the component or board level, rather they work at the subsystem and system levels. They piece parts of systems together to make larger systems-of-systems (sound familiar, programmers?) often with a poor understanding of when the black-box abstractions they deal with can break down and cause havoc. Currently fighting against this in my own workplace, where it's become clear that many engineers do not understand the system we support in sufficient detail to properly troubleshoot faults with that system.
roel_v 12y ago
"I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors"." Well duh. Not a single program shipped today, no matter how small, is "fully" understood by its authors, because to do so, one would have to understand every implementation nuance and bug of OS layers, libraries used, other parts it interacts with, ... And even for less strict definitions of "fully" - for any program that took longer than say 2 weeks to write, how can anyone claim they really know the details of everything, at the same time? Including the nuanced differences between various of OS calls, and the effect some environment variable might have on your localization code, just to name one thing?

rjbwork 12y ago

Perhaps. One could argue that one of these init file templates is just a base class with parts of the implementation overridden. :D

tjradcliffe 12y ago

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

rwallace 12y ago
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.

betenoire 12y ago

I agree: layers of something != abstraction

Sir_Substance 12y ago
I might keep that one.

nostrademons 12y ago

"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, they go with the "good enough" solution, build stuff off of it, and by the time "the right thing" comes along, all the momentum has shifted to its crappy competitor. A bunch of crappy software gets built on top of that, and as a result, we end users get the worst thing that could possibly work. But work it does. Maybe it's worth a shift in perspective to be grateful for the stuff that works rather than worry about the stuff that doesn't quite work right.

Swizec 12y ago
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.
- avmich 12y ago
  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 rabbit running from left to right - instead of predicting where rabbit will be in 10 seconds, let's run straight towards the rabbit and in half a second update the course. We win since rabbits don't usually run predictably along the straight line.
  - Swizec 12y ago
    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.

engi_nerd 12y ago

I don't think it's about the act of creating an abstraction, but rather, about using these abstractions with a deficient understanding of the limitations and implications of these abstractions. I agree with you that a significant amount of code is not fully understood by its authors. I see similar phenomena at work in many engineering projects. Relatively few engineers work at the component or board level, rather they work at the subsystem and system levels. They piece parts of systems together to make larger systems-of-systems (sound familiar, programmers?) often with a poor understanding of when the black-box abstractions they deal with can break down and cause havoc. Currently fighting against this in my own workplace, where it's become clear that many engineers do not understand the system we support in sufficient detail to properly troubleshoot faults with that system.

roel_v 12y ago

"I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors"." Well duh. Not a single program shipped today, no matter how small, is "fully" understood by its authors, because to do so, one would have to understand every implementation nuance and bug of OS layers, libraries used, other parts it interacts with, ... And even for less strict definitions of "fully" - for any program that took longer than say 2 weeks to write, how can anyone claim they really know the details of everything, at the same time? Including the nuanced differences between various of OS calls, and the effect some environment variable might have on your localization code, just to name one thing?