Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Ball-of-Mud Transition, or how software gets complex

akvo.org

Post reply on HN
Print view View original

31–35 of 35 posts

Re: The Ball-of-Mud Transition, or how software gets complex

#31

Post by greenyoda »

I'm not sure that randomly connecting nodes is a good model for how software complexity arises, since connections between software components are not made at random. When was the last time you threw some dice to decide whether some piece of your user interface would be connected to business logic or directly to your database server? There's usually a (non-random) reason for why we add a piece of code, and the reason why complexity gets out of hand is that we don't, for various reasons, refactor our architectures to eliminate accumulated complexity before it's too late (and then nobody can understand it anymore, and you end up with the ball of mud).

It's also interesting to note that Foote and Yoder's "Big Ball of Mud" paper[1] portrayed the mechanisms for mud-ball formation as a set of anti-patterns. It's an interesting read. Their give some pretty thoughtful explanations for how software transmogrifies into a mud-ball, none of which include random processes.

[1] http://laputan.org/mud (1999)

Re: The Ball-of-Mud Transition, or how software gets complex

#32

Post by mtwestra »

LukeShu wrote: post #20

This isn't about what he is saying, but how he is saying it: This bit bothered me: " Wikipedia does a great job of explaining it: " then has a quote from an actual source, that happens to be block-quoted on the Wikipedia page. If the part you quote was directly said by Brian Foote and Joseph Yoder, attribute it to them.

You're right, it had escaped my attention. I have quoted them directly in the blog now. Thanks!

Re: The Ball-of-Mud Transition, or how software gets complex

#33

Post by selimthegrim »

gavinpc wrote: post #27
ColinWright wrote: post #19

Picking up on adrianN's comment[0], when you have a collection of nodes and start connecting them at random, initially they are all disconnected (obviously) and any two that you pick are likely not to have any edges. This in the early stages, your graph is isolated nodes and isolated edges. After a while, by chance, you happen to join an existing edge to a node. That component now has three vertices, and is 50% more…

This is very close to the "percolation problem." [0] According to Robert Sedgewick, this particular problem has no known mathematical solution , and the threshold (for a given N) is only obtained through, e.g. a Monte Carlo simulations where you randomly open sites until the grid percolates (akin to the adding of threads). The whole thing is a good application of the union find algorithm. The threshhold for N > 2 is…

For general graphs, the situation is indeed poor. For lattices, much more is understood, cf. http://en.wikipedia.org/wiki/Stanislav_Smirnov

Re: The Ball-of-Mud Transition, or how software gets complex

#34

Post by mathattack »

PaulHoule wrote: post #8
mathattack wrote: post #2

So the story is software gets ugly when it gets less modular? This is a truism, no?

In real life I've seen many projects go wrong because people modularized it in the wrong way -- often connected with a naïve faith in "encapsulation" (Complex bugs, performance problems, and crackers don't respect encapsulation.) For instance, SOA has had a new lease on life lately, for good reasons. I picked up a system that had four layers involved with doing a request; each of these layers had different serializat…

Thank you for the detailed commentary. Fighting for simplicity is rough because the virtue doesn't always have a champion, while every new complexity increasing function has one. At my last firm, every feature had management committee sponsorship. Simplicity? A dirty word.

So I see your point. Thanks for elucidating.

Re: The Ball-of-Mud Transition, or how software gets complex

#35

Post by joe_the_user »

gavinpc wrote: post #27
ColinWright wrote: post #19

Picking up on adrianN's comment[0], when you have a collection of nodes and start connecting them at random, initially they are all disconnected (obviously) and any two that you pick are likely not to have any edges. This in the early stages, your graph is isolated nodes and isolated edges. After a while, by chance, you happen to join an existing edge to a node. That component now has three vertices, and is 50% more…

This is very close to the "percolation problem." [0] According to Robert Sedgewick, this particular problem has no known mathematical solution , and the threshold (for a given N) is only obtained through, e.g. a Monte Carlo simulations where you randomly open sites until the grid percolates (akin to the adding of threads). The whole thing is a good application of the union find algorithm. The threshhold for N > 2 is…

You mean one particular percolation problem, I assume.

Just to clarify because one might interpret your statement to mean that percolation problems in general don't have exact formulas for their solution but the "exact formula" section in your link would say otherwise.

Post reply on HN