Test-Driven Cameras

I am getting old.

The other day I was hanging around with my friend, Ike Ellis.  He told me a story about his kids.  His 3 young sons had been given disposable cameras as a gift.  These kids were actually confused by the idea of a camera that used film.  The first question they asked was

“Where is the picture?”
Ike explained that they had to look through the camera lens to see what the picture would look like.  They seemed ok with that, but the next question they asked was

“How do you know if you have taken a bad picture?”
Ike said “You won’t be able to know until after we get the film developed.” To which they replied,

“When will that be?” Still confused, they continued asking

“How do you delete the bad pictures?” 
 Ike said, “You can’t.”  At this point, the kids lost interest in the cameras.

However, because these cameras were gifts, the oldest decided to actually try out using the camera anyway.
The first thing he did was to take 6 pictures of the same thing.
Ike tried to explain that he shouldn’t do that, because the camera only had the ability to take a total of 32 (film) pictures.  After realizing that he could not experiment and would probably end up with a bad picture anyway, he set his camera next too the other two and walked away.

I wish people had this same reaction to the idea of writing code without first writing tests (TDD).

Tests give you the chance:

To see what you are going to write, BEFORE you write it.
To see if what you wrote actually worked.
To immediately get feedback.

To play (or experiment) with possible solutions.



If you haven’t already, here’s a great place to start learning to Test-Driven Development


If you are already writing tests, here’s a free library to make test even easier to write


Llewellyn Falco & Lynn Langit