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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.)
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.”)
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)
> LLMs specially are pretty promising for the future of programming.
How? I am sorry, but I don't get the optimism. I have used GPT4 for over two months now in various projects and got very mixed results. It has been fun to use, but it hasn't increased my productivity at all. The time I gained with the tasks it completed successfully without much tinkering was unfortunately compensated by many tasks that gave misleading or erroneous results, which I had to first find (not fun) and then fix either on my own or, again, with the help of GPT.
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.
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.
"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.
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?
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.
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.
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.
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.
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.
Who cares. When the first silver bullet tech that appeases his requirement comes along, my blog post will require 100x improvements in productivity, reliability, and simplicity.
"overall productivity" isn't necessarily the bar. If you're spending 1 hour a week managing git and you used to spend 10 hours a week managing zip files, it's an order of magnitude improvement.
If we're evaluating whether Brooks was correct in his "no silver bullet" prediction, then overall productivity is the bar because his prediction was about overall productivity of a dev team.
I agree that git improves productivity over passing around zip files, but it doesn't disprove Brooks' prediction.
Fair point, in the context of a silver bullet his intent was clearly to describe a single thing that improved productivity across the board. I had to go re-read the paper to reset my perspective.
I get your point but, no, it’s not for the same reason Amdahl’s law exists: if you already weren’t taking any significant time on something, even cutting the whole thing out would give you negligible benefits.
> 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.
Until it needs to maintained and scaled.
My first job out of college was to rewrite a data entry system for a state government used to enter crime statistics. They used Microsoft Access.
Well, if the domain expert wrote the first pass at it, think of the cycles of writing specifications, design, programming, and only then finding out the specs were wrong, got skipped.
That's a huge time savings, and as a bonus you have working code to refactor or use as a specification.
Microsoft Access is an amazing database, it manages related tables automatically, and can scale up to working with ODBC and SQL database back ends easily.
We also have cloud servers now, meaning deploying your application is a credit card swipe away, instead of having to set up and maintain your own servers.
> We've got GIT, which is a huge improvement over ZIP files of source code stored on floppy disks.
Real Programmers stored their source code on magnetic tapes, that is if they weren't using punch cards or paper tapes. RCS, the first open source version control system, predates PKZIP by a good five years, and SCCS, the first version control system, is only a year younger than the first commercially available floppy disk drive.
But never mind that. Git was at most an incremental improvement over its direct predecessor, BitKeeper, or the other popular version control systems at the time, like Subversion. Git wasn't even unique. The open source DVCSes Arch, darcs, and Monotone all predate Git, and Mercurial was started just a few days after Git. Our hacker parents and grandparents might be old, but they aren't _savages_. ;)
> 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.)
47 comments
[ 4.2 ms ] story [ 98.7 ms ] thread> 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.
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.
Lazarus is the open Delphi libraries implementation that uses it.
That would look a lot like the Zig language, it's delightful to use.
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.
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.
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.)
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)
How? I am sorry, but I don't get the optimism. I have used GPT4 for over two months now in various projects and got very mixed results. It has been fun to use, but it hasn't increased my productivity at all. The time I gained with the tasks it completed successfully without much tinkering was unfortunately compensated by many tasks that gave misleading or erroneous results, which I had to first find (not fun) and then fix either on my own or, again, with the help of GPT.
Maybe I am doing something wrong...
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.
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.
I outsource the first two to ChatGPT. Results are mixed, but at least I have a starting point.
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?
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.
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.
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.
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.
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.
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.
>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.
If we're evaluating whether Brooks was correct in his "no silver bullet" prediction, then overall productivity is the bar because his prediction was about overall productivity of a dev team.
I agree that git improves productivity over passing around zip files, but it doesn't disprove Brooks' prediction.
Git is possibly better at distributed teams.
Until it needs to maintained and scaled.
My first job out of college was to rewrite a data entry system for a state government used to enter crime statistics. They used Microsoft Access.
That's a huge time savings, and as a bonus you have working code to refactor or use as a specification.
Microsoft Access is an amazing database, it manages related tables automatically, and can scale up to working with ODBC and SQL database back ends easily.
Real Programmers stored their source code on magnetic tapes, that is if they weren't using punch cards or paper tapes. RCS, the first open source version control system, predates PKZIP by a good five years, and SCCS, the first version control system, is only a year younger than the first commercially available floppy disk drive.
But never mind that. Git was at most an incremental improvement over its direct predecessor, BitKeeper, or the other popular version control systems at the time, like Subversion. Git wasn't even unique. The open source DVCSes Arch, darcs, and Monotone all predate Git, and Mercurial was started just a few days after Git. Our hacker parents and grandparents might be old, but they aren't _savages_. ;)
> 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.)