He cites Brooks as proving that communication friction is quadratic in headcount. The exponent does not need to be exactly, or even nearly, 2; 1 + epsilon is already fatal. This is very closely related to Coase's ceiling.
There’s a good list of reasons why we do this, but it leaves out the biggest one, at least for me: building stuff is fun. Reinventing stuff is fun. It’s the most natural hammer to reach for whenever I encounter a nail. Not necessarily the best, but such is life.
Man I love and agree with nearly everything about this post except that I wouldn't take the advice to follow waterfall or PMBOK literally.
The post laments that it's hard to find Dr. Royce's original waterfall paper. That's probably true, I have my copy from a compilation book “Ideas that Created the Future: Classic Papers of Computer Science” edited by Lewis [1].
I do agree that it's important to do things like scope out your demands of your AI agent, check-in on progress, give as clear a requirement and test cases as you can. But you've always been able to do that with agile methods, and LLMs are fast enough that you don't need to go full waterfall (and if anything it would be counter productive).
Dr. Royce's paper talks about literally thousands of pages of documentation being needed for any reasonably useful system. Good luck fitting that into even a 1M context window :P.
But the main point to thesis, that you can't just let your coders loose to do whatever and expect the right results even pre-dates Fred Brooks. I'd argue it goes all the way back to the beginning, to the comments about Baggage's computing machine where British politicians asked if it would generate the correct answers even with incorrect inputs.
The answer then is the same answer today: of course not, and expecting anything different is foolishness.
Relatedly, I fully expect the software business to fail to learn from (nearly) literally every other industry how to operate when your marginal costs are no longer zero. It drives me nuts the number of people in software who think that people in other industries are slow because they’re just not as smart as us, rather than because when it takes months to get a cast part made, it better be right the first time.
Another obnoxious behaviour I’ve observed lately, is trying to attach whatever pre-existing pet methodologies one had to the AI-hype bandwagon like some sort of personal vindication orgy.
I'm a hands on engineering leader for a team of about 20 engineers and I've been spending the past 6 months trying to get my team to understand just this.
On Friday we had a coffee hour to share how we've been working recently and they all seemed perplexed at the workflows I've been adopting. It seems natural to me as someone who's been a manager for some time now, but very alien to all those who've never gone down that path.
That's not to say my workflows are superior, but they're extremely different to some of my teams now. In reality it's just leaning heavily on things like prds, limiting communication between agents, etc.
I don’t quite understand the management analogy. Agents aren’t people, they’re code generation machines. Part of managing is delegating and trusting the output of your employees without having to verify everything yourself. But if you’re “managing” an agent, how does that work? You can’t exactly hold an LLM responsible if it fucks something up.
Or are people really just yoloing and not even verifying that the code generation is correct? I know it’s a bit of a meme, but are people actually doing the meme in irl where there are actual consequences??
Nobody gets rewarded for rejecting the newfangled thing. Even when the newfangled thing should be rejected. Same as scientific papers are very biased against reporting nulls.
As someone that has studied engineering, designing a solution is very different than managing the resources around the design and implementation of that solution. Books like The Mythical Man Month and Making Things Happen deals with the management side, (from a team level) and The Pragmatic Programmer is from a personal level.
But TFA is ignoring the actual engineering side where you have to grapple with some primitives and assemble them in a way that do something valuable. And so in a way that is cost effective. That part is always answered by hand waves.
>You can make lots of money by making something appear novel and undiscovered, and consequently make yourself sound smart and cutting edge. Nobody raises a round to apply a well understood discipline correctly.
I'm curious about this. I thought investors preferred safe bets?
On the other hand, I know that if you're too early, it can be impossible to make a business work (or even to pitch the idea in the first place).
This is mostly wrong as far as motivation is concerned. Some people just by default figure stuff out with what they know. Others accumulate knowledge. If you go too far in either direction you are probably going to struggle, but it's just different people having different nature.
This isn't an issue for engineers only, it is basically ingrained in the current system in the world. The problem is in simple terms; the fact that being a polymath is absurdly hard in today's world.
You can't not reinvent something if you don't know it exists in the first place.
The thing about software is that it slots nicely into every other field, making it a _very_ good base to work off of to get concepts (aka the modern bootleg polymath) that have likely been invented in other fields (with different names).
The author missed one key motivation: giant fucking ego. I don’t know why every damn software engineer thinks they are gods gift and can derive anything from first principles. The OP hinted at it with the physicist XKCD but I think it is far more dominant in software because the payouts for mediocrity are just astronomical.
36 comments
[ 1.00 ms ] story [ 9.9 ms ] threadThis is pretty much the crux of it. It's very similar to the strategy of undercutting a market with VC subsidies until it dies and can be replaced.
The post laments that it's hard to find Dr. Royce's original waterfall paper. That's probably true, I have my copy from a compilation book “Ideas that Created the Future: Classic Papers of Computer Science” edited by Lewis [1].
I do agree that it's important to do things like scope out your demands of your AI agent, check-in on progress, give as clear a requirement and test cases as you can. But you've always been able to do that with agile methods, and LLMs are fast enough that you don't need to go full waterfall (and if anything it would be counter productive).
Dr. Royce's paper talks about literally thousands of pages of documentation being needed for any reasonably useful system. Good luck fitting that into even a 1M context window :P.
But the main point to thesis, that you can't just let your coders loose to do whatever and expect the right results even pre-dates Fred Brooks. I'd argue it goes all the way back to the beginning, to the comments about Baggage's computing machine where British politicians asked if it would generate the correct answers even with incorrect inputs.
The answer then is the same answer today: of course not, and expecting anything different is foolishness.
[1] https://www.amazon.com/dp/0262045303
On Friday we had a coffee hour to share how we've been working recently and they all seemed perplexed at the workflows I've been adopting. It seems natural to me as someone who's been a manager for some time now, but very alien to all those who've never gone down that path.
That's not to say my workflows are superior, but they're extremely different to some of my teams now. In reality it's just leaning heavily on things like prds, limiting communication between agents, etc.
Or are people really just yoloing and not even verifying that the code generation is correct? I know it’s a bit of a meme, but are people actually doing the meme in irl where there are actual consequences??
But TFA is ignoring the actual engineering side where you have to grapple with some primitives and assemble them in a way that do something valuable. And so in a way that is cost effective. That part is always answered by hand waves.
I'm curious about this. I thought investors preferred safe bets?
On the other hand, I know that if you're too early, it can be impossible to make a business work (or even to pitch the idea in the first place).
Related: You can't tell people anything (2004)
https://web.archive.org/web/20091025030730/https://habitatch...
Sometimes two or more developers may appear to coexist, but it's actually a simulated concurrency achieved by rapid context switching
Every time you close a file to open another, you are setting up a different context, therefore you are different agents.
You can't not reinvent something if you don't know it exists in the first place.
The thing about software is that it slots nicely into every other field, making it a _very_ good base to work off of to get concepts (aka the modern bootleg polymath) that have likely been invented in other fields (with different names).