The fiercest enemy of software is mud. Ouch and what’s mud? It’s a kind of sticky matter and results from the mixing of earth and water. The effect of mud is making every step and most actions hard to accomplish. It makes you slip; it, in a way, stops from progressing.
The association between mud and software is an old one and dates back to 1999, when Brian Foote and Joseph Yoder published this paper. Mud stops software from progressing towards its natural end–a successful application possibly built on time and budget. What’s the mud effect on software? What are the earth and water that mixed together stop progress of software? In the paper, Foote & Yoder call a big ball of mud (BBM) the following:
A system that’s largely unstructured, padded with hidden dependencies between parts, with a lot of data and code duplication and an unclear identification of layers and concerns—a spaghetti code jungle.
A BBM is then a software near its unnatural end, starving, about to die. A few key facts can be listed about BBMs:
- BBM doesn’t get formed overnight and grows over time;
- BBM isn’t that big in the beginning and sometimes it doesn’t get noted timely;
- No individual developer is so skilled and powerful to create a BBM all by himself: it’s always teamwork;
- Communication issues between development and business which creates a mismatch between expressed requirements and actual features coded.
- Precision of estimates—doesn’t exist! Uncertainty reigns and trust between parties is required to make progress.
- Requirements churn. An high frequency of change of requirements make the system change context eventually evolving into something that may have required a different architecture.
- Role of management. That crazy little thing called “being a team player …” may hide a lot of painful points.