9 ms·

Mythical Man Month

400 points by ingve 5mo ago

wewewedxfgdf 5mo ago
Look, I read it and loved it 25 hyears ago. Fred Brooks wrote that book when they were programming IBM operating systems in assembly language. Times have really, really changed - do not pay attention to the messages of this book unless for historical fun.
- yellowapple 5mo ago
  The lessons in that book have broadly held true for nearly every single one of my employers throughout the entirety of my career.
- gaigalas 5mo ago
  Our field is full of vague, terrible opinions and useless advice. Arrogant people that think they're better than others. That book isn't, it's built from humility and a rare bright light in this god forsaken field.
  - zephen 5mo ago
    The book is good. As you say, the author, Fred Brooks, is not at all arrogant. Martin Fowler, the author of the blog, may be a bit different than that.
- CreepGin 5mo ago
  IMHO, Brooks's Law applies more today than ever.
  - linsomniac 5mo ago
    I was half expecting Fowler to tie it in to right-sizing agent teams.
- freetime2 5mo ago
  Indeed a lot of things have changed. A worthwhile exercise is to read the book, contemplate how things have changed, and try to map lessons from the book onto modern technology and organizational practices. A LOT of the core principles are still relevant IMO, even if many of the implementation details are not.
- janalsncm 5mo ago
  Your comment and the OP both mention some things that are outdated about the book. What are those things?
- HarHarVeryFunny 5mo ago
  So men and months have suddenly become fungible ? You should tell these AI companies and we could have AGI tomorrow if only they would throw a few thousand more men on the project. Or perhaps today's men are coding agents? You can spin up as many agents as you care to, so asymptotically any project should be completable in zero time, regardless of complexity.
jdw64 5mo ago
[flagged]
- slopinthebag 5mo ago
  Once we ditch our centrally controlled economies perhaps life can be affordable enough to not prevent willing parents from having children.
  - jdw64 5mo ago
    I think Brooks would call that an optimistic schedule estimate.
  - Nifty3929 5mo ago
    Oddly from your comment I can't quite tell which end of the political spectrum you're on. I think I agree with you, but I'm not sure until I know which team you're on.
    - slopinthebag 5mo ago
      I bet depending on the questions you ask me I could be on either side :)
  - philwelch 5mo ago
    Life has never been more affordable than it is now. Virtually all of your ancestors were impoverished to a degree you can't even imagine.
    - slopinthebag 5mo ago
      Life was becoming increasingly more affordable, but that stopped being the case years ago. It is now declining. I would like it to either stay the same as it was years ago or start increasing again.
      - philwelch 5mo ago
alasdair_ 5mo ago
Notably, his essay “no silver bullet” states that there has never been a new technology or way of thinking or working that has led to a 10X increase in the speed of software development. That was true for almost seventy years until roughly last year. AI is the silver bullet - my output is genuinely 10X what it was before claude code existed.
- slopinthebag 5mo ago
  10x would only be possible if your output was low before Claude Code
  - hatsix 5mo ago
    I've found that I can have 10x output, so long as I don't expect anyone to review your code...
    - slopinthebag 5mo ago
      I can get 100x output, if we're counting lines of code!
      - emp17344 5mo ago
        I bet get I could hit 1000x output of random characters produced by smashing my hand against the keyboard.
- teddyh 5mo ago
  For your sake I hope that your pay is determined by your “output”, and not your long-term usefulness.
- jdw64 5mo ago
  [flagged]
  - altcognito 5mo ago
jh00ker 5mo ago
As a software engineering manager, I always look to staff up a project at the beginning as much as possible, looking for doing as much in parallel up-front as we can. If some things take longer than expected, then I already have a team of engineers with all the context since the project kicked off that can help each other with any longer running tasks. An engineer that has completed a smaller chunk of work can help out with the items on the critical path, for example.
- datadrivenangel 5mo ago
  Fred brooks would not necessarily endorse this.
  - jh00ker 5mo ago
    Please, say more! >I always look to staff up a project at the beginning as much as possible, looking for doing as much in parallel up-front as we can. Ah, maybe this is what you think he would take issue with? Fair enough. Perhaps I should have said: >I always look to staff up as much as is economically and organizationally optimal, to exploit all genuine parallelism opportunities, being careful not to overstaff.
    - pzoln 5mo ago
      You mileage may vary but in my (unfortunate) experience, stuffing up by any other reason than grassroots "we need more hands" raised by engineers themselves typically backfires. Teams that are constrained by people resources often find creative ways to work smarter. Teams that have an abundance of labor, often end up working unnecessarily harder, duplicating work, reinventing the wheel, not solving the right problems, etc. See also intensive vs extensive development.
      - erica123 5mo ago
        I agree with that
