10 ms·

The dirty secret in software development: most think they how to write efficient software when they need to, but very few can. Sometimes the excuse is that cpu

The dirty secret in software development: most think they how to write efficient software when they need to, but very few can. Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine. Many also don't know how to draw simple, low-overhead abstraction boundaries. Everybody wants to make the most generic code planning for things that will never happen or at least not in the way they think. You can't call out most people on this because this one piece of code they are working on is always the exception. And most developers don't know how to optimize as they write code. They often don't understand the problem or have enough mechanical sympathy to understand what code you should probably be careful with and should be made quick to start off with. They probably don't understand the cache system enough to know why that linked hash table is probably the wrong data structure. Hash means fast to them, and to them this is all premature optimization even when the correct solution is probably no more difficult than what they are doing. Calling something premature optimization is often used to shut down discussion of how their code can be improved. The field is too in love with horribly inefficient frameworks. Writing network code and protocols is now considered too low level for people. Many are too caught up it what is tech-cool. They're like the holistic medicine practitioners of software and they don't even know it.

regularfry 9y ago
In my observation, this puts the blame in the wrong place. It's simply that most software development is feature-driven, and efficiency is rarely held to be a feature by the business that's paying for them. That is, until it becomes a problem, at which point there are enough low-hanging fruit left by the constant scramble for user-facing shiny that making it not a problem again is relatively straightforward.
- jnordwick 9y ago
  I didn't buy that excuse at all. Devs have a habitual problem blaming others for their poor code. Often better code takes only marginally longer or even less time since you aren't having to deal with all the extra complexity that tends to be a part of "modern" development. The complexity is of our own making. We spend too much time on this extra cool and extensible way to use json and xml in case we even want to run on a quantum computer in in 50 years or avoid a simple recompilation when we need to change a constant that will likely never need to be changed when we should have been spending that time on more important things.
  - regularfry 9y ago
    You're conflating "better" with "more efficient to execute." That's only one possible interpretation of "better", and it's usually not the most important one.
    - marrs 9y ago
      but it very often is. If you're a web developer, for example, little matters more to your users than performance. This has been demonstrated an almost infinite number of times by now, but surprisingly few industry professionals seem to pay any attention to it
      - regularfry 9y ago
        Yes, and we can point that out to our business owners until we're blue in the face, but until they see the benefit they won't pay us to do that work. It can be surprisingly difficult to get this point across.
      - Brockenstein 9y ago
        Just because something matters objectively, doesn't mean it matters to the client/business (at the moment). And unless you as the developer are in the position to dictate that, sometimes you're at the mercy of non-technical requirements or demands. You can be right about everything, but unless you're the boss, at least sometimes you can only do what you're told.
      - aoeuasdf1 9y ago
        Little matters more to your users than performance, specifically, only features and security matter more than performance :)
        jononor 9y ago
        And that the software is available (ie actually shipped). And to use it they need to know it exists and what it's for, which usually involves some marketing.
- Gravityloss 9y ago
  Well for some reason it's those people [1] who have the money so they call the shots. Do you know of organizations where an internal drive for excellence is cultivated? Where technical people communicate directly across hierarchy levels and horizontally? Maybe even outside the company? [1]: People who are relatively close to the customer and not the implementation. Those people don't tend to understand how efficient some things are because they can't estimate how long something should take from lower principles which they have a benchmark for. This makes them much happier software users.
ClassyJacket 9y ago
"Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine." Does anyone know if there's a generalized name for this problem? It's the same one where your teacher gives you "only two hours of homework tonight" but forgets you have four other classes all doing the same thing.
- Daishiman 9y ago
  Parkinson's Law
  - ClassyJacket 9y ago
    "Originally, Parkinson's law is the adage that "work expands so as to fill the time available for its completion", and the title of a book which made it well-known. However, in current understanding, Parkinson's law is a reference to the self-satisfying uncontrolled growth of the bureaucratic apparatus in an organization." Hmm, I can see how they're related, but it doesn't seem to be quite what I'm talking about. I'm more referring to the overuse of resources by individual elements assuming or acting as if they're the only thing using it, like in the above examples of a teacher acting like their class is your only one, or a thread consuming resources like no others are active. Parkinson's law more seems to be the result of the effect that I'm talking about (among others, like procrastination).
    - vtbassmatt 9y ago
      Tragedy of the commons?
    - posterboy 9y ago
      willful ignorance?
