Author: Brandon Pearman

The views expressed here are mine alone and do not reflect the view of my employer.

Definition: When code is difficult to modify because dependent modules would need changes too.

Impact: This huge amount of required changes in multiple places may even be unknown to some degree making it difficult to estimate the change. Due to the difficulty of making simple changes and/or estimating them, the code may be left alone and not touched unless absolutely required.

Definition: When code gets modified then other areas break.

Impact: When unrelated areas of code break from a modification, they can easily be missed by the developer. When a company sees errors in unrelated areas when they ask for a "simple change" they lose confidence and trust in you as a developer. Even if you sell them on the idea of it not being your fault because it's highly coupled legacy code, they still dont trust you to touch that legacy code. Imagine taking your car in for an oil leak, which they fix beautifully but then you notice your aircon and brakes dont work anymore.

Definition:When the code is hard to reuse.

Impact:If the code is so tangled that it can't be reused then code gets duplicated, forcing the developers to maintain it in multiple places.

Definition: If it is difficult to preserve the current system design the developer will have to "hack" a new implementation. A high viscosity system is one where it is difficult to follow the design of the system.

Impact: Hack after hack will eventually cause the design to look like a frankenstein, where it becomes difficult to read or maintain.

High coupling is a big factor to poor code. Making sure that you implement the SOLID principles correctly is a good start. The big problem comes in when you have this massive code base which is written poorly. At this point there are two good options. The first option is REWRITE! The second option is REFACTOR! The third option is "dont touch it" but that may not always be a viable option since you are hired to add and change code. If there are pains around modifying this code you should do it more, right? because thats what Martin Fowler said.

"If it hurts, do it more often."

-Martin Fowler

Well not exactly. Banging your head against the wall hurts but that does not mean the solution is "do it more often". I think that Martin Fowler implies the obvious here. That if doing the right thing hurts, do it more often. In this case the right thing is good design principles. So do the right thing more often by refactoring more often, using SOLID principles and the learnings you have acquired from what made it poor in the first place.

Check out these links for more info:

My design and architecture repo