7 ms·

There's still no silver bullet

52 points by fagnerbrack 3y ago

tboyd47 3y ago
And silver bullets become even more non-existent each year.
mrkeen 3y ago
Read the next paragraph after that damn silver bullet quote: > Skepticism is not pessimism, however. Although we see no startling breakthroughs, and indeed, believe such to be inconsistent with the nature of software, many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit them should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road. Stop using the quote as an excuse to dismiss tech. Exploit tech instead.
- jbandela1 3y ago
  And there have been order of magnitude improvements before. For example, Visual Basic was an order of magnitude improvement in creating Windows form based applications over programming then using the Windows API.
- c_crank 3y ago
  Gradual improvements are the finest quality coffee for a programmer's mug. I would quite enjoy a future of writing clean, procedural programs with an improved C standard, VMs that are cleaner and easier to set up, and the latest edition of vanillajs
  - bitwize 3y ago
    If you want to write clean procedural programs with an improvement over C, you know where to find Free Pascal :)
    - c_crank 3y ago
      I actually don't know where to find Free Pascal - the question of which kind of Pascal and which compiler / build environment to use always seemed leery for someone looking for a Better C type language.
      - bitwize 3y ago
        https://www.freepascal.org/ https://www.freepascal.org/ It's also likely in your favorite distro's repo. Among Pascal fans, Free Pascal is generally considered "the way" because it's closest to Turbo Pascal/Delphi.
        AstralStorm 3y ago
        It is an Object Pascal (8 I believe?) implementation - has a backwards compatible unextended mode that matches Delphi. It does have a few extras of its own, especially improved assembly and C integrations. Lazarus is the open Delphi libraries implementation that uses it.
  - erichocean 3y ago
    > I would quite enjoy a future of writing clean, procedural programs with an improved C standard That would look a lot like the Zig language, it's delightful to use. What Rust is to C++, Zig is to C.
    - einpoklum 3y ago
      > What Rust is to C++, Zig is to C. No, they don't relate at all in the same way. (And that's not to mention the lack of consensus about what Rust is to C++...) That being said - Zig is quite the interesting language.
      - Karrot_Kream 3y ago
        At a 5000 ft level, I think it makes sense. C++ strives for zero-cost abstractions and lots of complexity with a side effect of making development more tractable for large teams with varying levels of familiarity with the codebase. Rust does the same thing, but uses different tools and levels. C has much lower language complexity but also requires longer onboarding times for engineers new to a project, at the cost of some sharp footguns that an experienced practitioner can avoid. Zig relative to Rust falls closer to this than a zero-cost abstraction based high-complexity language. Obviously the devil is in the details and Zig and C are very different languages, but I think the analogy stands well.
- jerf 3y ago
  We already are. Everyone nowadays moves much faster than when Brooks was writing. Who remembers a world where wanting a hash table meant you coded a hash table, and looked like a wizard while doing it? Now our problem with hash tables is people using them too freely without understanding the consequences.
  - namaria 3y ago
    The point of the quote is that hard problems require hard solutions. The mentality of seeking easy solutions is the problem. It took decades to yield the improvements we've seen since Brooks was active (in the 60s!). And still here we are, with hundreds of SaaS offerings that promise to deliver the remedy to all your systemic and organizational ills, and turns out to be yet another snowflake in a growing pile. We dig ourselves deeper into complexity year after year because that's what people are incentivized to do. Yet the warning that we should take a systemic view and be patient has been with us for two generations now.
  - kaba0 3y ago
    It literally was the point of Brooks that the only significant productivity boost is using other people’s software.
- kaycebasques 3y ago
  That's amazing, thanks for sharing. At large the technical writing community is dismissing generative AI. Of course I don't think it's a silver bullet but I have also been frustrated at this knee-jerk rejection. This quote really sums up my own thoughts and feelings beautifully.
- Avshalom 3y ago
  To be sure, regular bullets can still pretty if you aren't actually fighting werewolves.
