Mythical Man Month (opens in new tab)

>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

- How to win a Turing Award speech: https://www.youtube.com/watch?v=tw3gsBms-f8

- Thinking above the code: https://www.youtube.com/watch?v=-4Yp3j_jk8Q

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

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

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.

"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.

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.

"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

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.

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.

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.

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.

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.

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/

> 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.

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

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)

"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

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.

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.

I wonder if there's going to be a mythical AI month.

Adding AI to something makes it later/worse/slop

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.

"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.

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

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.

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.