I read this, and I am somewhat idignant:
Big Ball of Mud still seems to be the most popular way to design and architect software.
Just because something is ‘common’ doesn’t make it popular. Your standard everyday cold is pretty common, but it is not popular. Traffic jams are common, but I doubt anyone involved in them thinks that they are popular. Wading through bureaucratic red tape is common, not popular.
Primarily, BBoM happens because cost-benefit analysis is time-consuming and difficult. If programmers, architects and managers could measure and understand the longer-term cost of short-term poor decision making, we would get better decisions. Remedy? There’s no one magic bullet, but I suspect that a focus on code coverage and limited code complexity is a great place to start – I don’t know that I’ve ever seen a BBoM project with high code coverage and low complexity. This may be correlation and not causation, but I think there’s a legitimate story for how forcing unit testing discipline and simplicity pays dividends in terms of architectural strength.