The Agile Pyramid

(The story is not mine, but this is the best analogy I've known for Agile.)

There were two pyramid contractors in Egypt (guys who built pyramids for a living that is) and they are both hired by a really old pharaoh for building one for him. His requirements were.

1) It should be the biggest possible pyramid that can be built

2)It should be ready when he is dead.

Contractor A: Decides to build the largest pyramid ever. Bigger than the biggest. He estimates that this would take him a year with the laborers that are available to him.

Contractor B: Has a good long look at the pharaoh, and realizes that the pharaoh may not last that long, maybe a month or two. He decides on an interesting approach. He decides to build that largest possible pyramid that he can build in one month. The next month, he’ll build an even bigger one on top of that, the month after, an even bigger one.

The pharaoh died in 3 months.

The obvious and not so obvious benefits of Test Driven Development

The basic principle of Test Driven Development is simple. You write your test code before you write your implementation code. Counter intuitive when you first hear it, but after you start doing it, you ask yourself why you haven't done it all these years (well, aren't most great ideas like that?)

The benefits are obvious and also not so obvious.

1. Big picture thinking. As you write your test case, you start thinking more about how your application is supposed to behave. You start catching gaps in the specification well ahead of implementation and integration.

2. Test coverage happens automatically, since unit testing is no more an afterthought - test code is the fist thing you write. By the time you are done with your application, you are left with a test suite that covers every line of code that your wrote.

3. Effective multi-tasking. Most important but not so obvious, TDD helps the developer focus on one thing at a time and there-by multitask effectively. Good multi-taskers possess a knack for dividing their time among multiple tasks throughout the day, while giving their undivided attention to each single task when they are at it. The challenge, where most people fail is in dividing tasks into small enough and un-ambiguos units, with un-ambigous results. TDD, I've found helps a great deal in this. Each test case defines an unambiguous unit of work, with an unambiguous result - the test either passes or fails.

4. Context switching. Another not so obvious benefit - even if you are distracted during your work by something urgent and you pick it back up hours or even days later, you know exactly where you left it by simply running your test suite and checking which test case is failing.

For a detailed reading on the subject>> http://jamesshore.com/Agile-Book/test_driven_development.html