Once upon a time, a far country where two little pigs lived, Peter and Andrew, who were brothers. They both were the most intelligent pigs in the farm and, because of that, the rooster Irvin (the manager of the farm) organized a meeting in the barn, where he ordered them to develop a computer program to control the stock of feeds. He explained them that he wanted to know in every moment: how many bags of grain were and who got in and out grain them in the stock. For doing that, they had only one month but he warned them that in one week he wanted to see something working. At the end of this week, one of them would be eliminated.
Andrew, younger and more impulsive, immediatly put his hands on job. “There is no time to waste!”, he said. So he started lines and lines of code very fast. Some of the lines belonged to a program he recently helped to write for the daycare center of the cow Rose . Andrew thought that a grain stock and a daycare center weren’t so different. In the first one, bags of grain were saved and in the second, little animals. All right, he only had to make up a few little things but come on, software is mainly reusing what it’s already working, isn’t it?
Peter, however, before writing any single line of code started arranging with Irvin a couple of things: what was exactly what he could see in one week how he could know when each thing was really finished.
Irvin wanted to know, as fast as possible, how many grain bags were in each section of the stock because he suspected that in some sections there were bags accumulating without control and they were becoming bad. Since the bags went in and out constantly, he couldn’t know how many of them were and where they were in every moment, so they agreed to count them by sections and annotating to which sections they were going to and from where they were coming from each time a bag was going in or out. So, in a shot time they could have a clear idea of the use of the different zones of the stock.
While Andrew was taking advantage over Peter, writing a lot of lines of code, Peter was writing the automated tests first. For Andrew, it was a wasting of time: ¡he only had a week to convince Irvin!
At the end of the first week, Andrew’s demo was espectacular, it was a very complete users control, he made the presentation even from a smartphone and even showed the possibilities of a very powerful report generator that he previously developed for another farm. During the demonstration there were two or three little problems and he had to restart the program but, apart of that, everything was great.
Peter’s demonstration was much more modest, but accomplished all the Irvin’s expectations and the program didn’t fail in any moment. Of course, everything he showed was tested a lot of times before thanks he automated the tests. Peter made TDD, it means, he never wrote one single line of code without having a test that indicated any possible error. Andrew couldn’t believe that Peter wasted more than half of his time in that tests, that only delayed him in writing the functionalities that Irvin’s asked. Andrew’s program had a lot of buttons and a lot of options, probably more than necessary for Irvin purposes, but it had a “very professional” looking.
Irvin didn’t know what to do. Peter’s solution was very robust and it did just what he wanted. Andrew’s solution had few thins to improve, but it was very promising, come on, he made the demonstration from a mobile phone!
So, Irvin purposed them the following: “I will pay you 50% more than agreed in the beginning, but only for the one of you who makes the best project, for the other, I won’t pay nothing.”. It was a complicated offer, in one hand, the winner would earn much more than predicted. Very tentative. But, in the other hand, they could take the risk of working during a month completely for free. Hhhmmmm…
Andrew, as impulsive and arrogant as ever, didn’t hesitate for a moment. “It’s a deal!”, he said. Peter explained that he would accept only if Irvin got the commitment of collaborating as he did the first week. For Irvin it was reasonable and dated them to show him the final result in three weeks.
Andrew went out very fast and immediately called his cousin Seifer, who knew a lot and would ensured him the victory, although he had to give him part of the benefits. Both started to work immediately. While Andrew fixed the little bugs found during the demo, Seifer started to design an architecture that allowed to send messages form the mobile phone to a webservice that allowed to enqueue any operation to be processed in parallel by several servers and guarantee the system to be available 24 hours per day 7 days per week.
Meanwhile, Peter met with Irvin and Bernard (the stock manager) to see which could be the following functionalities to develop. He asked them to explain him, for every request, what profit would the farm get with every new functionality. And like this, step by step, they made list of prioritized functionalities and summarized in a set of cards. After that, Pater discussed every single card with Irvin and Bernard to find out how much time the corresponding functionalities would take to be finished. He also took notes about some criteria that later would be useful for consider that each functionality would be completely finished and in this way remove any emerging ambiguity. Peter realized, because of his experience, that he couldn’t do more job than the already discussed, so, he finished the meeting and started to work. First of all, he fixed a pair of bugs discovered during the demonstration and asked to Irvin to validate them. After that, he went home to rest.
The following day, Peter took the first of the cards and, like he did during the last week, he started to automate the acceptance criteria agreed with Irvin and Bernard and later, he wrote the part of the program responsible to accomplish this criteria.
Peter asked help to his friend Hudson, a vegetarian coyote who came from America to spend the winter in this country. Hudson didn’t know how to write programs, but he was very fast making simple things. Peter asked him to check constantly the acceptance criteria that he automated before. So, each time Peter made some change in his program, he called Hudson and he made, one after another, every acceptance tests that Peter wrote before. And every time there were more, this Hudson was really fast and tireless!
As time was passing, Andrew and Seifer had more and more problems. Finally he started to blame everybody. They blamed Irvin, because he didn’t explain them the very important details for the success of the project. He blamed also the cow Rose, because she included a set of changes in the daycare center program and the impact of these changes was that they couldn’t reuse almost nothing. They blamed as well the SMS and webservices inventors, because they didn’t know how a farm worked. They had so many work lines opened that they had to give up with SMS and they searched for a webpages generator that allowed them to draw the navigation flow in a graph and, from that point, generate the skeleton of the application. This would save a lot of time for sure! Very soon, Seifer, fed up of seeing that Andrew didn’t appreciate his help and knowing that his SMS idea wouldn’t be in the project, decided to abandon it, even refusing his part of the benefits, he really thought that they weren’t going to win the competition.
At the same time, Peter asked a couple of times Irvin and Bernard to validate if the work done up to this moment was good for them and he showed them a few demonstrations during these three weeks, what was very useful to fix some bugs and change some priorities. Irvin and Bernard were really happy with Peter’s work. However, they talked more than one time: “What is doing Andrew now? How is it going for him?”.
When the final date for present the program approached, Andrew didn’t sleep a pair of nights for finishing the program in time. But there were so many accumulated defects that every time he fixed one thing, another one failed. In fact, when the demonstration time came, Andrew only could show the program installed in his laptor (the only place where it barely worked) and everything was a disaster: error messages everywhere, unexpected behaviors… and the worst thing: the program didn’t make what Irvin wanted.
Peter, however, didn’t have any problem to show what was working long time ago and already tested a lot of times. Just in case, two days before the demo, Peter stopped adding new features to the program because he wanted to focus in giving a good user manual, which Irvin completely forgot to mention in the first meetings because already thought it would be included with the program. Of course, Andrew didn’t have time for that.
Apart of a set of good practices and an agile development process, Peter made something that Andrew despised: agreed with Irvin (the client) and Bernard (the user) the criteria to check whether every functionality would be correctly finished. We use to call it “acceptance criteria”, Petar added the possibility of automating their execution and incorporating them in a process of continuous integration (what is represented here through his friend Hudson). In this way, Peter was always sure that he wasn’t messing nothing old with a new modification. To avoid working again on already finished stuff, Peter was more efficient. In a shot time, the differences between both points of views may be not significative, but in medium and long time terms, it’s obvious that writing tests before developing the solution is much more efficient.
This is my translation to English of the text extracted from http://www.dirigidoportests.com/wp-content/uploads/2009/12/disenoAgilConTDD.pdf, a book (in Spanish) about agile development driven by tests and free for downloading. Although the story is pretty far from reality (as ever, but even more in IT world), any approach to this point of view is goof for any new project… but probably you already know this.