Many teams would be happier, more productive, and smell a whole lot better if they took his advice. -- TDD by Example

The shower is indeed the place where many difficult problems are solved. When you have a difficult problem, and it becomes and stay your top priority, your brain daemons (background processes) will work on it for you, and present a fresh solution in an unexpected moment, when you stumble on the problem in an unfamiliar environment such as the shower. When you are parking your car, or walking, or showering, these processes will leverage your free CPU.
Sometimes raising money becomes your shower top priority:

I realized recently that what one thinks about in the shower in the morning is more important than I'd thought. I knew it was a good time to have ideas. Now I'd go further: now I'd say it's hard to do a really good job on anything you don't think about in the shower. [...] Money matters are particularly likely to become the top idea in your mind. The reason is that they have to be. It's hard to get money. It's not the sort of thing that happens by default. It's not going to happen unless you let it become the thing you think about in the shower. And then you'll make little progress on anything else you'd rather be working on. -- The Top Idea in Your Mind

Test-Driven Development is an extension of Ungar's Shower Methodology. Given a red (failing) test, you'll have to make it pass:

If you know what to type, type it: always start from the Obvious Implementation if you know what it is.

If you don't know how to achieve the result, Fake It: return 0, return 4 and other hard-coded test-specific production code are ubiquitous as TDD starting points.

If you still can't generalize after faking the response, try Triangulation: write another test which feeds the system other values and expects a different response. This test, when passing, will ensure there is no hard-coding anymore.

If with triangulation you still don't know how to go on, take a Shower.

For example, given the test for extracting the square root of 2:

$this->assertEquals(1.4142..., sqrt(2));

