There's still no silver bullet
changelog.com
changelog.com
> 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.
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_. ;)
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.
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...
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 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.)
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.