[Eleopteryx]

This is painful for me as a Rails dev because the real technical debt is always a lack of test coverage. Cleaning up cruft is great, except without tests I'm just going to break my application in the process (and probably not know it.) Without first defining the behavior of the application, there's a reduced incentive to refactor anything. In this way, there's effectively two layers to the technical debt.

This becomes a compounding problem, where the technical debt gets so great that it becomes more appealing to just keep pushing out features and dealing with the fallout. Everywhere I've worked, the code has ended up exactly this yucky. And yes I've contributed to it too. I just don't think that the idea of paying for someone to go back and make the code nicer with no tangible changes to the application's external behavior doesn't seem to resonate with my CTOs. Maybe I just need to find better places to work.

[stank345]

I have experienced the exact same thing in Python and it feels bad to not make changes out of fear of breaking something. So much so that I won't do refactoring on a large codebase written in a dynamic language with not great code coverage (i.e. pretty much every one I've worked on professionally).

This is where static typing can help a _lot_ in my experience. Your types (and your function signatures) are contracts you still need to adhere to after you're done refactoring. Keep making changes until the compiler tells you it's all good and then usually it is.