- pjmorris 9y ago
  Maybe 'Tragedy of the Commons'? [0] [0] https://en.wikipedia.org/wiki/Tragedy_of_the_commons https://en.wikipedia.org/wiki/Tragedy_of_the_commons
dreamcompiler 9y ago
Efficiency can be done but it requires disciplines only taught in courses on real-time and embedded programming, and those seem to be fairly rare these days. Real-time and embedded programming teach the programmer how to reason about finite resources like time, energy, memory, and floating-point operations while requiring a level of mastery "down to the metal" that's also rare in overly abstraction-driven programming. RTE skills make every programmer better in the same way that glider skills make every pilot better.
- jnordwick 9y ago
  I went to Cal and aside from some hardware classes i never had a real time or embedded class. I think it requires an open mind to want to learn these things and put effort into it instead of blowing things off as premature or something the maintainer of the code behind you will come and fix.
  - rhodysurf 9y ago
    Anecdotal but this matches my experience. I went to generic public school for ocean engineering and took tons of embedded classes. I then worked on a student robot project and was shocked when the CS students were completely lost with how to approach writing drivers and interfaces for the sensors and such. I thought that would be standard for CS.
    - opportune 9y ago
      I think that stuff tends to be more common for EEs and CompEs.
    - RandomOpinion 9y ago
      > CS students were completely lost with how to approach writing drivers and interfaces for the sensors and such. I thought that would be standard for CS. No, that would be standard for computer engineering, not CS. Try to have a conversation about hardware to many practicing software developers who were CS majors and they'll look at you as if you've grown a second head.
omginternets 9y ago
And so where can a self-taught programmer self-teach himself about this stuff? I'm probably guiltier of this than I realize, especially since I loooooove me some abstraction.
- pjc50 9y ago
  "Arduino" and other small-system programming. Or get an emulator and try to write an Atari 2600 game: you have 128 bytes of RAM, don't use it all at once.
  - omginternets 9y ago
    I should have been clearer: I'm mostly interested in books and articles. I like to approach things theoretically before approaching them practically. (Nonetheless, thanks for your suggestion!)
    - Spearchucker 9y ago
      You could do worse than Steve McConnell's Code Complete - https://www.amazon.com/dp/0735619670 https://www.amazon.com/dp/0735619670.
    - gradstudent 9y ago
      Try "Racing the Beam"; a neat book describing the programming challenges with writing software for the Atari 2600. https://www.amazon.com/Racing-Beam-Computer-Platform-Studies/dp/026201257X https://www.amazon.com/Racing-Beam-Computer-Platform-Studies... Though, instead of reading, you really should just get over your complex and try writing some efficient code.
      - omginternets 9y ago
        >get over your complex It's not a complex. I'm always very surprised by this attitude. Theory serves practice. Case and point: the OP mentions that an understanding of cache architecture enables you to reason about which data-structures exhibit good cache locality. Discovering that hashtables have poor cache locality by trial-and-error seems like a waste of time compared to gaining theoretical insights.
skratlo 9y ago
> premature optimization is often used to shut down discussion of how their code can be improved and > The field is too in love with horribly inefficient frameworks Dude, I can't emphasize this enough. One of the best things I read in past week.
GuB-42 9y ago
If you ask developers to write efficient code and give them the means to do it, they will write efficient code. But unless they work in embedded software, this is rarely a priority. In fact, this tends to be actively discouraged : in the good shops, reliability, robustness and security is the goal, in bad shops, that's bullet-point features and meeting unrealistic deadlines. To get an idea of how optimization is poorly regarded, look no further than the infamous Heartbleed exploit of OpenSSL. One of the contributing factor for this bug was that the team used a custom memory allocator for performance reasons. After the bug was discovered, the team was actually blamed for it more than anything else that lead to the bug. And FYI, it was a real performance improvement, at least on some platforms.
- sclangdon 9y ago
  You seem to be under the impression that writing efficient code is at odds with writing reliable or robust code. Efficient does not mean unsafe. Efficient code does not have to shoot-from-the-hip. Efficiency means that the task is completed with the minimum wasted effort. To assume that you cannot have relieable code that is also efficient is absurd. If reliability is the top priority for your project, it just means you factor that in to your optimizations. It doesn't mean you just ignore efficiency and write any old shit, as seems to be the custom today. Your OpenSSL example seems to suggest the Heartbleed exploit was a result of developers daring to write performant code, and not that they simply wrote buggy or insecure code, performant or not.
  - TeMPOraL 9y ago
    I feel the problem here is what I imagine as this formula: reliability * efficiency = developer skill I.e. for a given level of reliability, you need more skilled[0] developers to be able to write efficient code. And I'm not thinking about premature optimizations here - just that the code an experienced developer will write the first time around will be efficient enough. So in short, if you aim for certain level of reliability and employ cheap/unskilled developers, efficiency will suffer. And as long as companies don't really care about performance, developers will not gain the necessary experience to write efficient code with just-in-time optimizations. -- [0] - for "skilled" meaning probably mostly some knowledge and experience in writing fast code; it's probably not the experience you'll get when all coding you've ever done is for the web.