sutro 5mo ago
"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." -FB
- oleggromov 5mo ago
  When I was young, in my teens, I already knew a bit about programming but of course nothing about the industry. These beautiful metaphors by Brooks, from books like inmates running the asylum, etc - they made me romanticize the industry I had no idea about. Now, about 20 years later, I wonder to which extent they influenced me to take the path I've taken. Because when I began, it wasn't lucrative or cool in the slightest.
  - syncsynchalt 5mo ago
    It's funny, I also read the book as a teen, and I came away from it amazed that IBM was dedicating entire team members to inter-/extra-team communication. Before that I hadn't even considered how necessary a product manager or project manager were in software development. But it was the "No Silver Bullet" essay added as a bonus in my copy that I think about the most. "Never again will we see a 10x productivity increase in a decade", this is self-evident now but must have been crushing to people who had experienced the first compilers, the first high-level languages, the first interactive terminals, and waited for the next incredible leap.
manoDev 5mo ago
It’s easy to see the conceptual integrity in good software, architecture, design and movies — or the lack of this quality in the bad ones. Vibe coded software is the Marvel green screen movie equivalent.
nvader 5mo ago
Fortunate to be reminded of this right now, especially the pull-quote about conceptual integrity. This is the reason why AI-assisted programming has not turned out to be the silver bullet we have been hoping for, at least yet. Muddled prompting by humans gets you the Homer Simpson car you wished for, that will eventually collapse under its own weight. I've been thinking a lot about Programming as Theory Building [0] as the missing piece in AI-assisted engineering. Perhaps there are approaches which naturally focus on the essence while ignoring the accidents, but I'm still looking for them. Right now the state of the art I see ignores both accident and essence alike, and degrades the ability to make progress. Please inform me if there are any approaches you know that work! And lest this sound pessimistic, far from it. This state of affairs is actually intoxicatingly motivating. Feels like we have found silver, and just need to start learning to mould bullets. [0] Another classic required reading of the industry https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- boron1006 5mo ago
  This is a good way of putting it. I ship individual features faster, but the end to end process of shipping software has remained the roughly same because the vast majority of my time is building the “theory”.
- tclancy 5mo ago
  [flagged]
- noosphr 5mo ago
  We've found pyrite thinking it gold. Then we bought the whole saloon drinks and hookers. The hangover tomorrow morning will not be pleasant. And the bar tab even less so.
  - Nevermark 5mo ago
    If only it wasn't a dichotomy!
- physicles 5mo ago
  I love that Naur paper! Also love this essay that extends it: https://hiringengineersbook.com/post/autonomy/ https://hiringengineersbook.com/post/autonomy/ I literally maintain a conceptual-model.md that describes the “things” in our entire system, how they relate to each other, and some bits about how that maps to the code (the DB schema maps sort of closely to it but sometimes not that close, and so does the API, and that’s ok). I wrote most of the doc myself, but plan to coauthor with LLMs going forward. So far it’s saved me tons of typing as I add features. I don’t have enough data yet on how well it will guide myself and others when adding stuff that really stretches the model, but I’m also optimistic that it’s a valuable approach.