pkoird 3y ago
Plenty of new technologies like version control, containerization, CI/CD, coupled with some robust modern languages with an arsenal of libraries come as close to the silver bullet as one can in my opinion. LLMs specially are pretty promising for the future of programming.
- bluquark 3y ago
  Brooks' definition of a silver bullet was "an order of magnitude improvement" and certainly none of those innovations individually come anywhere close. But I agree it's plausible that combined they might amount to one single order-of-magnitude improvement (as compared to average early-1980s development), for the subset of organizations that apply all of them together effectively. In my personal experience at my workplace I've certainly observed many times that the quote "Adding manpower to a late software project makes it later." is not universally true. When things go well, onboarding an experienced engineer and assigning them a parallelizable task has often proved a relatively lightweight process on teams I've been on, and I've seen the new member's productivity rapidly exceed their communication burden on the rest of the team. That might be explainable by how several of the innovations you listed reduce the need for communication between humans. For example, we now need less communication about regressions since CI/CD alerts the responsible party immediately, and we need to ask fewer questions when individuals can examine the entire history of a codebase in version control themselves. (That doesn't mean Fred Brooks's work is now obsolete, this story is consistent with Brooks's underlying analysis of the problem.)
  - sokoloff 3y ago
    What fraction of late projects have all those ingredients in place and readily identified, parallelized tasks needing to be started? I feel like part of the Brooks quote’s premise is that late projects got that way by some reason and those reasons are rarely amenable to more bodies. (That’s to suggest “if you have a choice to add programmers to a late project or an on-schedule one, you might be better off doing the latter if overall delivery is your goal.”)
  - kaba0 3y ago
    An often under-appreciated part of the original paper is effectively libraries - code you don’t have to write yourself. This is absolutely the biggest contribution to productivity improvements over that time period, and I think that we don’t always make good use of them (NIH syndrome, it’s not written in my favorite language, etc). Seriously, if there is a good quality library for the task already, just use it! That’s why python is where it is today in the data science community, and is also the reason why I will start any new project on the JVM unless there is a good reason not to. (The third contender for the biggest ecosystem is JS, and while it has similarly vast amount of packages, I found their average quality is behind that of the JVM’s)
wilg 3y ago
The problem is much harder than arguing against a "panacea". That's a classic straw-man – it's very rare for somebody to actually believe a new tool will solve "all their problems". The difficulty is you might find a tool that could solve many of your problems but has trade-offs. Some of which are foreseeable and some which are not. Predicting and weighing those is the hard part, not disabusing people of the notion of a perfect solution.
TheAceOfHearts 3y ago
There's also the saying of the golden hammer, where everything starts to look like a nail. But honestly, for a lot of problems whatever tool you're most familiar and comfortable with is probably going to be the best. This is especially true if the alternative is that nothing at all ends up getting built. Facebook got written in PHP originally and then they migrated as needed. Twitter was written in Rails and then they migrated as needed. Postgres is an amazing default choice for a database, especially if you're already familiarized with it and you don't have much expertise within the domain.
roycebranning 3y ago
"Good tools are hard to find, hard to evaluate, hard to learn. We have constraints, we have biases, we have shortcomings. But that’s all part of the work." Before I worked at a startup I was obsessed with learning the latest and greatest tool. Then I learned that the best thing to get the job done is usually the thing you already know. Now I'm back to indexing heavily on researching the right tool for the job. I feel this is the cycle that we are destined to repeat again and again.
Tade0 3y ago
> Good tools are hard to find, hard to evaluate, hard to learn. I outsource the first two to ChatGPT. Results are mixed, but at least I have a starting point.
- einpoklum 3y ago
  So, you use ChatGPT to find other tools? To evaluate tools? I doubt your second statement is true, because I doubt ChatGPT is trustworthy in evaluating things (seeing how it doesn't evaluate anything itself, and has no particular bias towards making truthful statements). Your first statement - maybe. Care to elaborate a little on ChatGPT as a tool-finder?
  - sokoloff 3y ago
    ChatGPT is reasonably good at parroting the more frequently expressed opinions as written by others. That seems like it would be a decent match to both turn up unknown-to-GP tools as well as surfacing frequently cited evaluation elements. ChatGPT doesn’t have an inherent bias towards truthfulness, but it does have a bias towards repeating things it has “read”, so to the extent that those tend towards truthful over false, it has an emergent bias towards truthfulness.
    - Tade0 3y ago
      Precisely. It gives me the sum total of the dev community's biases. Had I asked someone, I would just get one person's opinion. ...Or an answer generated by ChatGPT, because people tend to do that when they don't know what to say.
  - Tade0 3y ago
    I just ask "what's the best library to do X?". It gives me a range of results with descriptions. Then it's up to me to actually check if any of them fit my use case - the first one that does is selected. It's not foolproof though. Last time I was searching for a WASM version of the Opus codec that would work both in the browser and in Node, and in some cases the solution didn't work beyond the simplest of examples, but the author apparently was unaware of that.
mikewarot 3y ago
We've had a lot of tools that were orders of magnitude faster than previous approaches to programming. Visual Basic/VBA/Delphi/Hypercard et al, made it possible for domain experts to get usable applications built, with little to no programmer involvement. That was a HUGE improvement in our productivity. We've got IDEs that compile in a flash, compared to the interminable compiles of the past. That's a huge improvement to productivity. We could have capability based security, which makes it possible for a user to run any code without risking any side effects to files other than the ones they choose, like being able to plug in any lamp without burning down the house... but we haven't figured out, en masse, that we need that one yet. We've got GIT, which is a huge improvement over ZIP files of source code stored on floppy disks. We've got GitHub, GitLab, etc... the ability to quickly and easily work from home, office, laptop and keep them all in sync, or any other coherent relation (working on a feature branch, etc) without major hassle... is amazingly productive. We've got silver bullets everywhere.
- lasereyes136 3y ago
  This the the normal progress Brooks wrote about. Yes, we have things that have made our lives better or allowed us to make the things about programming that are accidentally hard, easier. The no silver bullets means that there is no magic that is going to make all parts of software development easy or instant. Some parts of creating software is still hard and might very well always be hard. Getting good requirements is one of those things that has been hard, still is hard, and might be hard for as long as we are building software.
- SanderNL 3y ago
  > Visual Basic/VBA/Delphi/Hypercard Most of these are gone. Not replaced by something better IMO. Excel is holding on though. > We've got IDEs that compile in a flash, compared to the interminable compiles of the past. That's a huge improvement to productivity. Compilers are faster, IDEs got slower. Tech stacks got fat. Things got distributed. Shit’s complex now. But I’ll give you git. Git is a win indeed.
- mtlynch 3y ago
  The things you mentioned are not silver bullets, as Brooks defined them. A "silver bullet" is a: >single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity. To take an easy example: >We've got GIT, which is a huge improvement over ZIP files of source code stored on floppy disks. This is a huge improvement over the previous flow of passing around ZIP files, but it doesn't yield an order of magnitude gain in overall productivity for a dev team. For it to yield a 10x improvement, it would mean that programmers were spending at least 90% of their time passing around source code. It's for sure an order of magnitude improvement on the subtask of code collaboration, but it's not a silver bullet in itself. I think collectively there have been advancements that have produced an order of magnitude improvement in dev productivity, but Brooks' claim was that there would be no one thing that eliminated 90% of a developer's work.
Brendinooo 3y ago
> Have a shiny hammer that looks great for hitting screws? > I know there’s React-based command line builders… And it’s like, okay, if you like components, cool. That makes sense. But why is React building your command-line app? I just don’t understand. > When I extemporaneously said “I just don’t understand”, I meant that the choice confounds me. But I do understand why people might make it. The rhetorical error here is the hammer and screw thing. Think of it more like: you need a table. If you're good at woodworking, make the legs out of wood. If you're a welder, make it out of pipe. If you're a mason, make it out of stone. Is one of those materials better than others? Depends on which variable you value - cost, aesthetics, weight, resale, etc. But ultimately, if you just need a table and you need to build it, use what you know to make it. (Ink is cool. I already knew React and was familiar with yoga so it was perfect for what I needed to do with it.)
aaron695 3y ago
[dead]
haha69 3y ago
LLM's feel like a silver bullet. Lets see.

52 points by fagnerbrack 3y ago

And silver bullets become even more non-existent each year.

Read the next paragraph after that damn silver bullet quote: > Skepticism is not pessimism, however. Although we see no startling breakthroughs, and indeed, believe such to be inconsistent with the nature of software, many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit them should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road. Stop using the quote as an excuse to dismiss tech. Exploit tech instead.

jbandela1 3y ago
And there have been order of magnitude improvements before. For example, Visual Basic was an order of magnitude improvement in creating Windows form based applications over programming then using the Windows API.
c_crank 3y ago
Gradual improvements are the finest quality coffee for a programmer's mug. I would quite enjoy a future of writing clean, procedural programs with an improved C standard, VMs that are cleaner and easier to set up, and the latest edition of vanillajs
- bitwize 3y ago
  If you want to write clean procedural programs with an improvement over C, you know where to find Free Pascal :)
  - c_crank 3y ago
    I actually don't know where to find Free Pascal - the question of which kind of Pascal and which compiler / build environment to use always seemed leery for someone looking for a Better C type language.
    - bitwize 3y ago
      https://www.freepascal.org/ https://www.freepascal.org/ It's also likely in your favorite distro's repo. Among Pascal fans, Free Pascal is generally considered "the way" because it's closest to Turbo Pascal/Delphi.
      - AstralStorm 3y ago
        It is an Object Pascal (8 I believe?) implementation - has a backwards compatible unextended mode that matches Delphi. It does have a few extras of its own, especially improved assembly and C integrations. Lazarus is the open Delphi libraries implementation that uses it.
- erichocean 3y ago
  > I would quite enjoy a future of writing clean, procedural programs with an improved C standard That would look a lot like the Zig language, it's delightful to use. What Rust is to C++, Zig is to C.
  - einpoklum 3y ago
    > What Rust is to C++, Zig is to C. No, they don't relate at all in the same way. (And that's not to mention the lack of consensus about what Rust is to C++...) That being said - Zig is quite the interesting language.
    - Karrot_Kream 3y ago
      At a 5000 ft level, I think it makes sense. C++ strives for zero-cost abstractions and lots of complexity with a side effect of making development more tractable for large teams with varying levels of familiarity with the codebase. Rust does the same thing, but uses different tools and levels. C has much lower language complexity but also requires longer onboarding times for engineers new to a project, at the cost of some sharp footguns that an experienced practitioner can avoid. Zig relative to Rust falls closer to this than a zero-cost abstraction based high-complexity language. Obviously the devil is in the details and Zig and C are very different languages, but I think the analogy stands well.