mfukar 9y ago
The dirty secret in software development: most think they write efficient software, but very few know what to compare it to and how.
kronos29296 9y ago
>The field is too in love with horribly inefficient frameworks. Writing network code and protocols is now considered too low level for people. Many are too caught up it what is tech-cool. They're like the holistic medicine practitioners of software and they don't even know it. While the frameworks themselves are made for a particular purpose, they are often misused. One great example would be electron. I found an electron clone of Keepass. Now why would anybody want that. And you find people justifying Huge bloated electron apps that take a minimum of 50 MB for a simple Hello World. And then they say memory is cheap. I say memory is cheap for 1 app at that size. Not running all apps at that size. If busybox can run GNU coreutils with a size less an MB then why can't they make more efficient apps? Beats me.
- noxToken 9y ago
  >...then why can't they make more efficient apps? They can. >...frameworks... are often misused.
amelius 9y ago
> most think they how to write efficient software when they need to, but very few can Doesn't mp3 transcoding have dedicated hardware instructions, making the job much easier?
- jleahy 9y ago
  No, because it's so easy to begin with.
  - amelius 9y ago
    Satisfying a low-power constraint?
- pjc50 9y ago
  It's not really "dedicated", it's just SIMD for FFT like most signal processing. Takes about 25 MIPS: https://retrocomputing.stackexchange.com/questions/2672/why-does-mp3-audio-decoding-overwhelm-retro-cpus https://retrocomputing.stackexchange.com/questions/2672/why-... You can get dedicated MP3 low-power decoder chips. You might have one in a fancy PC soundcard (SBLive?), but I don't think it's included in baseline AC97. (I remember having a 486DX that could decode MP3s with the Fraunhofer player at about 95% CPU but not Winamp, which was slighly too slow to keep up)
  - amelius 9y ago
    Does this also hold for modern smartphones?
    - pjc50 9y ago
      I don't know exactly; the chipsets tend to be closed. I've seen baseband processors which have the AMR codec in hardware (adaptive multi-rate, used for GSM phone audio).
weberc2 9y ago
I mostly agree, but I think you're too quick to assume that everyone who doesn't write optimal code is doing so because of some tech fad. Frequently it simply doesn't pay to write optimal code; there's no viable business case. Sure, using an array can be faster and not much harder than using a hash table, but writing a network protocol is frequently not worth the effort. In my experience, poor performance comes from the inability to make a business case (whether or not one actually exists), not from chasing fads.
- flavio81 9y ago
  I think good programmers, by default, try to write readable, easy-to-maintain code. If you ask them to write high-performance code then they will do it, knowing that readability might suffer because of it.
naikrovek 9y ago
If you're not developing for a real-time system, like most (all?) larger games or software for embedded hardware, it is likely that you are not thinking about performance very much, even if you have the time and skill to do so. You don't think about performance, as a developer, usually, until it becomes a problem, and there are so many layers and frameworks between an MP3 player and the CPU that this kind of thing should be expected. It is much more difficult to keep a real-time system working in real-time than it is to keep something performing as well as a desktop computer user expects it to perform.
Capt-RogerOver 9y ago
"Mechanical Sympathy"/empathy is a very good expression, kudos!
- jnordwick 9y ago
  I wish I could take credit, but i think it was Martin Thompson that coined the phrase. I think it if a perfect deception of the, often subconscious, understanding of what is going on underneath the code.