nemo1618 5mo ago
It's interesting to revisit Brooks' "surgical team" in light of AI. For example, I frequently have Claude act as a "toolsmith", creating bespoke project-specific tools on the fly, which are then documented in Skills that Claude can use going forward. What has changed is that a) One person (or rather, one person-AI hybrid) plays all the roles within the surgical team, and b) Internal frictions such as cost, development time, and communication overhead have all been dramatically slashed.
- rafaelmn 5mo ago
  How well does that work for you ? It's annoyingly inconsistent for me - I give it instructions on how to fetch JIRA ticket with a script that renders everything relevant to a .md and half of the time it will still default to reading it via ACLI. I have instructions on how to do a full build with warnaserror before commit but I still get pipeline errors regularly because it will skip the noincremental part, etc.
  - cyanydeez 5mo ago
    On a local model, with open code, when I wrote a specific javascript way to run sql queries because bash and psql were error prone, what I did was when I saw it make a mistake, I told it in passive agressive tones something like: "please edit AGENTS.md to detail how to use the query.js tool to run a query and to never use psql"; I did this two times until it stopped wanting to use psql. It seems like if you write the docs yourself that's not leveraging the probability that the model itself knows the anti-context guard rail that best prevents it from grabbing its average tool use.
  - ffsm8 5mo ago
    You may want to try out pi-agent and create custom extensions instead. Then codify this behavior into a process which automatically gets run through. I.e. $repo/origin as bare repo, then prompt to create a shell script which creates the worktree and cds into it, running the script you mentioned, instantiating pi in it. Potentially define explicit phases for your workflow and show the phase in the UI - and quality gates for transitions. Eg force the implment to finalize phase to only happen if all tests succeeded. Potentially add multiple review phases here too, with different prompts. This progressively gets rid of more and more inconsistencies. Still not a perfect solution, but on average I've had less and less to manually address with that workflow. Albeit at cost of tokens (multiple reviews phases obviously ingest all changes multiple time) Pi-agents extensibility is just a lot better then the other harnesses, but you could obviously also just introduce a different orchestrator to do the same. For me, pi-agent was just the least amount of effort necessary to get it going.
Nifty3929 5mo ago
I love this book, and I often recommend it to new folks on my team. I used to carry a few extra paperback copies to give away, just in case.
fukinstupid 5mo ago
[flagged]
jeffreygoesto 5mo ago
"Simple made Easy" is a nice add-on, the first half is the philosophical part and a classic. https://m.youtube.com/watch?v=SxdOUGdseq4 https://m.youtube.com/watch?v=SxdOUGdseq4
ForOldHack 5mo ago
"The most influential." is relative, I read it when it came out, and I had been programming for more than 20 years, there were 2 professors on the facility who were there... and confirmed much of it. 10 years later, while dipping back into academia again, it was a recommend read, so I read it again. 20 years later, the same thing happened... it influenced multiple generations of programmers and managers world wide. I am willing to read it again, and yes, it really is that influential.
jwr 5mo ago
I re-read that book every 10 years and try to think carefully about whether what Brooks wrote still holds. The last three times I read the book, everything held. This time, I'm not so sure: AI does change things significantly. Perhaps not for all teams and not all scales of software, but in my case (solo developer, complex software system) I did measure a 12x productivity increase [1]. Also, some of the problems Brooks describes became much easier, if not borderline trivial with AI. For example, maintaining design documentation that stays consistent with the software being built. I do this and it is no longer a problem. I still think most of what Brooks wrote is applicable today. I think the biggest difference is that AI enables smaller teams to work on larger systems, and the biggest benefit is for single-person teams (ahem) like me. I see it as another step that allows me to tackle larger systems: the previous one was Clojure which reduced incidental complexity so significantly that I was able to develop the system to the size it is today. AI is the next step: it allows me to build features that would have taken me years in a span of months. Not because of "vibe coding", but primarily because I can work on a set of design documents and turn my ideas into a coherent design. [1] For the nitpickers: yes, measured, not guessed. Yes, the metric was reasonable. No, it wasn't "lines of code" or something equally silly, in fact one of my main goals is reducing code size as much as possible. Yes, I compared larger time periods: 2 months with AI to an average of 12 months of the previous year. No, the metric wasn't gamed: this is a solo business and I have no interest in gaming my own metrics. I earn a living from this work, so this is as objective as it gets.
- aerhardt 5mo ago
  Dario Amodei said in the most recent interview with Dwarkesh that Anthropic currently gets achieves an increase of around 20-30% coding productivity, which tracks with my experience. What do you do to reap orders of magnitude more? Also, how much more money do you make? Or are you working less?
  - dnnddidiej 5mo ago
    I think if you build out simple sites it is 10x. That number tends to 1x as the project gets more complex. Side projects where you try an idea are you not finding 1h now to do what was 10h work?
