Is Your Code a Big Ball of Mud?

July 24, 2013

Allow me, for a moment, a hypothetical: you have invited a contractor into your home to build an addition. With the estimate comes an observation that your foundation is developing an issue. Perhaps it has broken down over time, or maybe it just wasn’t built right from the start. However, you’ve lived in this house for years without a problem, so now you must decide whether to take the contractor’s word. 

Contractors, after all, are in the business of selling construction, and foundation work is some of the most expensive. It’s not much of a stretch to assume they’re making the problem out to be more than it is. Then again, if there really is a problem, your house could fall down. 

You have three options:

  1. Find another contractor. If you truly believe they’re being disingenuous this is the proper course of action. You don’t want work done by an untrustworthy individual.
  2. Take the contractor’s advice. This is the right thing to do if you trust them. You put off the addition until the repairs are complete because you understand that a solid house is built on a solid foundation.
  3. Ignore the contractor’s advice but complete the addition. You have the contractor do the work you see as valuable and ignore what is out of sight. 

Beware making the third choice—if you trust these contractors to build new construction, why don’t you trust their analysis of your existing infrastructure? 

You are willingly taking on unnecessary risk, and opening your entire infrastructure to even greater future risk. A few things to consider:

  • Foundation repairs are always cheaper the earlier you take them on—the problem is bound to get worse or suddenly fail 
  • Your new addition may end up not being sound due to reliance on a compromised foundation

Unfortunately, when considering new functionality, organizations make this third choice much too frequently. Perhaps you’re saying to yourself right now - “I would never make that choice, that’s shortsighted.” Excellent, we’d love to work with you

I spend a significant amount of time reviewing legacy code to assess its quality, and almost invariably it’s an untested “big ball of mud.” This concept refers to an organization’s haphazard conglomeration of miscellaneous code, resembling a ‘mud ball.’ As you can imagine, it’s hard to build a very nice house on mud, let alone sound data architecture.

When assessing the scope and resources needed for any project, we always test our client’s legacy code (foundation) for stability. This helps identify the areas of biggest risk when considering new additions. Underlying structural issues should be addressed before adding any code. 

Find contractors you know to produce good work. Talk to your friends and read reviews. Don’t just pick the cheapest option or you’ll end up paying someone else to fix the substandard work. Once you’ve chosen someone you know you can trust, follow their advice but do not hesitate to challenge it. The best contractors care about your home (codebase) and want to do quality work.

 

Questions or ideas? Leave a comment below or connect with me on Twitter at @couchand.

 

See More