I've heard the argument that your user doesn't care about your test suite, or how easy it was for you to write something. While I think there's merit in such an argument, the black-and-white perspective of it simply makes it untrue. There's an implication that we should consider ourselves lucky when we get to do things like test drive, pair program, use good tools, and make good architecture. It's like we as engineers are compulsively driven to want to put things in nice and neat little boxes for organization's sake. When we can't do that or something disrupts the organization, we throw a tantrum because we're simply children. While I believe there are certainly cases where this applies, it's blatantly incorrect to paint all of us under such a stroke.
The thing is we get frustrated and angry at our cools, codebase,
A software shop should fight tooth and nail to stay on top of the curb. Does that mean we have to go back and rewrite? You betcha. But if our technical debt is reduced, if the engineers are able to get closer to the features or pull out 3rd party modules to assist in development, then isn't that a big win? Avoiding rewrites is a lost cause. How many banks are glad they are still running on COBOL today? Sure it was probably great at the time, but that time has passed. Everything we use now will eventually become archaic and dated. We may as well embrace the idea that code is a living document that needs small and big adjustments both over time. Does that mean we should jump on every shiny new framework the moment it comes out without evaluation? Of course not, but this entire "suck it up and get back to typing" attitude needs to go. Your user might not care if you're using punch cards to enter your code, but they certainly are going to feel impact of such a choice.
Something to consider.