ilitirit 5mo ago
"Conceptual integrity" is something I always try to adhere to when I design and build systems. I also use it also a bit of an indicator when gauging someone's experience. For example, mid-level devs will often try to introduce some form of "optimisation" somewhere in the codebase that results in the codeflow deviating from existing patterns. More often than not I will reject the PR, or the idea. For me, it's better than all flows follow similar paths. It makes it easier to reason and communicate ideas about, modularise and/or form logical groupings etc etc. This is also why one of my instructions to coding agents is that they adhere to established coding and testing patterns, even where they appear to be sub-optimal.
DeadEye2111 5mo ago
The funny thing is that adding agents to an AI-first project has similar issues (today). Agents stepping on each others toes, needing to manage state, communicate with each other, and divide up work that is planned ahead centrally. Agents accelerate, but don't reinvent the fundamentals of building products.
alexpotato 5mo ago
Anytime I read an article about increasing software delivery times, I think of this quote: “Through more vigorous computer programing and more sophisticated scheduling, it was possible to reduce the changeover period from two weeks to two days.” - Lee Iacocca (in his autobiography)
oytis 5mo ago
What is that? Does he let openclaw post for him? Wikipedia article on the same topic is more informative
deleted 5mo ago
[deleted]
cleifer 5mo ago
Loved Brooks’ and feel like I must’ve internalized his model because that’s all I care about anymore in dev. Coherence among the components (people or software) to produce something good. I think of if 100 pianos are tuned to the same tuning fork then they all play well together. AI accelerated iteration and undisciplined use seem to me the main risk lately. Drift from any prompting, accumulation of features, plausible looking patches that are actually slop. Wrote about this recently [0], it creates a dynamic where you aren’t just making the software less coherent, you’re paying more and more to make it so. Curious to hear others experience of this. [0] https://charlesleifer.com/blog/tokens-and-dreams/ https://charlesleifer.com/blog/tokens-and-dreams/
gobdovan 5mo ago
>He argues that conceptual integrity comes from both simplicity and straightforwardness If you want to follow this advice, I think Leslie Lamport's formulation is the most concrete. His version is: - Write down a small model of what you are about to build before building it. - Try to see how that model could fail. If it still looks good, either make the spec/design doc/model clearer and more concrete, or start writing the code. - If plain text gets too vague, use math. If you want tools to check it, use TLA+ with TLC or Apalache. Quint and stateright.rs are nearby tools in the same area. --- Materials: - TLA+ videocourse by Lamport: https://lamport.azurewebsites.net/video/videos.html https://lamport.azurewebsites.net/video/videos.html - How to win a Turing Award speech: https://www.youtube.com/watch?v=tw3gsBms-f8 https://www.youtube.com/watch?v=tw3gsBms-f8 - Thinking above the code: https://www.youtube.com/watch?v=-4Yp3j_jk8Q https://www.youtube.com/watch?v=-4Yp3j_jk8Q
moi2388 5mo ago
When I first heard about the book I accidentally read it as “Mythical Man Moth” and was deeply intrigued how this was about software development and immeasurably disappointed when I found out it was “month” instead.
- phforms 5mo ago
  Same, I always misread the title like this when it comes up and it amuses me for a while, since it sounds like it could be a book written by Franz Kafka.
matchagaucho 5mo ago
In agentic design, I keep coming back to the idea of “how easily we can compose elements”, along with Fowler’s OOP and refactoring principles. It’s a new frontier, and there are no absolutes. But I suspect the most durable AI systems will be built around highly composable, well-orchestrated agents.
bbaron63 5mo ago
When it comes to Brooks's Law and AI, will trying to incorporate AI tools into a late project, make the project later? Probably. I'm glad I'm close to retiring. AI has been a mixed blessing for me. I don't have the desire at this stage to do all the wrangling necessary to incorporate AI tools effectively into my workflow.
daviding 5mo ago
"Adding tokens to a late software project makes it bigger and still late."
rwoerz 5mo ago
> The issue here is communication, as the number of people grows, the number of communication paths between those people grows exponentially. Exponentially? Quadratically I would say.
mickgardner 5mo ago
I'm living this hell right now. Management just keep hiring developers. Coordination and communication between them and product managers gets more difficult. Management keep agreeing to unrealistic timelines on new projects, yet haven't completed the old projects yet. The architecture of the codebase is so convoluted and confusing that new devs take a very long time to get anywhere close to productive and self sufficient. Time to develop and release acceptable features gets longer and longer. On top of all that, senior devs and tech leads are very up tight about code quality and 'how to write your code' yet can't even agree with each other on 'how to write your code' leading to Pull Request hell for devs and occasional whole week rewrites. I'd buy a copy of this book and put it on my bosses desk, but he won't read it.
- phyzix5761 5mo ago
  Best advice I ever got was to let management fail on their unrealistic deadlines. You do this enough times and they'll start to get more realistic.
m463 5mo ago
I wonder if there's going to be a mythical AI month. Adding AI to something makes it later/worse/slop
z3ratul163071 5mo ago
so much bad software was written because of this guy (Martin) selling snakeoil
- wickedsickeune 5mo ago
  Are you confusing him with Robert C Martin?