taeric 9y ago
I think the secret is slightly different. Most think they can fully solve a problem. Such that their solution is the one everyone should use. This manifests in assuming everyone can afford the abstraction boundaries chosen. Or that everyone needs the same tradeoffs. Or, ultimately, that everyone would come to the same conclusion. I think of it as the desire of most people to boil software down to formulaic choices. Imagine if you came up with something as elegant as "F = ma" for software. I feel this is somewhat related to the rise in functional programming. It is not that either of those things are bad goals to chase. But they are not ends to themselves.
datagram 9y ago
"Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine." I find that this often extends beyond performance too. Many websites/apps waste lots of screen space because they were clearly designed for, and tested at, 1080p.

regularfry 9y ago

In my observation, this puts the blame in the wrong place. It's simply that most software development is feature-driven, and efficiency is rarely held to be a feature by the business that's paying for them. That is, until it becomes a problem, at which point there are enough low-hanging fruit left by the constant scramble for user-facing shiny that making it not a problem again is relatively straightforward.

jnordwick 9y ago
I didn't buy that excuse at all. Devs have a habitual problem blaming others for their poor code. Often better code takes only marginally longer or even less time since you aren't having to deal with all the extra complexity that tends to be a part of "modern" development. The complexity is of our own making. We spend too much time on this extra cool and extensible way to use json and xml in case we even want to run on a quantum computer in in 50 years or avoid a simple recompilation when we need to change a constant that will likely never need to be changed when we should have been spending that time on more important things.
- regularfry 9y ago
  You're conflating "better" with "more efficient to execute." That's only one possible interpretation of "better", and it's usually not the most important one.
  - marrs 9y ago
    but it very often is. If you're a web developer, for example, little matters more to your users than performance. This has been demonstrated an almost infinite number of times by now, but surprisingly few industry professionals seem to pay any attention to it
    - regularfry 9y ago
      Yes, and we can point that out to our business owners until we're blue in the face, but until they see the benefit they won't pay us to do that work. It can be surprisingly difficult to get this point across.
    - Brockenstein 9y ago
      Just because something matters objectively, doesn't mean it matters to the client/business (at the moment). And unless you as the developer are in the position to dictate that, sometimes you're at the mercy of non-technical requirements or demands. You can be right about everything, but unless you're the boss, at least sometimes you can only do what you're told.
    - aoeuasdf1 9y ago
      Little matters more to your users than performance, specifically, only features and security matter more than performance :)
      - jononor 9y ago
        And that the software is available (ie actually shipped). And to use it they need to know it exists and what it's for, which usually involves some marketing.
Gravityloss 9y ago
Well for some reason it's those people [1] who have the money so they call the shots. Do you know of organizations where an internal drive for excellence is cultivated? Where technical people communicate directly across hierarchy levels and horizontally? Maybe even outside the company? [1]: People who are relatively close to the customer and not the implementation. Those people don't tend to understand how efficient some things are because they can't estimate how long something should take from lower principles which they have a benchmark for. This makes them much happier software users.

ClassyJacket 9y ago

"Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine." Does anyone know if there's a generalized name for this problem? It's the same one where your teacher gives you "only two hours of homework tonight" but forgets you have four other classes all doing the same thing.

Daishiman 9y ago
Parkinson's Law
- ClassyJacket 9y ago
  "Originally, Parkinson's law is the adage that "work expands so as to fill the time available for its completion", and the title of a book which made it well-known. However, in current understanding, Parkinson's law is a reference to the self-satisfying uncontrolled growth of the bureaucratic apparatus in an organization." Hmm, I can see how they're related, but it doesn't seem to be quite what I'm talking about. I'm more referring to the overuse of resources by individual elements assuming or acting as if they're the only thing using it, like in the above examples of a teacher acting like their class is your only one, or a thread consuming resources like no others are active. Parkinson's law more seems to be the result of the effect that I'm talking about (among others, like procrastination).
  - vtbassmatt 9y ago
    Tragedy of the commons?
  - posterboy 9y ago
    willful ignorance?
pjmorris 9y ago
Maybe 'Tragedy of the Commons'? [0] [0] https://en.wikipedia.org/wiki/Tragedy_of_the_commons https://en.wikipedia.org/wiki/Tragedy_of_the_commons

dreamcompiler 9y ago