I would code an Obvious Implementation for sqrt(), if I already know the algorithm.
If I'm unsure, I would insert return 1.4142 to get a green bar initially, and then go on writing the algorithm.
If I do not know the algorithm at all, I will insert another test for sqrt(3) to triangulate it (even more than one test if it's the case).
If now I wonder what the algorithm is and I have no idea on how to go on, I will take a shower and think about it.

Disclaimers: TDD in this version is a methodology for implementing a single feature (it doesn't cover prioritization, or estimation, or everything else). It acts as a low level of abstraction, which can become higher if you can write end-to-end and functional tests.
Note also that taking a shower may be metaphorical: you can go work on another project, or another component, or to a meeting, or google for some resource on algorithms and data structures.

Our Kanban board

After all this talking about breaks, the comparison that does not always fit is with Kanban and Work-In-Progress limits. If you have to build a car, indeed you will achieve a very short lead time if you limit the buckets of semi-finished parts: there will be less inventory to transport and store, they will be exchanged more frequently and so on...
If you have to develop software, well, it depends: if you always perfectly know what to type, you can place a WIP limit of one or two user stories and work only on one feature at the time. Scrum and every Agile methodology does exactly this with iterations; Kanban does it at a finer level by limiting the tasks that can be moved forward in each phase (analysis/development/testing/deployment/...).
If I am on a PHP web application, Usually I perfectly know what to type: no problem with WIP limits.
Yet if learning is involved, you may juggle different stories and tasks in the same time period, working for example for one day on each, rotating them. I am tackling a difficult computer vision project where I have to solve problems that range from tracking vehicles in a video to estimate their positions and understand if they will collide under certain conditions. I'm putting in it 4 hours a week: there's no way I will be able to do more due to the research and experiments involved (half of the time I do not know how to go on; and it's normal.) Multitasking is the only way to go if I do not want to lose the other 36 work week hours.
So if I had an hard WIP limit on the projects I can tackle, I would be screwed. You know what works with very large WIP limits? Universities. Normally in Italy you can have 6 courses at the same time. If you try to do one course at the time (20 hours a week for three weeks), you will shoot yourself. Formally, there are almost no limits in the engineering faculties: you can complete your studies following the order you prefer.

Thus I think WIP limits are important as they avoid attacking too many things at the same time, and never complete any. Yet if creativity is involved, shuffling projects and go taking a shower when you need it will help you more.

I went for a shower after writing a draft of this article, and I thought also about the analogy of reading books, which is an example of where Kanban is really useful (summing it up: don't buy books if you do not already read all the ones from the last order.) In the cases of user stories, car parts or books we have a set of items which is useless until it goes through all the stages: a user story is deployed, a car part is on the road, a book is ordered, unpackaged and read. You don't get value from a still wrapped book sitting on your shelf, a story you can't deploy yet or an engine not mounted on a car.
With university, it's beneficial to have related courses taken at the same time instead of serially: you can often apply in practice a concept coming from another course, or compare different approaches (mathematical one vs. physics one vs. the engineer's attitude to linearize and model everything as a Gaussian; or the operations researcher attitude towards a problem vs. the computer scientist goal to find the best data structure to solve it).
With research projects like the computer vision one, the end result is unclear and there are no subparts that can be defined earlier. That's how it works in scientific research. I often don't have user story to transport from one side to the other of the board: I have challenges to overcome with creative thinking, and creativity is not a very repeatable, optimizable process.

Note that there is always a bit of creativity in every software project: that's what makes it fun.

Monday, April 04, 2011

This is an excerpt from Test-Driven Development By Example, the book by Kent Beck which introduced a first formalized version of TDD to the world. Singleton is cited as one of the most famous design patterns, along with Null Object and Composite:

How do you provide global variables in languages without global variables? Don't. Your programs will thank you for taking the time to think about design instead.

Sunday, April 03, 2011

I still have an exam to pass after my first semester in the master's program. It is the exam of computer vision, which consists of a project - in my case, automated detection of traffic infraction.
My goal is, given a video of an urban intersection and some configuration of the scene parameters, to detect vehicles that do not respect priority. I'm more or less correctly tracking the vehicles, but the challenge now is to rectify the scene in real world coordinates (meters instead of pixels):

The project is all TDDed, and it is hosted on Github, just for backup's sake. So this is an example of what you can do at PoliMi, computer engineering's program.

Friday, April 01, 2011

Yeah, from PHP 5.4 and further you will be finally be able to access your TARDIS from PHP code:

$t = new Tardis("192.168.0.4"); // the IP address of the TARDIS
$t->configureOwner(11); // only numbers from 1 to 11 supported
// but we'll eventually get to 13

You see the innovation here? PHP is providing a new extension with an object-oriented Api instead of a bunch of tardis_*() functions which take as parameters strings, arrays, integers and resources. Indeed we have jumper into the future.
The good news is spreading all over Twitter and in PHP mailing lists, as frameworks and hosting services will never be the same thanks to the use of TARDIS (so much for the Java platform being more powerful for integrating external software.)
What are the advantages of such an Api, directly available as a core extension of PHP? Here's my take.

Translation of pages

Homepage of TARDIS-powered Google Deutsch.

You can access the telepathical hooks of the TARDIS to write your pages only one time, and then translate automatically the content by linking the device to the minds of your users.
Make sure to display an EULA, or some I Accept checkbox, before diving into this feature. However, i18n is finally solved!
Disclaimer: as you can see in the example on the right, it does not work with images for now. It seems that translation of image-contained text is covered by a patent that Gallifreyans couldn't obtain.

Dimensional trascendence
As you know, TARDIS interior is in a different dimension from the exterior appearance. This space is suitable for server clusters and other technology: for example by moving your TARDIS to your server room, you will have an enormous capacity for scaling as it can contain an huge amount of racks.
You may have to install some additional cooling mechanism, however.

Chameleon Circuit

My home servers

You can rent rack space from other companies, but how can you make sure they not fiddle with your servers? You can simply link them to the chameleon circuit of the TARDIS. Their appearance will merge with the background, and no one will be able to find them without your permission.
But that's not all: you can also link newly spawned virtual machines to it via the PHP Api, so that they effectively disapper in the cloud and remain unreachable from attackers!

Teleportation
You can now physically access your production servers in case something is wrong and teleport them to the colocation site for production.
When this PHP script is executed (it can be chained to the failure of tests or to repeated failures of the db connection, or to the detection that someone wants to access your private customer data), the servers linked to the TARDIS are teleported back:

$tardis = new Tardis(...);
$tardis->query('SELECT * FROM servers
WHERE failed IS NOT NULL')
->fetchAll()
->teleport('22031', 'Italy');

My conclusions
PHP is going to be revolutionized and empowered by the TARDIS integration. You'd better hurry up and join a startup based on this new technology - visit the project page for more information on TARDIS-enabled PHP.