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.
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.
Yes, the future of software as an institution, if there is any, is driven by the loudest voices. Those loudest voices are thus driven by selected personalities as opposed to any accomplishment or title. The people who are the highest achievers are rarely the loudest voices as they tend to be the people spending time solving real problems as opposed to the people who just talk about themselves, the forest for the trees.
Not sure it’s obvious reasons, but understandable, sure. When someone questions your credentials the default is to tell them to jump, whether that’s a good idea or not.
Absolutely. Engineering is defined by it learning from history, it's an art build up from thousands of years of human attempts to alter the world around them. In a modern sense engineers inevitably require a certain amount of schooling, certification, and most critically of all professional and ethical standards.
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.
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.
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.
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.
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.
This 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.
FOMO is going to kill more americans than COVID.
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
I think it needs to be updated to just say "Those who can't do, go into software engineering". Teachers don't deserve that crap.
Never heard anyone say that about software engineering.