2009-10-13

Six questions on TDD

Read Uncle Bob's TDD Triage:
"Is TDD a replacement for architecture?
Is TDD a replacement for design?
Should TDD be used for every line of code?
Well, if you are going to write some tests afterwards, why not write all tests afterwards?
Given that we accept the need for tests, why the resistance to test-first?
Wouldn’t it be faster without such high test coverage?"
"TDD
The Design Pattern Religion
Minimizing Concurrency"
Very good reads indeed. It is of course triggered by all the controversy of Joel Spolsky's blog on Jamie Zawinski being a Duct Tape Programmer.
Here are some of my comments:
  1. Learn concurrency principles. You'll need it. Moore's Law no longer gives you more clock cycles per second, it gives you more processor cores. To effectively utilize a modern CPU you have to keep all cores busy. And if you struggle keeping two quad-cores busy, imagine keeping 1,000 cores busy. It probably requires a fundamental programming paradigm change like the proposed fork-join framework for Java.
  2. Use high level building blocks like java.util.concurrent and java.util.concurrent.atomic. It gives you well tested code that is maintained by Other Smart People, relieving your brain to work on more important things. Two classes to study: ExecutorService and BlockingQueue.
  3. TDD is a good way of writing safe concurrency code. Design each element as a single threaded execution flow, and assert state before and after. Pay attention to locks and shared data.
  4. Architecture is Important. You don't build a skyscraper or a space station in the same way as a dog house or a residential house.
  5. Testing is a good way of exploring unknown APIs or legacy code. You basically assert the expected output or behavior of the code you are exploring.
  6. Duct Tape is good for many things. You can even build a sailboat out of it. But you probably wouldn't enlist for the Volvo Ocean Race with it?