4 ms·

"No silver bullet" in itself must be one of the most misused or misunderstood phrases used by people to argue not to try better ways of doing things. If one sug

"No silver bullet" in itself must be one of the most misused or misunderstood phrases used by people to argue not to try better ways of doing things. If one suggests, that there is a safer or somehow better tool to get the job done ... no silver bullet! Your tool is not perfect for everything in the universe, so we will not even use it where it works significantly better!

WesolyKubeczek 4y ago
The thought that there is no ultimate perfect way to do things is liberating, if anything. It means that we can pick something we deem good enough and roll with it, or we can try and find an infinity of other good enough ways with acceptable tradeoffs, instead of searching for that end all, be all holy grail. Or we can stop trying at some point, because of diminishing returns. It's all okay. The important thing is not to worry that what we have is merely good, because the perfect might be waiting around the corner. It's not.
- kaba0 4y ago
  Also, the most important part of that quote is that due to there not being “free lunch” productivity boosts, we really should focus on reusing existing libraries, “standing on the shoulder of giants”, not reinventing the wheel for each platform/language.
  - zelphirkalt 4y ago
    "no free lunch" and "standing on ..." are 2 ideas, which are also being misused by people in at least 2 ways: One is to block, basically saying: "But no free lunch! Somewhere there must be a cost, because someone else once said no free lunch!", while it is very possible, that one has done something in a way, which was silly from the start and really could have a "free lunch", by switching to a better way of doing it. The other "standing on the shoulders of giants" is used as justification for accumulating more and more dependencies and not writing stuff oneself, no matter how simple, which is how we get into left-pad-like territory. We should indeed focus on reusing libraries, but please, _good_ libraries and not ones, which impose limitations in implementation as well as future thinking, by creating a high mental barrier to change ("But if we switch out this library we need to change aaalll this stuff, because our code is adapted to how the library works."). Sometimes adding a dependency is simply not worth it, like in the left-pad scenario. Just write that one function yourself and don't add more dependencies to the project. Always weigh the benefit against the additional load of dependencies added directly or indirectly as dependencies of dependencies.
    - kaba0 4y ago
      JS is definitely not a good example of “standing on the shoulder of giants”, the language has always lacked a sane standard library (it is getting better nowadays), plus due to optimizing for size and depending on “tree shakers” they have probably the worst dependency graphs ever. But should I really start writing a graph algorithm for the 15th time? I believe the point of the quote is not “blindly add dependencies”, but that a significant boost in productivity can come from reusing already existing, high quality code that fits in with the projects requirements. Left-pad is clearly not such for most projects, and “it is not a free lunch” (:D) in that maintaining dependencies also has a cost.
goto11 4y ago
To summarize, "No silver bullet" claims no single innovation will increase software developer productivity tenfold across the board. He does not say an innovation can't increase productivity greatly in a specific area, neither does he deny that many improvement can accumulate to a tenfold increase.
- kaba0 4y ago
  Also, he speculated it decades ago (though, arguably it still stands. There is no new managed language that would be 10x more productive than any already existing one)
  - goto11 4y ago
    He is not saying a "10x" language couldn't be invented, he is saying a hypothetical 10x language wouldn't increase overall developer productivity 10x. His argument is developers use a lot of time on the intrinsic complexity of designing solutions for complex problems. Representing these solutions in code is a smaller part of the job. So even if a new language increased coding productivity by 10x (like going from assembler to C might) it wouldn't increase overall productivity with the same factor. In short, the bottleneck is not the coding, the bottleneck is our minds thinking about how to solve the problem.
    - kaba0 4y ago
      I reread the paper and I see what you mean — due to coding being only one part of the equation for productivity, any increase in that area can only speed up that part, not the whole (basically Amdahl’s law). But it does also mention that since the appearance of high level languages, we are on a path of diminishing returns: “The most a high-level language can do is to furnish all the constructs the programmer imagines in the abstract program. To be sure, the level of our sophistication in thinking about data structures, data types, and operations is steadily rising, but at an ever-decreasing rate. And language development approaches closer and closer to the sophistication of users. Moreover, at some point the elaboration of a high-level language becomes a burden that increases, not reduces, the intellectual task of the user who rarely uses the esoteric constructs.” Also, Brooks originally wrote this paper for a 10 years timeline, and my point was mostly that even though we are like 3 times over its original length, I still don’t think languages would be even 3 times more productive, let alone more (and I won’t buy empirical evidence of your fav language, but some form of objective one).