jerf 3y ago
We already are. Everyone nowadays moves much faster than when Brooks was writing. Who remembers a world where wanting a hash table meant you coded a hash table, and looked like a wizard while doing it? Now our problem with hash tables is people using them too freely without understanding the consequences.
- namaria 3y ago
  The point of the quote is that hard problems require hard solutions. The mentality of seeking easy solutions is the problem. It took decades to yield the improvements we've seen since Brooks was active (in the 60s!). And still here we are, with hundreds of SaaS offerings that promise to deliver the remedy to all your systemic and organizational ills, and turns out to be yet another snowflake in a growing pile. We dig ourselves deeper into complexity year after year because that's what people are incentivized to do. Yet the warning that we should take a systemic view and be patient has been with us for two generations now.
- kaba0 3y ago
  It literally was the point of Brooks that the only significant productivity boost is using other people’s software.
kaycebasques 3y ago
That's amazing, thanks for sharing. At large the technical writing community is dismissing generative AI. Of course I don't think it's a silver bullet but I have also been frustrated at this knee-jerk rejection. This quote really sums up my own thoughts and feelings beautifully.
Avshalom 3y ago
To be sure, regular bullets can still pretty if you aren't actually fighting werewolves.

pkoird 3y ago

Plenty of new technologies like version control, containerization, CI/CD, coupled with some robust modern languages with an arsenal of libraries come as close to the silver bullet as one can in my opinion. LLMs specially are pretty promising for the future of programming.

