The Mythical Man-Month

What Hacker News says

1. ajrouvoetOct 2026
   I enjoyed the introduction. I just picked up “The mind of the Maker” by Sayers, which Fred Brooks cites in The Mythical Man Month: “ Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages: the idea, the implementation, and the interaction. A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author.” He goes on to say how the user meets the mind of the maker in the interaction: “The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker.”
   Show morethread
2. v64Oct 2026
   Those who haven't read Mythical Man Month are doomed to repeat it. I don't recall anywhere in the book where it states that the problems described in its essays don't apply to you if you're working with dozens of the most intelligent engineers in the world who can produce code in hours instead of days.

   I was discussing this with someone else and used the analogy of nuclear energy. Although nuclear plants are highly complex and use forces that have only been understood for the last hundred years, at the end of the day it's still boiling water to create steam to spin a turbine, and nothing about nuclear innovation can engineer away the laws of thermodynamics.

   Agents have and will continue to drastically change how we develop code, but it's my belief that drastically changing our software practices to speed up development just means we're going to hit engineering limits faster, rather than being able to overcome those limits entirely.

   Show morethread
3. mixmastamykOct 2026
   > not being taught enough history of computing

   Are they being taught any of significance? In school I only remember a blurb about Newton here or a blurb about Pascal there. Briefest of mentions about Unix at the start of a C class.

   All the rest I had to dig up myself, from the Mythical Man Month to Edwin Black's book. Believe it was the Joel on Software blog who got me interested in those type of books, never knew they existed in school.

   Show morethread
4. nilamoJun 2026
   I have no understanding of your viewpoint. I wish I did, it sounds interesting. I do like a Crafting Interpreters or Mythical Man Month...

   But I don't understand how those could not only be held to the same level as The Hobbit, but that you seem incapable of even reading Animal Farm.

   Do you enjoy any fictional media? TV, movies, plays, interactive murder mystery dinners, tabletop games (d&d, etc)?

   thread
5. bondoloJun 2026
   Early in my career I read "Peopleware" by Tom DeMarco and Timothy Lister. Between that book Brooks' "Mythical Man Month" and Humphrey's "Managing the Software Process" it seemed that there was hope for the software industry learning some necessary lessons and growing to become a true engineering discipline. Nope. Never happened. The industry standard, despite improvements in some areas, is still a farcical shitshow with little beyond lipservice to process, predictability or proper self-evaluation. I can only describe agile, as it is practised, more of a coping mechanism than an actual methodology. Indeed the methodology is embodied mostly in the infrastructure; issue tracking, version control, code review, continuous integration with as little methodology glue between them as required to produce output.

   Modern first and second tier software management seems less professional, is contributing less and is generally worse than it was twenty years ago. The quality of the engineering and program managers, their training and commitment to their craft seems really low and is not generally valued. On average team level software management has gotten worse rather than better and, given what is expected and how it is valued, this shouldn't be much of a surprise. It is truly disappointing that what could have been a valuable and productivity enhancing role became so useless.

   Things aren't going to change for the better though until the dust settles somewhat on the role of AI in software and systems development and we start again to consider how software should be developed in the 21st century. Maybe it is possible that with AI doing most of the low-level work that the focus will change to building and maintaining architecture and systems. Many programmers might become more like traditional engineers doing a lot more systems work than they do today and continuing to solve problems. Lord knows though it won't be today's software management doing this work; they have nothing in the way of skills to offer to the problem.

   Show morethread
6. renticulousMay 2026
   Amazing tweet.

   https://x.com/stevesi/status/2050325415793951124

   Here's how history rhymes with this logic. The development of compilers v writing assembly language was not without a very similar "controversy" — that is, are the new tools more efficient or less efficient.

   The first compilers were measured relative to hand-tuned assembly language efficiency. The existing world of compute was very much "compute bound" and inefficient code was being chased out of every system.

   The introduction of the first compilers generally delivered code "within 10-30%" as efficient as standard professional assembly. This "benchmark" was enough for almost a generation of Fortran programmers to dismiss the capabilities of compilers.

   Also worth noting, early compilers (all through the 1980s) routinely had bugs that generated incorrect code. Debugging a compiler is a nightmare (personal experience). This only provided more "ammo."

   With the arrival of COBOL the debate started to shift. COBOL generated decidedly "bloated" code so there was no way to win the efficiency argument. But what people started to realize was that a "modern" programming language made it possible to deliver vastly more software and for many more people to work on the same code (ASM notorious for being challenging for multiple engineers on the same portion of code). So the metric slowly started to move from "as good as hand tuned assembler" to "able to write bigger, more sophisticated code in less time with more people). Computers gained timesharing, more memory, and faster CPUs which made the efficiency argument far less compelling (only to repeat with the first 8K or 64K PCs).

   This entire transition is capped off with a description in Fred Brooks "Mythical Man Month" book, one of the seminal books in the field of programming and standard issue book sitting in my office waiting for me on my first day at Microsoft. (See full book free here https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythic...)

   It is very early. I was not a programmer when the above happened though I did join the professional ranks while many still held these beliefs. For example, I interned writing COBOL on mainframes while PCs were using C and Pascal which were buggy and viewed as inefficient on processor/space-constrained PCs.

   The debate would continue with C++, garbage collection, interpreted v compiled (Visual Basic) and more. As a fairly consistent observation over decades, every new tool is viewed through a lens (at first) by experienced programmers over what is worse while new programmers use the tool and operate in a new context (eg "more software" or "bigger projects"). The excerpt below shows this debate as captured in 1972.

   Show morethread