Efficiency can be done but it requires disciplines only taught in courses on real-time and embedded programming, and those seem to be fairly rare these days. Real-time and embedded programming teach the programmer how to reason about finite resources like time, energy, memory, and floating-point operations while requiring a level of mastery "down to the metal" that's also rare in overly abstraction-driven programming. RTE skills make every programmer better in the same way that glider skills make every pilot better.

jnordwick 9y ago
I went to Cal and aside from some hardware classes i never had a real time or embedded class. I think it requires an open mind to want to learn these things and put effort into it instead of blowing things off as premature or something the maintainer of the code behind you will come and fix.
- rhodysurf 9y ago
  Anecdotal but this matches my experience. I went to generic public school for ocean engineering and took tons of embedded classes. I then worked on a student robot project and was shocked when the CS students were completely lost with how to approach writing drivers and interfaces for the sensors and such. I thought that would be standard for CS.
  - opportune 9y ago
    I think that stuff tends to be more common for EEs and CompEs.
  - RandomOpinion 9y ago
    > CS students were completely lost with how to approach writing drivers and interfaces for the sensors and such. I thought that would be standard for CS. No, that would be standard for computer engineering, not CS. Try to have a conversation about hardware to many practicing software developers who were CS majors and they'll look at you as if you've grown a second head.

omginternets 9y ago

And so where can a self-taught programmer self-teach himself about this stuff? I'm probably guiltier of this than I realize, especially since I loooooove me some abstraction.

pjc50 9y ago
"Arduino" and other small-system programming. Or get an emulator and try to write an Atari 2600 game: you have 128 bytes of RAM, don't use it all at once.
- omginternets 9y ago
  I should have been clearer: I'm mostly interested in books and articles. I like to approach things theoretically before approaching them practically. (Nonetheless, thanks for your suggestion!)
  - Spearchucker 9y ago
    You could do worse than Steve McConnell's Code Complete - https://www.amazon.com/dp/0735619670 https://www.amazon.com/dp/0735619670.
  - gradstudent 9y ago
    Try "Racing the Beam"; a neat book describing the programming challenges with writing software for the Atari 2600. https://www.amazon.com/Racing-Beam-Computer-Platform-Studies/dp/026201257X https://www.amazon.com/Racing-Beam-Computer-Platform-Studies... Though, instead of reading, you really should just get over your complex and try writing some efficient code.
    - omginternets 9y ago
      >get over your complex It's not a complex. I'm always very surprised by this attitude. Theory serves practice. Case and point: the OP mentions that an understanding of cache architecture enables you to reason about which data-structures exhibit good cache locality. Discovering that hashtables have poor cache locality by trial-and-error seems like a waste of time compared to gaining theoretical insights.

skratlo 9y ago

> premature optimization is often used to shut down discussion of how their code can be improved and > The field is too in love with horribly inefficient frameworks Dude, I can't emphasize this enough. One of the best things I read in past week.

GuB-42 9y ago

If you ask developers to write efficient code and give them the means to do it, they will write efficient code. But unless they work in embedded software, this is rarely a priority. In fact, this tends to be actively discouraged : in the good shops, reliability, robustness and security is the goal, in bad shops, that's bullet-point features and meeting unrealistic deadlines. To get an idea of how optimization is poorly regarded, look no further than the infamous Heartbleed exploit of OpenSSL. One of the contributing factor for this bug was that the team used a custom memory allocator for performance reasons. After the bug was discovered, the team was actually blamed for it more than anything else that lead to the bug. And FYI, it was a real performance improvement, at least on some platforms.

sclangdon 9y ago
You seem to be under the impression that writing efficient code is at odds with writing reliable or robust code. Efficient does not mean unsafe. Efficient code does not have to shoot-from-the-hip. Efficiency means that the task is completed with the minimum wasted effort. To assume that you cannot have relieable code that is also efficient is absurd. If reliability is the top priority for your project, it just means you factor that in to your optimizations. It doesn't mean you just ignore efficiency and write any old shit, as seems to be the custom today. Your OpenSSL example seems to suggest the Heartbleed exploit was a result of developers daring to write performant code, and not that they simply wrote buggy or insecure code, performant or not.
- TeMPOraL 9y ago
  I feel the problem here is what I imagine as this formula: reliability * efficiency = developer skill I.e. for a given level of reliability, you need more skilled[0] developers to be able to write efficient code. And I'm not thinking about premature optimizations here - just that the code an experienced developer will write the first time around will be efficient enough. So in short, if you aim for certain level of reliability and employ cheap/unskilled developers, efficiency will suffer. And as long as companies don't really care about performance, developers will not gain the necessary experience to write efficient code with just-in-time optimizations. -- [0] - for "skilled" meaning probably mostly some knowledge and experience in writing fast code; it's probably not the experience you'll get when all coding you've ever done is for the web.