_0ffh 4y ago
I suspect there is no bit of wisdom in the world, that is not misunderstood, distorted, and abused by lesser people.

WesolyKubeczek 4y ago

The thought that there is no ultimate perfect way to do things is liberating, if anything. It means that we can pick something we deem good enough and roll with it, or we can try and find an infinity of other good enough ways with acceptable tradeoffs, instead of searching for that end all, be all holy grail. Or we can stop trying at some point, because of diminishing returns. It's all okay. The important thing is not to worry that what we have is merely good, because the perfect might be waiting around the corner. It's not.

kaba0 4y ago
Also, the most important part of that quote is that due to there not being “free lunch” productivity boosts, we really should focus on reusing existing libraries, “standing on the shoulder of giants”, not reinventing the wheel for each platform/language.
- zelphirkalt 4y ago
  "no free lunch" and "standing on ..." are 2 ideas, which are also being misused by people in at least 2 ways: One is to block, basically saying: "But no free lunch! Somewhere there must be a cost, because someone else once said no free lunch!", while it is very possible, that one has done something in a way, which was silly from the start and really could have a "free lunch", by switching to a better way of doing it. The other "standing on the shoulders of giants" is used as justification for accumulating more and more dependencies and not writing stuff oneself, no matter how simple, which is how we get into left-pad-like territory. We should indeed focus on reusing libraries, but please, _good_ libraries and not ones, which impose limitations in implementation as well as future thinking, by creating a high mental barrier to change ("But if we switch out this library we need to change aaalll this stuff, because our code is adapted to how the library works."). Sometimes adding a dependency is simply not worth it, like in the left-pad scenario. Just write that one function yourself and don't add more dependencies to the project. Always weigh the benefit against the additional load of dependencies added directly or indirectly as dependencies of dependencies.
  - kaba0 4y ago
    JS is definitely not a good example of “standing on the shoulder of giants”, the language has always lacked a sane standard library (it is getting better nowadays), plus due to optimizing for size and depending on “tree shakers” they have probably the worst dependency graphs ever. But should I really start writing a graph algorithm for the 15th time? I believe the point of the quote is not “blindly add dependencies”, but that a significant boost in productivity can come from reusing already existing, high quality code that fits in with the projects requirements. Left-pad is clearly not such for most projects, and “it is not a free lunch” (:D) in that maintaining dependencies also has a cost.

goto11 4y ago

To summarize, "No silver bullet" claims no single innovation will increase software developer productivity tenfold across the board. He does not say an innovation can't increase productivity greatly in a specific area, neither does he deny that many improvement can accumulate to a tenfold increase.

kaba0 4y ago
Also, he speculated it decades ago (though, arguably it still stands. There is no new managed language that would be 10x more productive than any already existing one)
- goto11 4y ago
  He is not saying a "10x" language couldn't be invented, he is saying a hypothetical 10x language wouldn't increase overall developer productivity 10x. His argument is developers use a lot of time on the intrinsic complexity of designing solutions for complex problems. Representing these solutions in code is a smaller part of the job. So even if a new language increased coding productivity by 10x (like going from assembler to C might) it wouldn't increase overall productivity with the same factor. In short, the bottleneck is not the coding, the bottleneck is our minds thinking about how to solve the problem.
  - kaba0 4y ago
    I reread the paper and I see what you mean — due to coding being only one part of the equation for productivity, any increase in that area can only speed up that part, not the whole (basically Amdahl’s law). But it does also mention that since the appearance of high level languages, we are on a path of diminishing returns: “The most a high-level language can do is to furnish all the constructs the programmer imagines in the abstract program. To be sure, the level of our sophistication in thinking about data structures, data types, and operations is steadily rising, but at an ever-decreasing rate. And language development approaches closer and closer to the sophistication of users. Moreover, at some point the elaboration of a high-level language becomes a burden that increases, not reduces, the intellectual task of the user who rarely uses the esoteric constructs.” Also, Brooks originally wrote this paper for a 10 years timeline, and my point was mostly that even though we are like 3 times over its original length, I still don’t think languages would be even 3 times more productive, let alone more (and I won’t buy empirical evidence of your fav language, but some form of objective one).

_0ffh 4y ago

I suspect there is no bit of wisdom in the world, that is not misunderstood, distorted, and abused by lesser people.