6 ms·

No Silver Bullet (1986) [pdf]

55 points by ayberkt 11y ago

crpatino 11y ago
This is required reading for every promising young hacker. The more promising, the more required.
- slacka 11y ago
  I couldn't disagree with you more. This paper offers no insight, only excuses to accept that software will always be buggy. If anything I'd encourage young engineers to explore technologies that have been not been explored to their fullest potential. Computer Science is a very young field and many unexplored paths such as flow based or some automated programming method that hasn't been dreamed up yet that may lead to far more reliable software. I dread to think what today's CPUs would be like if an electrical engineering version of this was required reading for every EE in the 70s. We should just accept buggy CPUs because of the complexity in designing CPUS with 7 billion transistors.
  - pron 11y ago
    > This paper offers no insight, only excuses to accept that software will always be buggy. Is that how you read it? I read it as a call to accept an open eyed view of the industry and its advances, and tirelessly work to make progress rather than believe in messianic fads and jump from one to the next. It is optimistic yet realistic, and warns against unconstructive zeal.
  - crpatino 11y ago
    > This paper offers no insight, only excuses to accept that software will always be buggy. The paper does not address the problem of buggy software, though it is related. It addresses the problem that software is complex. And the insight it offers is that not all complexity is equal: there is accidental complexity (programming is hard because the way we have done things historically is not yet optimized) and inherent complexity (programming is hard because we are modeling complex stuff and it is inherently hard for human minds to juggle all the relevant details). The excuses you complain about are really examples where people confuse one with the other. i.e. you cannot solve the problem of Requirement Gathering with better compilers because the problem is not technical, it is that stake holders are playing political games in the background, so if left to their own devices they'll give you vague, confusing requirements now with the tacit intention of leveraging those when the inevitable struggles come in the future. > I dread to think what today's CPUs would be like if an electrical engineering version of this was required reading for every EE in the 70s. I am sorry to inform you that an EE version of this will be direly needed in the near future. As the Moore law keeps hitting more and more fundamental limits of physics, we need engineers who are able to work in the problems that matter and make hardware that gives us the best possible performance given the constrains available. It would not do to have each generation of young EEs to start yet another cargo cult every 5 years or so, wasting valuable resources in the attempt to pack twice as much transistors per wafer.
DenisM 11y ago
To this day this piece from 1987 remains one of the most wanted pieces of wisdom: I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding. The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach. Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.
- MalcolmDwyer 11y ago
  Cool quote. Maybe now we "grow" software, in the sense that any application consists of probably thousands of interconnected systems/libraries/frameworks that work together in a way that is organic or emergent.
pron 11y ago
I remember how, as a young programmer, how hopeful I was that this technique (OO, RAD, "Components") or that language (Scheme, ML -- those two were the "ancient secret knowledge" that we "rediscovered" and our bosses had "overlooked" -- C++, Ada) will change programming forever and make software development completely different, and how angry I was at the experienced developers who told me that the most approaches will fail, and the best few would only yield perhaps significant, but evolutionary rather than revolutionary advances. Now I'm the one saying this to others... I think that two specific advances did end up yielding significant (though evolutionary) progress since that text was written: automatic garbage collection, and automated testing practices. Both were viewed with skepticism, the latter with some derision, but they have both helped us out of a real crisis of the software industry in the nineties, when too many projects just couldn't get off the ground (or, rather, continuously crashed).
- slacka 11y ago
  Yes, the world would be a better place if young minds all stopped dreaming and accepted the wisdom of the elders. There's nothing left to explore. </sarcasm>
  - pron 11y ago
    Boy, are you a pessimist! That's not at all the message. The message is about working towards progress rather than jumping from one fad to the next with blind faith that something will "save" us. It's a call for technological progress rather than an alchemist's semi-religious search for a way to turn lead into gold.
    - slacka 11y ago
      My first reaction after reading the paper was similar to yours. That I had fallen for the OOP hype train. Later when my boss cited it as an excuse to iterate our aging platform instead of attempting a redesign, my view of it began to change. It's true many technologies have been overhyped, but it's far too early to throw in the towel. A little over optimistic youth fueled zeal, has let to some of our greatest advances. I think Bret Victor sums my views up best here: http://worrydream.com/dbx/ http://worrydream.com/dbx/
