Big Ball of Entropy?

Just a quick thought, the comments should be interesting on this one.

 

 

What is the relationship between the Big Ball of Mud and Entropy?

Are all systems of a reasonable level of complexity destined to become Big Balls of Mud?

Do the economics of our industry drive things towards a Big Balls of Mud?

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

16 Responses to Big Ball of Entropy?

  1. Carl Wayne Hardeman says:

    Plumbers have the integrity to turn down a project which is close to impossible to do. Programmers will keep trying.

  2. Adam D. says:

    @Phil .. then (as Greg puts it), you have man sized holes in your safety net….

  3. Steve Py says:

    Economics & general attitude of the development team.

    The initial development team starts out with the best intentions, and the best “current” skills, knowledge, and technology they have in their posession at the time. (VB6, C++, ASP, ASP.Net 1.1)

    After the product is released to the world and starts going through the “fermenting” stages (bug fixes, enhancements, customizations) the ball of mud is forming.

    What’s left of the original development team starts beating drums for a new version of the product using the “now” modern technologies (C#, ASP.Net 3.5, etc.) while greenhorns are left to maintain the old beast. Management wants to squeeze every penny out of the existing product so that means more enhancements and customizations to “just get sales” ot provide cash flow or prop up investment into a new and improved version.

    “Veteran” developers would never willingly remain on the “legacy” project. They want, they’ve “earned” greenfield status. If they don’t get the green field, they move on.

    This is one reason I like graduate developers. Their minds are like sponges and most of them have a passion to be responsible for building something. They know the whole of the system is bigger than they can accomplish alone, and provided that they are mentored in best practices (School is little-to-no help there) they make for some excellent development tallent. Unfortunately, all too soon they become “experienced” developers. They lose the shine off their passion for development, becoming bigots or hypocrites that believe they could build it better, faster, stronger if it were up to them; but the software is the way it is because of someone else.

  4. Phil Booth says:

    @Adam D: I guess I’m just lucky then. Seriously, I’m living in a world where the unit tests on my projects have stayed very, um, unit-ish (or whatever the word I want is). That is the whole point of setUp() and tearDown() after all…

  5. Adam D says:

    You will always get BBoM because the complexity will migrate to the unit tests. Unless you do some DbC stuff like Spec# with which you can trim the test suite to a managable size.

  6. Phil Booth says:

    @Craig: Do you? I’ve not experienced that myself…

  7. Addy Santo says:

    One interesting aspect which I think many people miss out on is that the bar for agility, maintainability etc is not fixed – it rises as software development practices evolve. One reason that legacy systems always seem to be “muddier” than modern systems is that their basic architecture and design is outdated, and that even if their entropy has not increased since day 1 (ie the code works perfectly and hasn’t been touched), they would still be considered BBOMs by today’s standards. In the same vein, I suspect that anything written today using our current tools and development practices would be considered pretty lame in another 5-10 years even without entropy effects.

  8. Robert Reppel says:

    BBoM comes from ignorance => greed / fear / delusion: “WE HAVEN’T A CLUE about the design of that system, but we REALLY WANT TO HAVE that new feature / fix ASAP and the way everything will hit the fan if we don’t meet the deadline FREAKS US OUT. We WILL HAVE A CHANCE TO DEAL WITH THE RESULTING MESS LATER.

  9. Craig says:

    But then you move your BBOM to the unit tests…

  10. Jeff Certain says:

    @Peter,

    Well stated. If there is no oversight over the implementation, the architecture will devolve to BBoM. If the architecture/design is evolved over time with architectural oversight, BBoM shouldn’t occur.

    Seems that developers working around architectural problems accelerates BBoM, while evolving the architectural will defer it.

  11. Phil Booth says:

    I would say undoubtedly yes, the second law of thermodynamics applies to software development. The Big Ball of Mud is chaos rendered as source code. As competent programmers, however, we are fortunate to have weapons of mass neguentropy in our arsenal. I refer, of course, to refactoring (heavily supported by TDD and unit tests).

  12. Greg says:

    Update in post.

  13. Jake Kim says:

    1. BBoM is the state of the environment and Entropy is the measure of the state.

    2. Yes.

  14. Big Ball of Mud is the result of not managing Entropy.

  15. Ollie Jones says:

    Everything decays over time :)

  16. Jimmy Bogard says:

    I’d say the natural entropy of a software system is to go towards BBoM. That is, systems that get changed frequently. It takes effort in reducing complexity, eliminating duplication and improving design. If effort is not taken to do so, BBoM is the result.

    I wouldn’t say that reasonable complexity leads towards BBoM, but rather unless a system is broken up, you can no longer increase the rate of change, as you will be spending resources keeping the system from turning into a BBoM.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>