bluquark 3y ago
Brooks' definition of a silver bullet was "an order of magnitude improvement" and certainly none of those innovations individually come anywhere close. But I agree it's plausible that combined they might amount to one single order-of-magnitude improvement (as compared to average early-1980s development), for the subset of organizations that apply all of them together effectively. In my personal experience at my workplace I've certainly observed many times that the quote "Adding manpower to a late software project makes it later." is not universally true. When things go well, onboarding an experienced engineer and assigning them a parallelizable task has often proved a relatively lightweight process on teams I've been on, and I've seen the new member's productivity rapidly exceed their communication burden on the rest of the team. That might be explainable by how several of the innovations you listed reduce the need for communication between humans. For example, we now need less communication about regressions since CI/CD alerts the responsible party immediately, and we need to ask fewer questions when individuals can examine the entire history of a codebase in version control themselves. (That doesn't mean Fred Brooks's work is now obsolete, this story is consistent with Brooks's underlying analysis of the problem.)
- sokoloff 3y ago
  What fraction of late projects have all those ingredients in place and readily identified, parallelized tasks needing to be started? I feel like part of the Brooks quote’s premise is that late projects got that way by some reason and those reasons are rarely amenable to more bodies. (That’s to suggest “if you have a choice to add programmers to a late project or an on-schedule one, you might be better off doing the latter if overall delivery is your goal.”)
- kaba0 3y ago
  An often under-appreciated part of the original paper is effectively libraries - code you don’t have to write yourself. This is absolutely the biggest contribution to productivity improvements over that time period, and I think that we don’t always make good use of them (NIH syndrome, it’s not written in my favorite language, etc). Seriously, if there is a good quality library for the task already, just use it! That’s why python is where it is today in the data science community, and is also the reason why I will start any new project on the JVM unless there is a good reason not to. (The third contender for the biggest ecosystem is JS, and while it has similarly vast amount of packages, I found their average quality is behind that of the JVM’s)

wilg 3y ago

The problem is much harder than arguing against a "panacea". That's a classic straw-man – it's very rare for somebody to actually believe a new tool will solve "all their problems". The difficulty is you might find a tool that could solve many of your problems but has trade-offs. Some of which are foreseeable and some which are not. Predicting and weighing those is the hard part, not disabusing people of the notion of a perfect solution.

TheAceOfHearts 3y ago

There's also the saying of the golden hammer, where everything starts to look like a nail. But honestly, for a lot of problems whatever tool you're most familiar and comfortable with is probably going to be the best. This is especially true if the alternative is that nothing at all ends up getting built. Facebook got written in PHP originally and then they migrated as needed. Twitter was written in Rails and then they migrated as needed. Postgres is an amazing default choice for a database, especially if you're already familiarized with it and you don't have much expertise within the domain.

roycebranning 3y ago

"Good tools are hard to find, hard to evaluate, hard to learn. We have constraints, we have biases, we have shortcomings. But that’s all part of the work." Before I worked at a startup I was obsessed with learning the latest and greatest tool. Then I learned that the best thing to get the job done is usually the thing you already know. Now I'm back to indexing heavily on researching the right tool for the job. I feel this is the cycle that we are destined to repeat again and again.

Tade0 3y ago

> Good tools are hard to find, hard to evaluate, hard to learn. I outsource the first two to ChatGPT. Results are mixed, but at least I have a starting point.

einpoklum 3y ago
So, you use ChatGPT to find other tools? To evaluate tools? I doubt your second statement is true, because I doubt ChatGPT is trustworthy in evaluating things (seeing how it doesn't evaluate anything itself, and has no particular bias towards making truthful statements). Your first statement - maybe. Care to elaborate a little on ChatGPT as a tool-finder?
- sokoloff 3y ago
  ChatGPT is reasonably good at parroting the more frequently expressed opinions as written by others. That seems like it would be a decent match to both turn up unknown-to-GP tools as well as surfacing frequently cited evaluation elements. ChatGPT doesn’t have an inherent bias towards truthfulness, but it does have a bias towards repeating things it has “read”, so to the extent that those tend towards truthful over false, it has an emergent bias towards truthfulness.
  - Tade0 3y ago
    Precisely. It gives me the sum total of the dev community's biases. Had I asked someone, I would just get one person's opinion. ...Or an answer generated by ChatGPT, because people tend to do that when they don't know what to say.
- Tade0 3y ago
  I just ask "what's the best library to do X?". It gives me a range of results with descriptions. Then it's up to me to actually check if any of them fit my use case - the first one that does is selected. It's not foolproof though. Last time I was searching for a WASM version of the Opus codec that would work both in the browser and in Node, and in some cases the solution didn't work beyond the simplest of examples, but the author apparently was unaware of that.

mikewarot 3y ago

We've had a lot of tools that were orders of magnitude faster than previous approaches to programming. Visual Basic/VBA/Delphi/Hypercard et al, made it possible for domain experts to get usable applications built, with little to no programmer involvement. That was a HUGE improvement in our productivity. We've got IDEs that compile in a flash, compared to the interminable compiles of the past. That's a huge improvement to productivity. We could have capability based security, which makes it possible for a user to run any code without risking any side effects to files other than the ones they choose, like being able to plug in any lamp without burning down the house... but we haven't figured out, en masse, that we need that one yet. We've got GIT, which is a huge improvement over ZIP files of source code stored on floppy disks. We've got GitHub, GitLab, etc... the ability to quickly and easily work from home, office, laptop and keep them all in sync, or any other coherent relation (working on a feature branch, etc) without major hassle... is amazingly productive. We've got silver bullets everywhere.

lasereyes136 3y ago
This the the normal progress Brooks wrote about. Yes, we have things that have made our lives better or allowed us to make the things about programming that are accidentally hard, easier. The no silver bullets means that there is no magic that is going to make all parts of software development easy or instant. Some parts of creating software is still hard and might very well always be hard. Getting good requirements is one of those things that has been hard, still is hard, and might be hard for as long as we are building software.
SanderNL 3y ago
> Visual Basic/VBA/Delphi/Hypercard Most of these are gone. Not replaced by something better IMO. Excel is holding on though. > We've got IDEs that compile in a flash, compared to the interminable compiles of the past. That's a huge improvement to productivity. Compilers are faster, IDEs got slower. Tech stacks got fat. Things got distributed. Shit’s complex now. But I’ll give you git. Git is a win indeed.
mtlynch 3y ago
The things you mentioned are not silver bullets, as Brooks defined them. A "silver bullet" is a: >single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity. To take an easy example: >We've got GIT, which is a huge improvement over ZIP files of source code stored on floppy disks. This is a huge improvement over the previous flow of passing around ZIP files, but it doesn't yield an order of magnitude gain in overall productivity for a dev team. For it to yield a 10x improvement, it would mean that programmers were spending at least 90% of their time passing around source code. It's for sure an order of magnitude improvement on the subtask of code collaboration, but it's not a silver bullet in itself. I think collectively there have been advancements that have produced an order of magnitude improvement in dev productivity, but Brooks' claim was that there would be no one thing that eliminated 90% of a developer's work.

Brendinooo 3y ago

> Have a shiny hammer that looks great for hitting screws? > I know there’s React-based command line builders… And it’s like, okay, if you like components, cool. That makes sense. But why is React building your command-line app? I just don’t understand. > When I extemporaneously said “I just don’t understand”, I meant that the choice confounds me. But I do understand why people might make it. The rhetorical error here is the hammer and screw thing. Think of it more like: you need a table. If you're good at woodworking, make the legs out of wood. If you're a welder, make it out of pipe. If you're a mason, make it out of stone. Is one of those materials better than others? Depends on which variable you value - cost, aesthetics, weight, resale, etc. But ultimately, if you just need a table and you need to build it, use what you know to make it. (Ink is cool. I already knew React and was familiar with yoga so it was perfect for what I needed to do with it.)

aaron695 3y ago

[dead]

haha69 3y ago

LLM's feel like a silver bullet. Lets see.