One of the greatest lessons I had growing up was from my music teacher, on improvement: You’re either getting better or getting worse, but you’re never standing still The same applies to a software system. Any software system’s design either gets better or worse with each change made. Often times, we borrow on our technical debt for a short-term gain, knowing we’ll need to repay the debt later with some larger refactorings. This is a tactical choice made at the expense of a potentially strategic advantage. I believe that it is the natural order of software to gravitate towards a “ big ball of entropy ”. It’s why I think velocities on teams level out over time – simply because it can become more and more costly to make changes to a system. If we’re not proactive on eliminating duplication when we find it, that big ball of mud will be right around the corner. Once designs grow to a certain size, effort has to be made on the macro level to break apart concerns. Separation of concerns on the class level can only take you so far, eventually you’ll need to take separation of concerns to the system level, and implement strategies like messaging/SOA to keep systems independent, decoupled and cohesive. ...