Case closed

Many heated arguments about Test-Driven Development have certain recurring reasoning on both sides. In general, developers have a hard time accepting that they need to think differently about implementation and design and/or have to alter exisitng design in order to be able to write tests. "I would need to introduce this indirection only for testing" or "There is no need for this kind of hierarchy to implement the features in the production system", and their alikes are common critiques of TDD.
Inexperienced TDD people almost invariably try to tackle these with answers like "But your design will be better this way" or "Modularity is your friend" or "Indirection is a way to build flexibilty into your code".

Obviously all of these are correct and nothing new. SOLID for example is a well-known and universal set of principles supporting the answers above. However most of the defenders of TDD are missing the point.
The point is this:
Once we've agreed that unit testing is a very efficient way to create quality software and we want to do it, there is no room for further discussion. You just have to think about the testability of your code as any other requirement you have to implement. Don't worry, you will get all the earlier mentioned: flexibility, maintainability, comprehensibility, and so on. But that shouldn't have influence on this praticular matter, because you are required to write testable code anyway. There is really nothing else to it.
Once you can get your head around this, your life as an agile programmer will be much, much easier. Mine already is.

Read full post...

Traps Pt.1.: Rope-A-Dope

Many times in software development you have a simple problem, which has an easy solution. Or so it seems. You start solving the problem, but it turns out first you have to solve a different problem. Not a difficult one either, so you start working on it, but it's not long before you realise that before you could solve the second one you have to start with a third, all new problem. Again, not a very complicated one. Before you know it it's six o'clock in the evening, and you'd forgot all about the original problem, let alone solving it. Let's call it the Rope-A-Dope Trap. It's difficult exactly becuse it seems easy all the way. Every time just one small step away. There was just no point where you could have said no.
A possible escape from this trap is applying the Rule Of Three(or Two).

There are always obsticles creeping in when solving software problems, it's inevitable. But whenever you find yourself face to face with the third "creeper" in a row, you need to abort what you're doing, take a step back, a deep breath and a very good look at your original problem in light of the three unforseen ones. Rethink, regroup and start over. Starting over could mean a different approach, design, tool or even different requirements.
So watch out next time for a Rope-A-Dope. And don't forget that it could occur on many levels too. A method, a feature or a whole solution.

Read full post...