Software and Mud

There seems to be a strange relationship between software and mud. Many will be familiar with the Big Ball of Mud architectural style and there are countless examples of code that resembles mud more than anything else.

A while ago a colleague of mine used an analogy between a software related problem he was facing and wading through mud (or as we say in Dutch: "door de moose ploegen"). I'm amazed at how poignant this analogy actually is. Think of a situation where the first thing you notice is that you have mud on the soles of your shoes. As you trot on you quickly end up knee deep in mud. At this point you can either back out and retreat to solid ground, or persevere, in which case you often end up stuck!

Of course you might also make it through, as John Carmack once noted:

Yes, you can make windows do anything you want to if you have enough time to beat on it, but you can come out of it feeling like you just walked through a sewer. [.plan]

Many software related situations come to mind that closely follow this story:

• Merging exercises gone wrong
• Refactoring plans that start simple but spiral out of control
• Anything to do with character encoding
• ...

Feel free to add this mud analogy to your software vocabulary!

(As an aside: some people can wade through mud more elegantly than others, as Kate Moss illustrates.)