osullivj 11y ago
And here's Brad Cox's rejoinder... http://virtualschool.edu/cox/pub/NoSilverBulletRevisted/ http://virtualschool.edu/cox/pub/NoSilverBulletRevisted/ Planning the Software Industrial Revolution is also a classic... http://virtualschool.edu/cox/pub/PSIR/ http://virtualschool.edu/cox/pub/PSIR/
elihu 11y ago
I wonder if people don't take the wrong lesson from this essay. There might not be any single 10x productivity-enhancing technology, but there have been many modest improvements. I think it's fair to say that a good programmer in 2015 is probably 10x more productive than a good programmer in 1995. Someone reading this today might be tempted to dismiss tools they just don't understand as "not a silver bullet". However, even modest improvements are worth striving for, and if you only adopt what is "industry standard", you'll always be behind your early-adopter peers. (Or at least, those of your early-adopter peers who have good enough taste to distinguish a good, useful technology from the next shiny new thing that isn't ready for production and may never be.) Things that have been a boon to me have been getting into Linux back in the early days when it was new-ish, the arrival of Google, learning Haskell, learning to use source control (first svn, now git), and the availability of things like Stack Overflow and Wikipedia. If I had to go back to using the tools of the mid nineties (Borland Turbo C++ on Windows 3.1, NCSA Mosaic and a 14.4kbps modem, 33mhz processors, 8 megs of ram, etc...), I could still sort of get stuff done as a programmer but really we've come a long long way since then.
- nickbauman 11y ago
  The biggest problems in tech are not technological but the social interaction of primary creative agents: those of us responsible for making great strides in magnifying human intellect. Those of us making the software.
  - kpil 11y ago
    The biggest problems that we could be better at, at least. One other hard problem is to figure out how to construct systems that are not so damn fragile. I am not talking about raid-5 here, but how to find ways to tackle the intrinsic complexity of our problems so that minor faults in our definitions and solutions will not cause catastrophically nonlinear crashes. Maybe that requires hard AI, but it would be nice if when developing the equivalent of a house, the boiler would not explode and destroy the house if one forgot to connect the doorbell. If you see what I mean. Back to the original topic: No I don't think an average developer is 10x more productive now, maybe 2x thanks to that it's so much easier to find information about everything, but the intrinsic complexity is still there, and we still have the same brains. Although I think that google and wikipedia are an enabler - For my hobby projects I can google and implement a really quick/smart algorithm that I probably would not find - less invent myself. However; It does not help the typical "enterprise" coder that is churning out boring code while trying to figure out ill-defined and complex rules. I believe though that the developer variance is 10x - at least when regarding long term maintainability. (Less time wasted on fixing old bugs, easier to implement new features, etc, etc.) Unfortunately, only a few people are required to complicate things beyond repair so the larger the team, the less does it matter. I just got reminded of my favourite observation: Complicated problems requires complicated solutions. It follows that if someone is a bit dense, all their problems are complicated. Therefore, the solutions will too be complicated.
carsongross 11y ago
I now believe there is one at least silver-alloy bullet: simplicity, painstakingly maintained and violently defended by well paid developers.
- TeMPOraL 11y ago
  It's less of a bullet and more of a main battle tank - without proper armament it won't defeat the target, but it does protect you and lets you drive through many obstacles like they weren't even there.
- DonaldFisk 11y ago
  Agreed. If they're allowed to. I wrote much the same thing here: http://web.onetel.com/~hibou/blog/NoSilverBullet.html http://web.onetel.com/~hibou/blog/NoSilverBullet.html One of the problems is that many people actually prefer complexity over simplicity for a variety of reasons: they wrote it, and it will be simplified over their dead bodies; or it needs all these features to satisfy all their lusers; or they want to show off how smart they are; or it's harder to reverse-engineer, ... Joel Spolsky (who otherwise talks a lot of sense) defends bloatware here: http://www.joelonsoftware.com/articles/fog0000000020.html http://www.joelonsoftware.com/articles/fog0000000020.html
- the_af 11y ago
  Everyone agrees with simplicity when stated in such general terms, but in practice, simplicity where? Note that simplicity in one piece of software often leads to complexity in another. For example, a language with a minimal set of instructions may be considered "simple", but building software with it can be complex and unwieldy. A minimalist API may be elegant and concise, but lead to headaches when attempting to use it. Etc, etc.
  - carsongross 11y ago
    I don't think there there is a good objective definition for simplicity, since a large component of what I'm getting at is subjective and context-dependent, and therefore involves "appropriateness". API design is different than app building is different than container building, etc. This is why good developers are so important. Regarding APIs, I like them to be layered: http://devblog.guidewire.com/2008/10/05/api-design/ http://devblog.guidewire.com/2008/10/05/api-design/ so that code built on top of them can be as simple as possible.
ageyfman 11y ago
Open source is surely a silver bullet that increased productivity 10x at least, for most of us.
ScottBurson 11y ago
I believe Brooks will eventually be proven wrong about AI and Automatic Programming. Granted, he has not been proven wrong yet. It is interesting, perhaps even a little surprising, that reasoning about programs has proven to be one of the most intractable challenges for AI. Why, to take a simple-sounding example, when my program does something wrong, can I not simply ask the machine why it did it? Why do I have to go in with a debugger and find the problem myself? This wouldn't require solutions to any of the familiar bugaboos of AI: it doesn't need a massive database of facts about the world, it doesn't require visual image recognition, it doesn't require natural language understanding, it doesn't require robotics or simulated emotions or any of those things. It just requires logical reasoning. Can't computers do that? Well, no, it turns out, they can't do it, not in its full generality. Despite all the things it doesn't require, general logical reasoning is still almost AI-complete, which is a cute way of saying we still don't know how to make machines do it. And fully general reasoning is required to solve the problem. We have lots of static analysis algorithms that can answer specific kinds of questions about programs, but we're still not very close to being able to answer an arbitrary question, even fairly simple ones. The spaces we would have to search are just too big; the branching factors are too high. I think there is hope on the horizon, though. The so-called automated reasoning systems that have been built over the last few decades -- also called theorem provers -- have mostly not made use of any machine learning techniques. These two technologies are starting to be combined, and machine learning is of course a very hot area right now. I believe that eventually we will have Automatic Programming worthy of the name as a result of this combination.

55 points by ayberkt 11y ago

crpatino 11y ago

This is required reading for every promising young hacker. The more promising, the more required.

slacka 11y ago
I couldn't disagree with you more. This paper offers no insight, only excuses to accept that software will always be buggy. If anything I'd encourage young engineers to explore technologies that have been not been explored to their fullest potential. Computer Science is a very young field and many unexplored paths such as flow based or some automated programming method that hasn't been dreamed up yet that may lead to far more reliable software. I dread to think what today's CPUs would be like if an electrical engineering version of this was required reading for every EE in the 70s. We should just accept buggy CPUs because of the complexity in designing CPUS with 7 billion transistors.
- pron 11y ago
  > This paper offers no insight, only excuses to accept that software will always be buggy. Is that how you read it? I read it as a call to accept an open eyed view of the industry and its advances, and tirelessly work to make progress rather than believe in messianic fads and jump from one to the next. It is optimistic yet realistic, and warns against unconstructive zeal.
- crpatino 11y ago
  > This paper offers no insight, only excuses to accept that software will always be buggy. The paper does not address the problem of buggy software, though it is related. It addresses the problem that software is complex. And the insight it offers is that not all complexity is equal: there is accidental complexity (programming is hard because the way we have done things historically is not yet optimized) and inherent complexity (programming is hard because we are modeling complex stuff and it is inherently hard for human minds to juggle all the relevant details). The excuses you complain about are really examples where people confuse one with the other. i.e. you cannot solve the problem of Requirement Gathering with better compilers because the problem is not technical, it is that stake holders are playing political games in the background, so if left to their own devices they'll give you vague, confusing requirements now with the tacit intention of leveraging those when the inevitable struggles come in the future. > I dread to think what today's CPUs would be like if an electrical engineering version of this was required reading for every EE in the 70s. I am sorry to inform you that an EE version of this will be direly needed in the near future. As the Moore law keeps hitting more and more fundamental limits of physics, we need engineers who are able to work in the problems that matter and make hardware that gives us the best possible performance given the constrains available. It would not do to have each generation of young EEs to start yet another cargo cult every 5 years or so, wasting valuable resources in the attempt to pack twice as much transistors per wafer.

DenisM 11y ago

To this day this piece from 1987 remains one of the most wanted pieces of wisdom: I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding. The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach. Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.

MalcolmDwyer 11y ago
Cool quote. Maybe now we "grow" software, in the sense that any application consists of probably thousands of interconnected systems/libraries/frameworks that work together in a way that is organic or emergent.

pron 11y ago

I remember how, as a young programmer, how hopeful I was that this technique (OO, RAD, "Components") or that language (Scheme, ML -- those two were the "ancient secret knowledge" that we "rediscovered" and our bosses had "overlooked" -- C++, Ada) will change programming forever and make software development completely different, and how angry I was at the experienced developers who told me that the most approaches will fail, and the best few would only yield perhaps significant, but evolutionary rather than revolutionary advances. Now I'm the one saying this to others... I think that two specific advances did end up yielding significant (though evolutionary) progress since that text was written: automatic garbage collection, and automated testing practices. Both were viewed with skepticism, the latter with some derision, but they have both helped us out of a real crisis of the software industry in the nineties, when too many projects just couldn't get off the ground (or, rather, continuously crashed).

slacka 11y ago
Yes, the world would be a better place if young minds all stopped dreaming and accepted the wisdom of the elders. There's nothing left to explore. </sarcasm>
- pron 11y ago
  Boy, are you a pessimist! That's not at all the message. The message is about working towards progress rather than jumping from one fad to the next with blind faith that something will "save" us. It's a call for technological progress rather than an alchemist's semi-religious search for a way to turn lead into gold.
  - slacka 11y ago
    My first reaction after reading the paper was similar to yours. That I had fallen for the OOP hype train. Later when my boss cited it as an excuse to iterate our aging platform instead of attempting a redesign, my view of it began to change. It's true many technologies have been overhyped, but it's far too early to throw in the towel. A little over optimistic youth fueled zeal, has let to some of our greatest advances. I think Bret Victor sums my views up best here: http://worrydream.com/dbx/ http://worrydream.com/dbx/

osullivj 11y ago

And here's Brad Cox's rejoinder... http://virtualschool.edu/cox/pub/NoSilverBulletRevisted/ http://virtualschool.edu/cox/pub/NoSilverBulletRevisted/ Planning the Software Industrial Revolution is also a classic... http://virtualschool.edu/cox/pub/PSIR/ http://virtualschool.edu/cox/pub/PSIR/

elihu 11y ago

I wonder if people don't take the wrong lesson from this essay. There might not be any single 10x productivity-enhancing technology, but there have been many modest improvements. I think it's fair to say that a good programmer in 2015 is probably 10x more productive than a good programmer in 1995. Someone reading this today might be tempted to dismiss tools they just don't understand as "not a silver bullet". However, even modest improvements are worth striving for, and if you only adopt what is "industry standard", you'll always be behind your early-adopter peers. (Or at least, those of your early-adopter peers who have good enough taste to distinguish a good, useful technology from the next shiny new thing that isn't ready for production and may never be.) Things that have been a boon to me have been getting into Linux back in the early days when it was new-ish, the arrival of Google, learning Haskell, learning to use source control (first svn, now git), and the availability of things like Stack Overflow and Wikipedia. If I had to go back to using the tools of the mid nineties (Borland Turbo C++ on Windows 3.1, NCSA Mosaic and a 14.4kbps modem, 33mhz processors, 8 megs of ram, etc...), I could still sort of get stuff done as a programmer but really we've come a long long way since then.

nickbauman 11y ago
The biggest problems in tech are not technological but the social interaction of primary creative agents: those of us responsible for making great strides in magnifying human intellect. Those of us making the software.
- kpil 11y ago
  The biggest problems that we could be better at, at least. One other hard problem is to figure out how to construct systems that are not so damn fragile. I am not talking about raid-5 here, but how to find ways to tackle the intrinsic complexity of our problems so that minor faults in our definitions and solutions will not cause catastrophically nonlinear crashes. Maybe that requires hard AI, but it would be nice if when developing the equivalent of a house, the boiler would not explode and destroy the house if one forgot to connect the doorbell. If you see what I mean. Back to the original topic: No I don't think an average developer is 10x more productive now, maybe 2x thanks to that it's so much easier to find information about everything, but the intrinsic complexity is still there, and we still have the same brains. Although I think that google and wikipedia are an enabler - For my hobby projects I can google and implement a really quick/smart algorithm that I probably would not find - less invent myself. However; It does not help the typical "enterprise" coder that is churning out boring code while trying to figure out ill-defined and complex rules. I believe though that the developer variance is 10x - at least when regarding long term maintainability. (Less time wasted on fixing old bugs, easier to implement new features, etc, etc.) Unfortunately, only a few people are required to complicate things beyond repair so the larger the team, the less does it matter. I just got reminded of my favourite observation: Complicated problems requires complicated solutions. It follows that if someone is a bit dense, all their problems are complicated. Therefore, the solutions will too be complicated.

carsongross 11y ago

I now believe there is one at least silver-alloy bullet: simplicity, painstakingly maintained and violently defended by well paid developers.

TeMPOraL 11y ago
It's less of a bullet and more of a main battle tank - without proper armament it won't defeat the target, but it does protect you and lets you drive through many obstacles like they weren't even there.
DonaldFisk 11y ago
Agreed. If they're allowed to. I wrote much the same thing here: http://web.onetel.com/~hibou/blog/NoSilverBullet.html http://web.onetel.com/~hibou/blog/NoSilverBullet.html One of the problems is that many people actually prefer complexity over simplicity for a variety of reasons: they wrote it, and it will be simplified over their dead bodies; or it needs all these features to satisfy all their lusers; or they want to show off how smart they are; or it's harder to reverse-engineer, ... Joel Spolsky (who otherwise talks a lot of sense) defends bloatware here: http://www.joelonsoftware.com/articles/fog0000000020.html http://www.joelonsoftware.com/articles/fog0000000020.html
the_af 11y ago
Everyone agrees with simplicity when stated in such general terms, but in practice, simplicity where? Note that simplicity in one piece of software often leads to complexity in another. For example, a language with a minimal set of instructions may be considered "simple", but building software with it can be complex and unwieldy. A minimalist API may be elegant and concise, but lead to headaches when attempting to use it. Etc, etc.
- carsongross 11y ago
  I don't think there there is a good objective definition for simplicity, since a large component of what I'm getting at is subjective and context-dependent, and therefore involves "appropriateness". API design is different than app building is different than container building, etc. This is why good developers are so important. Regarding APIs, I like them to be layered: http://devblog.guidewire.com/2008/10/05/api-design/ http://devblog.guidewire.com/2008/10/05/api-design/ so that code built on top of them can be as simple as possible.

ageyfman 11y ago

Open source is surely a silver bullet that increased productivity 10x at least, for most of us.

ScottBurson 11y ago

I believe Brooks will eventually be proven wrong about AI and Automatic Programming. Granted, he has not been proven wrong yet. It is interesting, perhaps even a little surprising, that reasoning about programs has proven to be one of the most intractable challenges for AI. Why, to take a simple-sounding example, when my program does something wrong, can I not simply ask the machine why it did it? Why do I have to go in with a debugger and find the problem myself? This wouldn't require solutions to any of the familiar bugaboos of AI: it doesn't need a massive database of facts about the world, it doesn't require visual image recognition, it doesn't require natural language understanding, it doesn't require robotics or simulated emotions or any of those things. It just requires logical reasoning. Can't computers do that? Well, no, it turns out, they can't do it, not in its full generality. Despite all the things it doesn't require, general logical reasoning is still almost AI-complete, which is a cute way of saying we still don't know how to make machines do it. And fully general reasoning is required to solve the problem. We have lots of static analysis algorithms that can answer specific kinds of questions about programs, but we're still not very close to being able to answer an arbitrary question, even fairly simple ones. The spaces we would have to search are just too big; the branching factors are too high. I think there is hope on the horizon, though. The so-called automated reasoning systems that have been built over the last few decades -- also called theorem provers -- have mostly not made use of any machine learning techniques. These two technologies are starting to be combined, and machine learning is of course a very hot area right now. I believe that eventually we will have Automatic Programming worthy of the name as a result of this combination.