IMO it stems from the fact that managers up the ladder don't understand or have never been told that software that produces the expected results isn't necessarily finished work. There is a reason most of us have this gut feeling, this strive for elegance. We can only be at rest when we feel we master the creature we have built, and can live up to our clients expectation of maintaining it and making it evolve. Managers see it under a different light. TDD was made for them, for they are those who buy it. At the end, cut the costs as much as possible. The system (still) gives the expected results ? Alright, job done. There is no consideration for the hell of a ball of mud that often drives the whole thing behind the curtain. Yet, at the end they are those who pay for hiring the wrong persons or following the wrong cult. This is how you get overbudget or fail a project. TDD ? Separation of concerns ? Why not, but the same goal of working and flexible code can be met by developing and encouraging good craft in a team. Not by luring people in adhering to practices that constrain them to do a bad job unbeknownst to them. Testing and structure stem from good craft, not the other way around.