6 ms·

The essay is remarkably prescient. Brooks dared to predict that thirty years later, software would still be created by programmers sitting in front of editors,

by aedron 7y ago

The essay is remarkably prescient. Brooks dared to predict that thirty years later, software would still be created by programmers sitting in front of editors, painstakingly typing up code branches for all of the scenarios a given program is supposed to handle. And their output would still mostly suck, because of the infinity of possible states, mostly due to variables and synchronicity. Complexity that cannot be abstracted away. Given how starry-eyed we usually are about even the near future, that is bold. The web, language advances, tooling - these are quality-of-life improvements. They don't 'solve' the inherent complexity of software development, the way it was promised by CASE tools (Brooks' likely target with his essay) and countless other 'business oriented' approaches. In fact those approaches have failed so many times that they have been largely abandoned, so in recent times, Brooks' essay might seem superfluous. The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Not yet, given that it is still an esoteric tool for a specialized class of problems, as part of traditional software systems. But with increasing computing power, I can imagine a future where machine learning can be set to work on broader tasks and start to look like magic self-directed software development.

crdoconnor 7y ago
>The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Definitely not. Machine learning is up there with 2012's nosql movement as one of the most overhyped silver bullets. The improvements to programming over the last 30 years have been incremental more than anything in spite of the hype cycles of various silver bullets (OOP, functional programming, side effect free code, TDD, nosql, static types, etc.)
otabdeveloper4 7y ago
> The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Machine learning can't even predict a simple binary proportion ratio. No, it's not a silver bullet.
- arithma 7y ago
  Can you elaborate on that just a bit, I couldn't find anything relevant by doing a quick search for a few combinations of those keywords.
  - hoseja 7y ago
    They may mean machine-learning-assisted branch predictors. No clue otherwise.
  - otabdeveloper4 7y ago
    I'm not smart enough to go into the technical details, so I'll use an example instead. Machine learning is very effective in categorizing things - for example, given an image estimate whether it pictures a cancer cell or not. On the other hand, machine learning sucks where you need to predict things instead of categorizing - for example, given a set of factors, figure out your risk of getting cancer within 5 years. Any such machine learning predictive system will be useless due to under- or overfitting. (Again, I'm not an expert, just a guy who has many years of experience trying to build such predictive systems.)
coldtea 7y ago
>The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Not yet, given that it is still an esoteric tool for a specialized class of problems, as part of traditional software systems. But with increasing computing power, I can imagine a future where machine learning can be set to work on broader tasks and start to look like magic self-directed software development. I'd stick with the silver bullet idea. I don't see machine learning going anywhere, and what passes as machine learning today is just a buzzword.
- nickpinkston 7y ago
  It never works until it does. Many major inventions seemed impossible, but they just took a long time. Software is so young and growing so fast, it's hard to say what can happen.
  - coldtea 7y ago
    >It never works until it does. Many major inventions seemed impossible, but they just took a long time. And others remained impossible still, e.g. cold fusion.
    - nickpinkston 7y ago
      They mostly remain unsolved, not impossible. Cold fusion not withstanding, most aren't prohibited by physics - in fact humans already are an existence proof that bio-machines can already create software autonomously with no change in physics, so seems like a question of when, not if.
- bobm_db 7y ago
  I like this article, but I think actually the software industry has seen a succession of silver bullets. The problem is, once they appear, you take them for granted: https://riskfirst.org/Silver-Bullets https://riskfirst.org/Silver-Bullets
pjmorris 7y ago
I think fuzzing, like afl, is an example of the kind of machine learning that might be useful to software engineering. If we could just figure out how to fuzz requirements along with input fields, we might get somewhere.
ken 7y ago
> Brooks dared to predict that thirty years later, software would still be created by programmers sitting in front of editors, painstakingly typing up code branches for all of the scenarios a given program is supposed to handle. Did I miss this? The thesis says it's about what will happen "within a decade" of 1986 -- "as we look to the horizon of a decade hence". He makes no projections beyond that, that I see, and the timeline seems specifically chosen to suggest that further large improvements are still possible but will take time.
- jerf 7y ago
  We've made massive progress on the accidental complexity. That's what a lot of the "bloat" is that people complain about, and why even though I am a bit sympathetic to that, it's only a bit. There's a reason that, for instance, Electron is so popular, and that reason is a lot of Electron apps would not be paragons of efficiency if Electron didn't exist, they would simply not exist at all, or with a greatly reduced feature set or greatly higher expense. Improving the essential complexity has not moved much at all, which is why my computer science education from 24 years ago is still pretty much the same one people get now and hasn't lost its relevance. The removal of the accidental complexity sometimes means it's only the essential complexity left shining through. In that sense, while he may have had the humility to time-bound his predictions to a mere decade, they've still stayed fresh much longer than that. (Reading the entire Mythical Man Month in 201x is a bizarre experience; all the specific tech references are so dated that they are more myth than fact now, yet, the underlying points those references are in support of are still quite fresh. Arguably a bit incomplete now, we have teams of a scale well beyond what they had then, sitting on piles of software yet larger, but still correct at the core.)
breck 7y ago
> Brooks dared to predict I love this. So rare nowadays to scientists make bold predictions. Disclosure: I work on Tree Notation (https://treenotation.org/ https://treenotation.org/). Two years ago, in 2017 I predicted Tree Notation will be a silver bullet: by 2027 we will have a 10x improvement in reliability, productivity, and simplicity, thanks to the Tree Notation ecosystem. 2 years later, and thousands of experiments and conversations later, I'm almost positive that will happen.
- bearer_token 7y ago
 Okay, I'll bite. How is this different than an Abstract Syntax Tree (AST)?
 - breck 7y ago
 Think of your code in a spreadsheet or Cartesian plane. Each word has a location in 2D space. There is a physical manifestation of your program’s source code. The parsed version (with the words of your source replaced with their parsed types), has the same shape (physical manifestation) as your source code. So source == AST. Currently traditional languages this is not true. They are stripped to 1D and the further you move from lisp the more different they become.
 - heavenlyblue 7y ago
 How is that different from XML?
 - breck 7y ago
 In XML: <a></a> === <a> </a> In Tree Notation those are 2 different structures.
 bobbiechen 7y ago
 Interesting. Would you say this is similar to a visual programming language like Max/MSP? I was always intimidated by the large screens of spaghetti (almost literally, because of patch cords). How do you deal with large complex code? Lots of folding?
lliamander 7y ago
Further prescience is in the areas that he predicted would be good areas at attacking essential complexity: 1. Build vs. Buy - I would say that open source has generally become the "COTS" solution that Brooks was looking for. 2. Requirements refinement and prototyping - agile development. 3. Incremental development - also agile, as well as different evolutionary architecture approaches 4. Great designers - the establishment of technical career ladders at many companies. Again, none of these things are silver bullets, but they have contributed to significant progress in our industry.

by aedron 7y ago

crdoconnor 7y ago

>The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Definitely not. Machine learning is up there with 2012's nosql movement as one of the most overhyped silver bullets. The improvements to programming over the last 30 years have been incremental more than anything in spite of the hype cycles of various silver bullets (OOP, functional programming, side effect free code, TDD, nosql, static types, etc.)

otabdeveloper4 7y ago

> The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Machine learning can't even predict a simple binary proportion ratio. No, it's not a silver bullet.

arithma 7y ago
Can you elaborate on that just a bit, I couldn't find anything relevant by doing a quick search for a few combinations of those keywords.
- hoseja 7y ago
  They may mean machine-learning-assisted branch predictors. No clue otherwise.
- otabdeveloper4 7y ago
  I'm not smart enough to go into the technical details, so I'll use an example instead. Machine learning is very effective in categorizing things - for example, given an image estimate whether it pictures a cancer cell or not. On the other hand, machine learning sucks where you need to predict things instead of categorizing - for example, given a set of factors, figure out your risk of getting cancer within 5 years. Any such machine learning predictive system will be useless due to under- or overfitting. (Again, I'm not an expert, just a guy who has many years of experience trying to build such predictive systems.)

coldtea 7y ago

>The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Not yet, given that it is still an esoteric tool for a specialized class of problems, as part of traditional software systems. But with increasing computing power, I can imagine a future where machine learning can be set to work on broader tasks and start to look like magic self-directed software development. I'd stick with the silver bullet idea. I don't see machine learning going anywhere, and what passes as machine learning today is just a buzzword.

nickpinkston 7y ago
It never works until it does. Many major inventions seemed impossible, but they just took a long time. Software is so young and growing so fast, it's hard to say what can happen.
- coldtea 7y ago
  >It never works until it does. Many major inventions seemed impossible, but they just took a long time. And others remained impossible still, e.g. cold fusion.
  - nickpinkston 7y ago
    They mostly remain unsolved, not impossible. Cold fusion not withstanding, most aren't prohibited by physics - in fact humans already are an existence proof that bio-machines can already create software autonomously with no change in physics, so seems like a question of when, not if.
bobm_db 7y ago
I like this article, but I think actually the software industry has seen a succession of silver bullets. The problem is, once they appear, you take them for granted: https://riskfirst.org/Silver-Bullets https://riskfirst.org/Silver-Bullets

pjmorris 7y ago

I think fuzzing, like afl, is an example of the kind of machine learning that might be useful to software engineering. If we could just figure out how to fuzz requirements along with input fields, we might get somewhere.

ken 7y ago

> Brooks dared to predict that thirty years later, software would still be created by programmers sitting in front of editors, painstakingly typing up code branches for all of the scenarios a given program is supposed to handle. Did I miss this? The thesis says it's about what will happen "within a decade" of 1986 -- "as we look to the horizon of a decade hence". He makes no projections beyond that, that I see, and the timeline seems specifically chosen to suggest that further large improvements are still possible but will take time.

jerf 7y ago
We've made massive progress on the accidental complexity. That's what a lot of the "bloat" is that people complain about, and why even though I am a bit sympathetic to that, it's only a bit. There's a reason that, for instance, Electron is so popular, and that reason is a lot of Electron apps would not be paragons of efficiency if Electron didn't exist, they would simply not exist at all, or with a greatly reduced feature set or greatly higher expense. Improving the essential complexity has not moved much at all, which is why my computer science education from 24 years ago is still pretty much the same one people get now and hasn't lost its relevance. The removal of the accidental complexity sometimes means it's only the essential complexity left shining through. In that sense, while he may have had the humility to time-bound his predictions to a mere decade, they've still stayed fresh much longer than that. (Reading the entire Mythical Man Month in 201x is a bizarre experience; all the specific tech references are so dated that they are more myth than fact now, yet, the underlying points those references are in support of are still quite fresh. Arguably a bit incomplete now, we have teams of a scale well beyond what they had then, sitting on piles of software yet larger, but still correct at the core.)

breck 7y ago

> Brooks dared to predict I love this. So rare nowadays to scientists make bold predictions. Disclosure: I work on Tree Notation (https://treenotation.org/ https://treenotation.org/). Two years ago, in 2017 I predicted Tree Notation will be a silver bullet: by 2027 we will have a 10x improvement in reliability, productivity, and simplicity, thanks to the Tree Notation ecosystem. 2 years later, and thousands of experiments and conversations later, I'm almost positive that will happen.

bearer_token 7y ago
Okay, I'll bite. How is this different than an Abstract Syntax Tree (AST)?
- breck 7y ago
 Think of your code in a spreadsheet or Cartesian plane. Each word has a location in 2D space. There is a physical manifestation of your program’s source code. The parsed version (with the words of your source replaced with their parsed types), has the same shape (physical manifestation) as your source code. So source == AST. Currently traditional languages this is not true. They are stripped to 1D and the further you move from lisp the more different they become.
 - heavenlyblue 7y ago
 How is that different from XML?
 - breck 7y ago
 In XML: <a></a> === <a> </a> In Tree Notation those are 2 different structures.
 - bobbiechen 7y ago
 Interesting. Would you say this is similar to a visual programming language like Max/MSP? I was always intimidated by the large screens of spaghetti (almost literally, because of patch cords). How do you deal with large complex code? Lots of folding?

lliamander 7y ago

Further prescience is in the areas that he predicted would be good areas at attacking essential complexity: 1. Build vs. Buy - I would say that open source has generally become the "COTS" solution that Brooks was looking for. 2. Requirements refinement and prototyping - agile development. 3. Incremental development - also agile, as well as different evolutionary architecture approaches 4. Great designers - the establishment of technical career ladders at many companies. Again, none of these things are silver bullets, but they have contributed to significant progress in our industry.