Steve Hayes brings up a lovely quote. The opposite of a testable design is a detestable design.
Author: Robert Watkins
My name is Robert Watkins. I am a software developer and have been for over 20 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 22 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down. View all posts by Robert Watkins
Software is too expensive to build cheaply.... 
Jason Yip of Thoughtworks Sydney highlighted your blog reference.
When Martin was at the SYdney XP Activity Club (SYXPAC) Meeting (28 Feb) I took advantage of the opportunity to ask him if an architectural decision such as the use of SOA ever justified compromising the OO paradigm or the basic layering pattern. I am working on one of Microsoft’s top 100 .NET projects world wide. The architecture consists of very small and direct data pipes servicing specific parts of the UI called Winparts. It results in what Martin would describe as an “Autonomous Client”.
In the past I would have railed against the architecture for all the consequences of mixing presentation and business logic such as duplication, incomprehensibility,…. Now, being test infected, I rail against it even more vehemently because it is so unconducive to test driven development and continuous testing and refactoring. I felt so vehemently that I described it to Martin as “detestable” in more than just one sense!
Somebody else in the conversation described it as the style of architecture you would use with a lot of ex COBOL programmers. There are a lot of ex VB6 programmers here and previous VB6 applications made heavy use of complex user controls which “encapsulated” both presentation and business logic. (The use of quotes around encapsulated is to express irony, heavy irony!)
Another dire consequence that I see here as a result of a “detestable” architecture coupled to a rigorous QA testing is accelerated software entropy. Many issues are raised by testers and assigned to a range of developers who each “apply another coat of varnish” to the software module in dealing with the assigned issue. If they are lucky they will not create another problem in resolving their own. If the issue involves multiple parts of the software module more often than not they will introduce complex interdependencies. Without a suite of unit tests there is not the necessary scope to strip the software module back to its bare necessities to satisfy its functional requirements as simply as possible.
With so many coats of varnish the original item becomes completely opaque. The paradox is that the velocity of the software entropy is directly related to the diligence of the QA testing. In our case it is built in from the original release. It is another paradox that is worthy of a term such as “detestable”!
Stephen Smith
Stephen, I took the liberty of moving your comment to this entry instead; I hope you don’t mind.
Certainly, designs that are not testable make life awkward. While it is certainly true that you can build quality software without testing, it’s not easy and you never get rid of all the bugs. As you say, the QA exercise essentially becomes a tail chasing exercise.
The “detestable” term really hit a bell for me when I read it, so I posted it here. I’m glad you enjoyed it; just remember that I didn’t make it up so I’m not claiming credit. 🙂