400 points by ingve 5mo ago

Look, I read it and loved it 25 hyears ago. Fred Brooks wrote that book when they were programming IBM operating systems in assembly language. Times have really, really changed - do not pay attention to the messages of this book unless for historical fun.

yellowapple 5mo ago
The lessons in that book have broadly held true for nearly every single one of my employers throughout the entirety of my career.
gaigalas 5mo ago
Our field is full of vague, terrible opinions and useless advice. Arrogant people that think they're better than others. That book isn't, it's built from humility and a rare bright light in this god forsaken field.
- zephen 5mo ago
  The book is good. As you say, the author, Fred Brooks, is not at all arrogant. Martin Fowler, the author of the blog, may be a bit different than that.
CreepGin 5mo ago
IMHO, Brooks's Law applies more today than ever.
- linsomniac 5mo ago
  I was half expecting Fowler to tie it in to right-sizing agent teams.
freetime2 5mo ago
Indeed a lot of things have changed. A worthwhile exercise is to read the book, contemplate how things have changed, and try to map lessons from the book onto modern technology and organizational practices. A LOT of the core principles are still relevant IMO, even if many of the implementation details are not.
janalsncm 5mo ago
Your comment and the OP both mention some things that are outdated about the book. What are those things?
HarHarVeryFunny 5mo ago
So men and months have suddenly become fungible ? You should tell these AI companies and we could have AGI tomorrow if only they would throw a few thousand more men on the project. Or perhaps today's men are coding agents? You can spin up as many agents as you care to, so asymptotically any project should be completable in zero time, regardless of complexity.

jdw64 5mo ago

[flagged]

slopinthebag 5mo ago
Once we ditch our centrally controlled economies perhaps life can be affordable enough to not prevent willing parents from having children.
- jdw64 5mo ago
  I think Brooks would call that an optimistic schedule estimate.
- Nifty3929 5mo ago
  Oddly from your comment I can't quite tell which end of the political spectrum you're on. I think I agree with you, but I'm not sure until I know which team you're on.
  - slopinthebag 5mo ago
    I bet depending on the questions you ask me I could be on either side :)
- philwelch 5mo ago
  Life has never been more affordable than it is now. Virtually all of your ancestors were impoverished to a degree you can't even imagine.
  - slopinthebag 5mo ago
    Life was becoming increasingly more affordable, but that stopped being the case years ago. It is now declining. I would like it to either stay the same as it was years ago or start increasing again.
    - philwelch 5mo ago

alasdair_ 5mo ago

Notably, his essay “no silver bullet” states that there has never been a new technology or way of thinking or working that has led to a 10X increase in the speed of software development. That was true for almost seventy years until roughly last year. AI is the silver bullet - my output is genuinely 10X what it was before claude code existed.

slopinthebag 5mo ago
10x would only be possible if your output was low before Claude Code
- hatsix 5mo ago
  I've found that I can have 10x output, so long as I don't expect anyone to review your code...
  - slopinthebag 5mo ago
    I can get 100x output, if we're counting lines of code!
    - emp17344 5mo ago
      I bet get I could hit 1000x output of random characters produced by smashing my hand against the keyboard.
teddyh 5mo ago
For your sake I hope that your pay is determined by your “output”, and not your long-term usefulness.
jdw64 5mo ago
[flagged]
- altcognito 5mo ago

jh00ker 5mo ago

As a software engineering manager, I always look to staff up a project at the beginning as much as possible, looking for doing as much in parallel up-front as we can. If some things take longer than expected, then I already have a team of engineers with all the context since the project kicked off that can help each other with any longer running tasks. An engineer that has completed a smaller chunk of work can help out with the items on the critical path, for example.

datadrivenangel 5mo ago
Fred brooks would not necessarily endorse this.
- jh00ker 5mo ago
  Please, say more! >I always look to staff up a project at the beginning as much as possible, looking for doing as much in parallel up-front as we can. Ah, maybe this is what you think he would take issue with? Fair enough. Perhaps I should have said: >I always look to staff up as much as is economically and organizationally optimal, to exploit all genuine parallelism opportunities, being careful not to overstaff.
  - pzoln 5mo ago
    You mileage may vary but in my (unfortunate) experience, stuffing up by any other reason than grassroots "we need more hands" raised by engineers themselves typically backfires. Teams that are constrained by people resources often find creative ways to work smarter. Teams that have an abundance of labor, often end up working unnecessarily harder, duplicating work, reinventing the wheel, not solving the right problems, etc. See also intensive vs extensive development.
    - erica123 5mo ago
      I agree with that

