The Ball-of-Mud Transition, or how software gets complex
1–10 of 35 posts
Re: The Ball-of-Mud Transition, or how software gets complex
#2So the story is software gets ugly when it gets less modular? This is a truism, no?
Re: The Ball-of-Mud Transition, or how software gets complex
#3So the story is software gets ugly when it gets less modular? This is a truism, no?
Almost; the core insight is the non-linearity of this truism.
Re: The Ball-of-Mud Transition, or how software gets complex
#4So the story is software gets ugly when it gets less modular? This is a truism, no?
Almost; the core insight is the non-linearity of this truism.
Adding to that, there's also somth in the article about "modularity" not being the default when it comes to "nature".
> In nature, complexity is where the good things, such as life, happen.
Re: The Ball-of-Mud Transition, or how software gets complex
#5The attribution to (through) Wikipedia describes the term as being coined in 1997, but the original authors of that paper expanded there ideas in 1999. I reread this paper every couple of years just to make sure I'm not "guilty".
Re: The Ball-of-Mud Transition, or how software gets complex
#6So the story is software gets ugly when it gets less modular? This is a truism, no?
Like Dexen says, the surprise is in the non-linearity. The sudden transition from a sparsely connected to a widely connected system comes somewhat unexpected (at least to me :-) ).
Re: The Ball-of-Mud Transition, or how software gets complex
#7Earlier quoted context omitted.
Almost; the core insight is the non-linearity of this truism.
Adding to that, there's also somth in the article about "modularity" not being the default when it comes to "nature". > In nature, complexity is where the good things, such as life, happen.
> somth
Re: The Ball-of-Mud Transition, or how software gets complex
#8So 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 serialization/deserialization logic (two submodules) and at least one submodule that would actually do the work.
Debugging a problem in the system often involved a wild goose chase across 12 submodules and often changing something simple (like adding a new data field) would require all 12 modules to be changed.
Even if you have a good batting average and you manage to make these changes right 90% of the time it's close to certain that making a change to that system would create a new bug.
The underlying social problem isn't that "people want to do things quickly", it's that people don't see simplicity as a virtue and don't see complexity as a problem. If they valued speed, they'd pursue simplicity because you can make changes much more quickly in a simple system.
Re: The Ball-of-Mud Transition, or how software gets complex
#9This sounds like "Broken Windows Syndrome".
Once a system gets to the point where more than (somewhere between 30-50%) is connected together, developers stop caring about keeping it modular, because it's clear to them that their efforts are a waste of energy.
From that point onwards, the project becomes a cesspool of hackery.
Re: The Ball-of-Mud Transition, or how software gets complex
#10So 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…
> you can make changes much more quickly in a simple system.
IME: Doing N features hackishly takes O(n^2) time; Doing them properly takes O(2n). The problem is when management sees a project as a series of several n=1 tasks, instead of one n=n project.