I got into an argument this weekend about making code more testable. It was actually really interesting, because my defense maybe wasn't as good as I'd thought!
Here's the setup:
We were talking about some code that has an external dependency built very deeply into it. Specifically, it makes a call out to a third-party library right in the middle of a few methods. He looked at it and said, "Not a great idea, but it's working. Maybe we'll fix it eventually." I looked at it and said, "ouch! That's really not very testable. We should make changing it a bit of a priority."
And the argument:
Him: "It's working. I agree it's not ideal, but why does that mean we should change it urgently?"
Me: "It's not testable as it. I can't really exercise what happens if this third-party thing has problems or goes away."
Him: "So what?"
Me: "Umm.... err...."
I eventually was able to articulate that as unlikely as it was that this particular dependency would go away or return something unexpected, it was possible and I'd like to test for it. And he agreed that would be nice. And we agreed that... you know what? It's really not that urgent.
Nevertheless, I learned something.
Testable is not itself a goal. It's a means to an end, but if you can't articulate the end, you probably don't need the means.
And that's true of all the "able"s: testable, usable, maintainable. Unless it provides actual value to someone, you don't inherently need it. Usability is nice. Maintainability is nice. Testable is nice. None of them are in themselves overriding requirements. Rather, they are exactly as valuable as the value they provide to the consumer of the software (internal or external). Make your justification about the customer; it's much more compelling.