sutro 5mo ago

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." -FB

oleggromov 5mo ago
When I was young, in my teens, I already knew a bit about programming but of course nothing about the industry. These beautiful metaphors by Brooks, from books like inmates running the asylum, etc - they made me romanticize the industry I had no idea about. Now, about 20 years later, I wonder to which extent they influenced me to take the path I've taken. Because when I began, it wasn't lucrative or cool in the slightest.
- syncsynchalt 5mo ago
  It's funny, I also read the book as a teen, and I came away from it amazed that IBM was dedicating entire team members to inter-/extra-team communication. Before that I hadn't even considered how necessary a product manager or project manager were in software development. But it was the "No Silver Bullet" essay added as a bonus in my copy that I think about the most. "Never again will we see a 10x productivity increase in a decade", this is self-evident now but must have been crushing to people who had experienced the first compilers, the first high-level languages, the first interactive terminals, and waited for the next incredible leap.

manoDev 5mo ago

It’s easy to see the conceptual integrity in good software, architecture, design and movies — or the lack of this quality in the bad ones. Vibe coded software is the Marvel green screen movie equivalent.

nvader 5mo ago

Fortunate to be reminded of this right now, especially the pull-quote about conceptual integrity. This is the reason why AI-assisted programming has not turned out to be the silver bullet we have been hoping for, at least yet. Muddled prompting by humans gets you the Homer Simpson car you wished for, that will eventually collapse under its own weight. I've been thinking a lot about Programming as Theory Building [0] as the missing piece in AI-assisted engineering. Perhaps there are approaches which naturally focus on the essence while ignoring the accidents, but I'm still looking for them. Right now the state of the art I see ignores both accident and essence alike, and degrades the ability to make progress. Please inform me if there are any approaches you know that work! And lest this sound pessimistic, far from it. This state of affairs is actually intoxicatingly motivating. Feels like we have found silver, and just need to start learning to mould bullets. [0] Another classic required reading of the industry https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf

boron1006 5mo ago
This is a good way of putting it. I ship individual features faster, but the end to end process of shipping software has remained the roughly same because the vast majority of my time is building the “theory”.
tclancy 5mo ago
[flagged]
noosphr 5mo ago
We've found pyrite thinking it gold. Then we bought the whole saloon drinks and hookers. The hangover tomorrow morning will not be pleasant. And the bar tab even less so.
- Nevermark 5mo ago
  If only it wasn't a dichotomy!
physicles 5mo ago
I love that Naur paper! Also love this essay that extends it: https://hiringengineersbook.com/post/autonomy/ https://hiringengineersbook.com/post/autonomy/ I literally maintain a conceptual-model.md that describes the “things” in our entire system, how they relate to each other, and some bits about how that maps to the code (the DB schema maps sort of closely to it but sometimes not that close, and so does the API, and that’s ok). I wrote most of the doc myself, but plan to coauthor with LLMs going forward. So far it’s saved me tons of typing as I add features. I don’t have enough data yet on how well it will guide myself and others when adding stuff that really stretches the model, but I’m also optimistic that it’s a valuable approach.

nemo1618 5mo ago

It's interesting to revisit Brooks' "surgical team" in light of AI. For example, I frequently have Claude act as a "toolsmith", creating bespoke project-specific tools on the fly, which are then documented in Skills that Claude can use going forward. What has changed is that a) One person (or rather, one person-AI hybrid) plays all the roles within the surgical team, and b) Internal frictions such as cost, development time, and communication overhead have all been dramatically slashed.

rafaelmn 5mo ago
How well does that work for you ? It's annoyingly inconsistent for me - I give it instructions on how to fetch JIRA ticket with a script that renders everything relevant to a .md and half of the time it will still default to reading it via ACLI. I have instructions on how to do a full build with warnaserror before commit but I still get pipeline errors regularly because it will skip the noincremental part, etc.
- cyanydeez 5mo ago
  On a local model, with open code, when I wrote a specific javascript way to run sql queries because bash and psql were error prone, what I did was when I saw it make a mistake, I told it in passive agressive tones something like: "please edit AGENTS.md to detail how to use the query.js tool to run a query and to never use psql"; I did this two times until it stopped wanting to use psql. It seems like if you write the docs yourself that's not leveraging the probability that the model itself knows the anti-context guard rail that best prevents it from grabbing its average tool use.
