Developers shouldn’t run around with their heads cut off but in my experience they most certainly will at some point, trying to fix bugs, if they don’t write their programs to be headless. A good way to write a headless application is to write, you probably guessed it, Unit Tests!
From personal experience, I know that if you don’t write your code to be testable, it’s extremely hard to make it so at a later date. If anything, your unit tests become more like integration tests. The same holds true, that if you write your code for one UI, business logic tends to creep into your forms, making it more difficult to support a UI on a different platform at a later date. It also makes testing through the UI mandatory, and it’s very difficult to thoroughly test code through the UI as it evolves. Using an ORM helps separate business logic from UI, but it’s not a silver bullet. I think the best approach is to use a framework like MVVM in concert with an ORM. Unit Testing IMHO is the next best solution. It’s a good way to make sure your code is headless as well as uncoupled from other dependancies and forces you to think about coding it in a more defensive manner so it will withstand the constant regression testing.
At some point, if you aren’t actively making payments, your technical debt will force you to re-write your software, and without unit tests much of the requirements for the code, and those hard won bug fixes will be lost because developers don’t write documentation (at least good docs). So while you think you’re new code may smell as fresh as a daisy, compared to the old stuff, it will essentially be a large and unproven undertaking. Unit tests are payments against technical debt, allowing you to change the software to meet evolving requirements with minimal breakage.
I recently had to update some unit tests that I wrote after another developer refactored the class under test. Apparently, despite my request that he update the tests, he failed to see the value in doing so. What I discovered was that he had introduced a bug which would have remained undiscovered for some time, had I not updated the tests. Prior to that, the unit tests for that single class had proven their value several times, having once created a new test to prevent a bug found in production, and catching breakage in previous refactoring efforts. That was on a single class! I can only imagine what life would be like if there was 80% test coverage.
If you don’t use unit testing I would encourage you to invest the time to learn how to write unit tests, and to actually do so. Don’t learn it’s value like I have - from the school of hard knocks…