Live data from Hacker News

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

akvo.org

11–20 of 35 posts

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

#11
There is a long but good read that goes into this topic here http://blogs.msdn.com/b/karchworld_identity/archive/2011/04/...

It's about the full lifecycle of a typical software product. Particularly "Section 2.3.1: Loss of Architectural Integrity"

> code decay can be thought of as any implementation of functionality that makes the overall comprehension of the system more difficult to attain and increases the efforts required to implement future changes.

.. and makes further decay more likely

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

#14
What he doesn't emphasize is the directionality of this phase transition. It's really easy to add one more string, but staring at the resulting button-thread agglomeration it's very difficult to know what string to cut. This is why there is a never ending stream of new projects started to solve the same problems over and over. Their authors covet the opportunity to make progress during the honeymoon period, before the Sisyphean battle against software entropy sets in.

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

#15
From my experience code is either 'done properly' or 'shoehorned in'. But really, 'done properly' means 'you have time to organize everything satisfactorily at a high level', typically only when you are writing a new module from scratch.

Everything else is trying to shoehorn something new into an existing framework, and you don't have enough time to get it 'done properly' because your product manager has a heart attack when you tell them how long it'll take to do a proper refactoring job. This is where you will quite happily cut corners, and the chance that you'll inadvertently break existing functionality in the process increases exponentially. This is the mechanism that, in my experience, causes balls-of-mud.

And of course, no matter how good you are at planning every required use-case of your code over its lifetime at the 'done properly' stage, you can never think of it all, so at some point or another you are forced to shoehorn stuff in everywhere anyway.

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

#16
post #12

What he studied experimentally with the buttons and threads is know in graph theory as the "Giant component" threshold and is exactly known. https://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93R%C3%A9nyi_...

That's true, but I'm unaware of much work being done on the error bounds for small N (for some concept of small). I started on this during my PhD, but rapidly moved onto other problems that seemed more tractable, and never really returned to it. The results of Bollobás, Erdős, Rényi, and others, are mostly asymptotic. They do, however, seem remarkably good even on graphs of small size (under 10^6 vertices).

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

#17
post #12

What he studied experimentally with the buttons and threads is know in graph theory as the "Giant component" threshold and is exactly known. https://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93R%C3%A9nyi_...

That's very interesting adrianN, thanks!

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

#18
post #14

What he doesn't emphasize is the directionality of this phase transition. It's really easy to add one more string, but staring at the resulting button-thread agglomeration it's very difficult to know what string to cut. This is why there is a never ending stream of new projects started to solve the same problems over and over. Their authors covet the opportunity to make progress during the honeymoon period, before th…

I agree completely - once you're on the wrong side of the transition, it is hard to go back

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

#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 likely to be chosen at random than the isolated edges.

There comes a point where you join two non-trivial components, and before long you reach a tipping point. Suddenly nearly every node you choose already belongs to a component, and that component starts vacuuming up everything.

Thus we have the emergence of "The Giant Component". This transition is sharp and well-studied. Whether you think of it as "obvious" depends on how much you study these things. I seem to recall that there is a major result that says that all first-order predicates have these threshold emergence properties, but it's been too long (30 years) since I studied this, and I could be wrong. I may be able to find some references if people really want me to.

[0] https://news.ycombinator.com/item?id=6546978

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

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

Post reply on HN