- ffsm8 5mo ago
  You may want to try out pi-agent and create custom extensions instead. Then codify this behavior into a process which automatically gets run through. I.e. $repo/origin as bare repo, then prompt to create a shell script which creates the worktree and cds into it, running the script you mentioned, instantiating pi in it. Potentially define explicit phases for your workflow and show the phase in the UI - and quality gates for transitions. Eg force the implment to finalize phase to only happen if all tests succeeded. Potentially add multiple review phases here too, with different prompts. This progressively gets rid of more and more inconsistencies. Still not a perfect solution, but on average I've had less and less to manually address with that workflow. Albeit at cost of tokens (multiple reviews phases obviously ingest all changes multiple time) Pi-agents extensibility is just a lot better then the other harnesses, but you could obviously also just introduce a different orchestrator to do the same. For me, pi-agent was just the least amount of effort necessary to get it going.

Nifty3929 5mo ago

I love this book, and I often recommend it to new folks on my team. I used to carry a few extra paperback copies to give away, just in case.

fukinstupid 5mo ago

[flagged]

jeffreygoesto 5mo ago

"Simple made Easy" is a nice add-on, the first half is the philosophical part and a classic. https://m.youtube.com/watch?v=SxdOUGdseq4 https://m.youtube.com/watch?v=SxdOUGdseq4

ForOldHack 5mo ago

"The most influential." is relative, I read it when it came out, and I had been programming for more than 20 years, there were 2 professors on the facility who were there... and confirmed much of it. 10 years later, while dipping back into academia again, it was a recommend read, so I read it again. 20 years later, the same thing happened... it influenced multiple generations of programmers and managers world wide. I am willing to read it again, and yes, it really is that influential.

jwr 5mo ago

I re-read that book every 10 years and try to think carefully about whether what Brooks wrote still holds. The last three times I read the book, everything held. This time, I'm not so sure: AI does change things significantly. Perhaps not for all teams and not all scales of software, but in my case (solo developer, complex software system) I did measure a 12x productivity increase [1]. Also, some of the problems Brooks describes became much easier, if not borderline trivial with AI. For example, maintaining design documentation that stays consistent with the software being built. I do this and it is no longer a problem. I still think most of what Brooks wrote is applicable today. I think the biggest difference is that AI enables smaller teams to work on larger systems, and the biggest benefit is for single-person teams (ahem) like me. I see it as another step that allows me to tackle larger systems: the previous one was Clojure which reduced incidental complexity so significantly that I was able to develop the system to the size it is today. AI is the next step: it allows me to build features that would have taken me years in a span of months. Not because of "vibe coding", but primarily because I can work on a set of design documents and turn my ideas into a coherent design. [1] For the nitpickers: yes, measured, not guessed. Yes, the metric was reasonable. No, it wasn't "lines of code" or something equally silly, in fact one of my main goals is reducing code size as much as possible. Yes, I compared larger time periods: 2 months with AI to an average of 12 months of the previous year. No, the metric wasn't gamed: this is a solo business and I have no interest in gaming my own metrics. I earn a living from this work, so this is as objective as it gets.

aerhardt 5mo ago
Dario Amodei said in the most recent interview with Dwarkesh that Anthropic currently gets achieves an increase of around 20-30% coding productivity, which tracks with my experience. What do you do to reap orders of magnitude more? Also, how much more money do you make? Or are you working less?
- dnnddidiej 5mo ago
  I think if you build out simple sites it is 10x. That number tends to 1x as the project gets more complex. Side projects where you try an idea are you not finding 1h now to do what was 10h work?

ilitirit 5mo ago

"Conceptual integrity" is something I always try to adhere to when I design and build systems. I also use it also a bit of an indicator when gauging someone's experience. For example, mid-level devs will often try to introduce some form of "optimisation" somewhere in the codebase that results in the codeflow deviating from existing patterns. More often than not I will reject the PR, or the idea. For me, it's better than all flows follow similar paths. It makes it easier to reason and communicate ideas about, modularise and/or form logical groupings etc etc. This is also why one of my instructions to coding agents is that they adhere to established coding and testing patterns, even where they appear to be sub-optimal.

DeadEye2111 5mo ago

The funny thing is that adding agents to an AI-first project has similar issues (today). Agents stepping on each others toes, needing to manage state, communicate with each other, and divide up work that is planned ahead centrally. Agents accelerate, but don't reinvent the fundamentals of building products.