mfukar 9y ago

The dirty secret in software development: most think they write efficient software, but very few know what to compare it to and how.

kronos29296 9y ago

>The field is too in love with horribly inefficient frameworks. Writing network code and protocols is now considered too low level for people. Many are too caught up it what is tech-cool. They're like the holistic medicine practitioners of software and they don't even know it. While the frameworks themselves are made for a particular purpose, they are often misused. One great example would be electron. I found an electron clone of Keepass. Now why would anybody want that. And you find people justifying Huge bloated electron apps that take a minimum of 50 MB for a simple Hello World. And then they say memory is cheap. I say memory is cheap for 1 app at that size. Not running all apps at that size. If busybox can run GNU coreutils with a size less an MB then why can't they make more efficient apps? Beats me.

noxToken 9y ago
>...then why can't they make more efficient apps? They can. >...frameworks... are often misused.

amelius 9y ago

> most think they how to write efficient software when they need to, but very few can Doesn't mp3 transcoding have dedicated hardware instructions, making the job much easier?

jleahy 9y ago
No, because it's so easy to begin with.
- amelius 9y ago
  Satisfying a low-power constraint?
pjc50 9y ago
It's not really "dedicated", it's just SIMD for FFT like most signal processing. Takes about 25 MIPS: https://retrocomputing.stackexchange.com/questions/2672/why-does-mp3-audio-decoding-overwhelm-retro-cpus https://retrocomputing.stackexchange.com/questions/2672/why-... You can get dedicated MP3 low-power decoder chips. You might have one in a fancy PC soundcard (SBLive?), but I don't think it's included in baseline AC97. (I remember having a 486DX that could decode MP3s with the Fraunhofer player at about 95% CPU but not Winamp, which was slighly too slow to keep up)
- amelius 9y ago
  Does this also hold for modern smartphones?
  - pjc50 9y ago
    I don't know exactly; the chipsets tend to be closed. I've seen baseband processors which have the AMR codec in hardware (adaptive multi-rate, used for GSM phone audio).

weberc2 9y ago

I mostly agree, but I think you're too quick to assume that everyone who doesn't write optimal code is doing so because of some tech fad. Frequently it simply doesn't pay to write optimal code; there's no viable business case. Sure, using an array can be faster and not much harder than using a hash table, but writing a network protocol is frequently not worth the effort. In my experience, poor performance comes from the inability to make a business case (whether or not one actually exists), not from chasing fads.

flavio81 9y ago
I think good programmers, by default, try to write readable, easy-to-maintain code. If you ask them to write high-performance code then they will do it, knowing that readability might suffer because of it.

naikrovek 9y ago

If you're not developing for a real-time system, like most (all?) larger games or software for embedded hardware, it is likely that you are not thinking about performance very much, even if you have the time and skill to do so. You don't think about performance, as a developer, usually, until it becomes a problem, and there are so many layers and frameworks between an MP3 player and the CPU that this kind of thing should be expected. It is much more difficult to keep a real-time system working in real-time than it is to keep something performing as well as a desktop computer user expects it to perform.

Capt-RogerOver 9y ago

"Mechanical Sympathy"/empathy is a very good expression, kudos!

jnordwick 9y ago
I wish I could take credit, but i think it was Martin Thompson that coined the phrase. I think it if a perfect deception of the, often subconscious, understanding of what is going on underneath the code.

taeric 9y ago

I think the secret is slightly different. Most think they can fully solve a problem. Such that their solution is the one everyone should use. This manifests in assuming everyone can afford the abstraction boundaries chosen. Or that everyone needs the same tradeoffs. Or, ultimately, that everyone would come to the same conclusion. I think of it as the desire of most people to boil software down to formulaic choices. Imagine if you came up with something as elegant as "F = ma" for software. I feel this is somewhat related to the rise in functional programming. It is not that either of those things are bad goals to chase. But they are not ends to themselves.

datagram 9y ago

"Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine." I find that this often extends beyond performance too. Many websites/apps waste lots of screen space because they were clearly designed for, and tested at, 1080p.