The Three Rules of Test Driven Development

Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.

If you think about this you will realize that you simply cannot write very much code at all without compiling and executing something. Indeed, this is really the point. In everything we do, whether writing tests, writing production code, or refactoring, we keep the system executing at all times. The time between running tests is on the order of seconds, or minutes. Even 10 minutes is too long.

Robert Martin

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Besides these rules and independently of an agile approach, I always like as a developer being able to verify quickly my code, because it makes much more easier to find all the errors I do ;o)

Agile Software Development: True Adoption or Just a Label?

At what stage is the agile approach (XP, Scrum, TDD, …) adoption at your location? (2005 results)

Not aware 13% (26%)
Not using 13% (16%)
Investigating 14% (14%)
Analysed and rejected 4% (3%)
Pilot projects 8%(4%)
Partial implementation (adoption of some agile practices) 17% (17%)
Partial deployment (some projects are using this approach) 14% (12%)
Deployed (all new projects are using this approach) 17% (8%)

Participants: 512 (232)

Ending date: February 2008

Source: Methods & Tools

Comparing the 2008 and 2005 results, we could notice that the level of ignorance of the agile movement has decreased, as only 13% of the organizations are ignorant of it. Full deployment numbers have doubled in the recent years to reach 17% and total rate of various adoption levels is now 56% compared to 41% in 2005. This growing adoption rate has also been confirmed by other surveys on this topic. Some critics will naturally discuss the “scientific” nature of this kind of surveys, but I believe that they are useful to give us an idea of the evolution of the software development world. The increased popularity of agile is also visible on the Indeed job request trend.

The recent improvement in agile software development process visibility and acceptance should however make us cautious with the current results on agile adoption surveys. When software development practices are more widely accepted, the number of adopting organizations increases, but the substance of valid usage of this practices decreases. The answers to surveys tend then to be biased towards what should be the correct answer instead of reflecting the reality of the software development context. The tendency of upper management to “push” new approaches to people who are more reluctant to change their old habits does usually not produce good results. This is even truer when projects will not be given additional resources to support the transition.

We are therefore transitioning from a period where agile adoption level may have been underestimated to another where it could be overestimated. Previously, some developers would not define their practices openly as agile or extreme programming because manager would have considered it a “cow-boy process”. A 2006 Forrester’s report found that agile adoption in the US and Europe was 17% according to a survey of 1078 IT decision-maker. They however precised that ” because Agile processes are often adopted at the grassroots level, they frequently fly below the radar. This makes it unlikely that a single IT decision-maker knows what methodology every development team is using. For this reason, Forrester believes that Agile adoption is actually higher than reported in this study.” Today, some companies will pretend that they are agile, but without implementing the essence of the approach.

It is also interesting to notice that the rate of rejection is similar in both surveys. This means that the percentage of companies completely opposed to agile practices is still very low. We could also see that the proportion of companies that are in a partial implementation state is still superior to those who are in partial deployment. This confirms that organizations prefer to adopt agile practices by gradually shifting their process towards agility instead of choosing a big bang implementation. Agility is about iteration and incrementation and this should be also applied to process changes.

When compared to other surveys performed in 2007 on agile adoption, the results of the Methods & Tools poll are equivalent. The adoption rate of participants is slightly inferior with 56% (48% without pilot projects) compared with 73% for the VersionOne survey and 69% for the Scott Ambler survey. Our percentage of organizations having deployed agile approaches in all projects stands at 17%, which is very close to the 15% rate that VersionOne presents for 100% agile adoption.

The importance of the agile approach is surely growing in the software development community. It remains to be determined, with an unbiased perspective, how this evolution will translate in the rate of software development project successes, because at the end, this is what matters the most.

Other agile deployment surveys and agile adoption material

Indeed.com Job Trends for: agile, scrum, “extreme programming”, “test driven”

VersionOne 2nd Annual “State of Agile Development” Survey (2007)

Scott Ambler Surveys (2007)

Scott Ambler Surveys Presented in Dr. Dobb’s (2007)