alexpotato 5mo ago

Anytime I read an article about increasing software delivery times, I think of this quote: “Through more vigorous computer programing and more sophisticated scheduling, it was possible to reduce the changeover period from two weeks to two days.” - Lee Iacocca (in his autobiography)

oytis 5mo ago

What is that? Does he let openclaw post for him? Wikipedia article on the same topic is more informative

deleted 5mo ago

[deleted]

cleifer 5mo ago

Loved Brooks’ and feel like I must’ve internalized his model because that’s all I care about anymore in dev. Coherence among the components (people or software) to produce something good. I think of if 100 pianos are tuned to the same tuning fork then they all play well together. AI accelerated iteration and undisciplined use seem to me the main risk lately. Drift from any prompting, accumulation of features, plausible looking patches that are actually slop. Wrote about this recently [0], it creates a dynamic where you aren’t just making the software less coherent, you’re paying more and more to make it so. Curious to hear others experience of this. [0] https://charlesleifer.com/blog/tokens-and-dreams/ https://charlesleifer.com/blog/tokens-and-dreams/

gobdovan 5mo ago

>He argues that conceptual integrity comes from both simplicity and straightforwardness If you want to follow this advice, I think Leslie Lamport's formulation is the most concrete. His version is: - Write down a small model of what you are about to build before building it. - Try to see how that model could fail. If it still looks good, either make the spec/design doc/model clearer and more concrete, or start writing the code. - If plain text gets too vague, use math. If you want tools to check it, use TLA+ with TLC or Apalache. Quint and stateright.rs are nearby tools in the same area. --- Materials: - TLA+ videocourse by Lamport: https://lamport.azurewebsites.net/video/videos.html https://lamport.azurewebsites.net/video/videos.html - How to win a Turing Award speech: https://www.youtube.com/watch?v=tw3gsBms-f8 https://www.youtube.com/watch?v=tw3gsBms-f8 - Thinking above the code: https://www.youtube.com/watch?v=-4Yp3j_jk8Q https://www.youtube.com/watch?v=-4Yp3j_jk8Q

moi2388 5mo ago

When I first heard about the book I accidentally read it as “Mythical Man Moth” and was deeply intrigued how this was about software development and immeasurably disappointed when I found out it was “month” instead.

phforms 5mo ago
Same, I always misread the title like this when it comes up and it amuses me for a while, since it sounds like it could be a book written by Franz Kafka.

matchagaucho 5mo ago

In agentic design, I keep coming back to the idea of “how easily we can compose elements”, along with Fowler’s OOP and refactoring principles. It’s a new frontier, and there are no absolutes. But I suspect the most durable AI systems will be built around highly composable, well-orchestrated agents.

bbaron63 5mo ago

When it comes to Brooks's Law and AI, will trying to incorporate AI tools into a late project, make the project later? Probably. I'm glad I'm close to retiring. AI has been a mixed blessing for me. I don't have the desire at this stage to do all the wrangling necessary to incorporate AI tools effectively into my workflow.

daviding 5mo ago

"Adding tokens to a late software project makes it bigger and still late."

rwoerz 5mo ago

> The issue here is communication, as the number of people grows, the number of communication paths between those people grows exponentially. Exponentially? Quadratically I would say.

mickgardner 5mo ago

I'm living this hell right now. Management just keep hiring developers. Coordination and communication between them and product managers gets more difficult. Management keep agreeing to unrealistic timelines on new projects, yet haven't completed the old projects yet. The architecture of the codebase is so convoluted and confusing that new devs take a very long time to get anywhere close to productive and self sufficient. Time to develop and release acceptable features gets longer and longer. On top of all that, senior devs and tech leads are very up tight about code quality and 'how to write your code' yet can't even agree with each other on 'how to write your code' leading to Pull Request hell for devs and occasional whole week rewrites. I'd buy a copy of this book and put it on my bosses desk, but he won't read it.

phyzix5761 5mo ago
Best advice I ever got was to let management fail on their unrealistic deadlines. You do this enough times and they'll start to get more realistic.

m463 5mo ago

I wonder if there's going to be a mythical AI month. Adding AI to something makes it later/worse/slop

z3ratul163071 5mo ago

so much bad software was written because of this guy (Martin) selling snakeoil

wickedsickeune 5mo ago
Are you confusing him with Robert C Martin?