Top all-time · #593
Brian Foote
Personal blog · laputan.orgprogrammingdesign
Brian Foote's personal blog at laputan.org covers programming and design. Since 2007, 103 different Hacker News readers have linked it 128 times, most often “Big Ball of Mud (1999)”. It has a working feed you can follow.
Sometimes recommended · 11 of 40 sampled comments recommend it?
Why HN links it
HN readers link Brian Foote's 'Big Ball of Mud' essay on how real software decays into tangled structure, and cite it on architecture, legacy code and technical debt.
- Recommended for · 11 comments
- Called essential reading, very influential and a wonderful essay; one commenter praised its pictures.
Summarised by Claude from a sample of 40 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Brian's research interests include object-oriented programming, design, reuse, languages, frameworks, software architecture, patterns, reflection, metalevel architecture, and software evolution.
Most-linked posts?
- Big Ball of Mud (1999)48 people · 52 mentions · first linked 2007-09-25
- Big Ball of Mud (1999)16 people · 22 mentions · first linked 2013-10-14
- The "Big Ball of Mud" Pattern10 people · 10 mentions · first linked 2007-04-08
- Big Ball of Mud (1999)7 people · 7 mentions · first linked 2026-01-19
- Big Ball of Mud (1999)3 people · 3 mentions · first linked 2021-02-26
- The Selfish Class (1997)2 people · 2 mentions · first linked 2015-06-15
- The Use of Subroutines in Programmes (1951) [pdf]2 people · 2 mentions · first linked 2017-06-16
- Big Ball of Mud2 people · 2 mentions · first linked 2009-10-30
- /mud/mud.html2 people · 2 mentions · first linked 2016-12-06
- Big Ball of Mud2 people · 2 mentions · first linked 2026-08-08
What Hacker News says?
> So, is pile-of-if-statements the best we can do for business software? You’ll enjoy the Big Ball of Mud paper[1]. Real world systems are prone to decay. You first of all start with a big ball of mud because you’re building a system before you know what you want. Then as parts of the system grow up, you improve the design. Then things change again and the beautiful abstraction breaks down. Production software is al…
Comment linking /mud/mud.html
on “Cognitive load is what matters”Submitted Big Ball of Mud (1999) as a story · 162 points
HN discussion> To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file Yes and that’s normal. Big ball of mud is the worlds most popular software architecture. Original: http://www.laputan.org/mud/ My modern take based on the original: https://swizec.com/blog/big-ball-of-mud-the-worlds-most-…
Comment linking /mud/
on “Plain Vanilla Web”Submitted Big Ball of Mud (1999) as a story · 122 points
HN discussion> Single-digit million lines of code (~5M, let’s say) > Somewhere between 100 and 1000 engineers working on the same codebase > The first working version of the codebase is at least ten years old > The cardinal mistake is inconsistency Funny enough, the author notes the problem on why consistency is impossible in such a project and the proceeds to call it the cardinal mistake. You cannot be consistent in a project o…
Comment linking /mud/
on “Mistakes engineers make in large established codebases”Submitted Big Ball of Mud as a story · 97 points
HN discussion"I'm at the point where I'm serioulsly debating writing something more substantial on how actual software design works" It's probably already been written; see the "Big Ball of Mud": http://www.laputan.org/mud/mud.html
Comment linking /mud/mud.html
on “Software Architecture Guide”Submitted Big Ball of Mud (1999) as a story · 90 points
HN discussionThe classic essay Big Ball of Mud is relevant as well: http://www.laputan.org/mud/mud.html
Comment linking /mud/mud.html
on “Organizing complexity is the most important skill in software development”Submitted Big Ball of Mud (1999) as a story · 73 points
HN discussionThis is how you end up with a big ball of mud [1]. If the argument is that LLMs are just as capable as humans at building big balls of mud, then I'm not sure it's much of an endorsement of their use. [1] https://www.laputan.org/mud/
Comment linking /mud/
on “The gap in shared understanding of LLM capability is widening”Submitted The Use of Subroutines in Programmes (1951) [pdf] as a story · 68 points
HN discussionThis one has been very influential to me: Big Ball of Mud Brian Foote and Joseph Yoder http://www.laputan.org/mud/
Comment linking /mud/
on “Papers every developer should read at least twice (2009)”Submitted Big Ball of Mud (1999) as a story · 52 points
HN discussion01. [On the criteria to be used in decomposing systems into modules – David Parnas]( https://prl.ccs.neu.edu/img/p-tr-1971.pdf ) 02. [A Note On Distributed Computing – Jim Waldo, Geoff Wyant, Ann Wollrath, Sam Kendall]( https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/... ) 03. [The Next 700 Programming Languages – P. J. Landin]( http://thecorememory.com/Next_700.pdf ) 04. [Can Programming Be Liberated fr…
Comment linking /pub/patterns/noble/noble.pdf
on “Papers every developer should read at least twice (2009)”Submitted The Use of Sub-Routines in Programmes (1951) [pdf] as a story · 31 points
HN discussionMaybe today, but its going to keep growing until you hear it groaning under the weight of features that have more and more risk, and generally an unknown amount because those Excel methods are getting creakier and creakier over time as you try to accomplish more with the same tools. The problem isnt Excel or any useful tool, its the misapplication of the tool and seeing people driving that same road already extremel…
Comment linking /mud/
on “Look for the duct tape”Submitted The Selfish Class (1997) as a story · 21 points
HN discussion> But if the toilet is already dirty, you’re not going to be the one cleaning other people’s pee, so you just add your own and leave. Good analogy, but in code it's more than just disgusting to clean up after others. Changing code that was poorly written by someone else may cause bugs, bugs that now become your problem. The goal of every programmer faced with such a codebase—as in the dirty bathroom analogy—is to ge…
Comment linking /mud/
on “Software Architecture Is Overrated, Clear and Simple Design Is Underrated”Submitted Reflective Facilities in Smalltalk-80 (1989) as a story · 12 points
HN discussion> Just so we are clear, you ask why Facebook didn't rewrite 10,000 human-years of code into a mythical unnamed "proper" ... You don't need to rewrite anything (at least, not all at once.) Personally, I'd have expected you to make something akin to CoffeeScript or ClojureScript that targets PHP, and can "link with" your existing PHP modules (or rather, with their HHVM bytecode representations.) Then treat the PHP cod…
Comment linking /mud/
on “Hack: a new programming language for HHVM”Submitted Big Ball of Mud as a story · 9 points
HN discussionMaybe this will help: http://laputan.org/mud/mud.html
Comment linking /mud/mud.html
on “Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?”Submitted Class Warfare: Classes vs. Prototypes as a story · 6 points
HN discussionThere is a paper on "balls of mud" that I feel is essential reading for our discipline. http://www.laputan.org/mud/
Comment linking /mud/
on “I'm not burned out, I'm pissed off”Submitted Big Ball of Mud (1999) as a story · 5 points
HN discussionThis is why I like to always write any sort of user-script batch-job tools (backfills, purges, scrapers) with a "porcelain and plumbing" approach: The first step generates a fully declarative manifest of files/uris/commands (usually just json) and the second step actually executes them. I've used a --dry-run flag to just output the manifest, but I just read some folks use a --live-run flag to enable , with dry-run b…
Comment linking /mud/mud.html
on “I Accidentally Deleted 7TB of Videos Before Going to Production”Submitted Big Ball of Mud Pattern as a story · 4 points
HN discussionI'm not OP, but there are a few I could see some mentioned in the OP's post in passing. * The common lisp condition system [3, 0] is a way better way to do errors. * Tune-able compilers [1] allow you to make better trade offs than even gcc allows for c, let alone Clojure's very opaque compiler. * CLOS [2] is a very powerful object system which clojure does not replicate (they have multi methods, and java classes, bu…
Comment linking /pub/papers/MOP.pdf
on “How to write Common Lisp in 2017 – an initiation manual”Submitted Big Ball of Mud as a story · 4 points
HN discussion