Scrum Alliance Membership Survey Shows Growing Scrum Adoption and Project Success (2007)

TDD Survey Results by Stelligent (2007)

Boston Roundtable Survey Results by Stelligent (2007)

Agile Project Management Tooling Survey by Trail Ridge Consulting (2006)

Corporate IT Leads The Second Wave Of Agile Adoption by Forrester (2005)

Waterfall Manifesto Agile Software Development Adoption Poll (ongoing)

Slowdown in ScrumMaster (CSM) Certifications?

Low Scrum Adoption Rate in German-speaking world?

Adopting an Agile Method

Agile Delivery at British Telecom - A case study on Agile process adoption

Google Code Blog: Calling all JavaScript developers: Hack the Day Away with Google

On Friday, February 29th, Google will be holding a developer hackathon to get you started on our JavaScript APIs. We will be doing short introductions of the APIs and then breaking up into groups for coding and camaraderie. There will be plenty of Google engineers present to ask questions and get help from. Food will be provided and there will be prizes.

The event is open to anyone in the community that wants to learn about some Google API's, do some coding, or ask some questions. So please bring your laptops and come hang out at Google.

We'll be covering the following APIs:
* Google Gears
* Google AJAX Search/Feeds
* Google Gadgets
* Google Maps
* Google Calendar
* Blogger

The event will be held in two sessions, the first from 2:00PM - 5:30PM and another from 6:00PM - 10:00PM. You are welcome to stay for both.

Seville Tech Talk
Google Campus
1600 Amphitheatre Pkwy
Mountain View, CA94043

Friday, February 29th
2:00PM - 5:30PM
6:00PM - 10:00PM


To attend, all you need to do is RSVP and let us know you can make it, and be sure to add the event to your calendar.

Hope to see you there!

Google Code Blog: Calling all JavaScript developers: Hack the Day Away with Google

New Agile Software Development Portal

The Agile Software Development Web site is a repository for resources concerning agile software development approaches (Extreme Programming (XP), Scrum, Test Driven Development (TDD), Feature Driven Development (FDD), DSDM, Lean Software) and practices (refactoring, pair programming, continuous integration, user stories). The content consists of articles, news, press releases, quotations, books reviews and links to articles, Web sites, tools, blogs, conferences and other elements concerning agile software development. Feel free to contribute with your own articles, links or press releases.

http://www.devagile.com/

Sharing Trough Implementation Patterns

The thing I like about the pattern form is that it gives you a way to talk about the motivation for what you are doing. So there is a lot of Java style books, and good ones, out there people with lots of experience, people who've thought carefully about how to program, but when I read them what I hear is a set of commandments, "Name variables like this, arrange your code like that, etc" and all those are good things to do in certain circumstances, but what doesn't ever come true for me is why? What's the context, what stage needs to be set before that's the right thing to do, and what are the consequences? If I do that what other thing should I do so that the whole system works well together? So there are different personal styles.

People come to those styles because there are a bunch of decisions that work well together. Taking one bit of that out and using it isn't necessarily working well. So by writing a pattern kind of format I get a chance to say: "How do you name fields?" Well, let's see. What are all the things that you might want to communicate? What things might a reader be interested in if they are reading a name of a variable? What are all the constraints on naming, both in terms of like cognitive constraints. Abbreviations don't work well for a variety of reasons, but why? Really long names don't work well, but why? By writing in terms of patterns I get an opportunity to think about all of those. Here is my rule for naming variables, to use simple names that describe the role of the variable in the computation, but if I just said that as a commandment, someone could copy that, but they don't really get it in the same sense that I care about, and more importantly when that is not the right rule, they don't get any sense of what thinking was behind that rule, so they don't know when to break it.

Source: "Kent Beck on Implementation Patterns" on infoq.com

The main point in Kent Beck's words is that you cannot use software development methods and tools without knowing the context in which you should use them. Every time you find something interesting and new, you should ask yourself why and when you could use it, and why and when you should not use it.