You’ve heard about limiting WIP (Work-In-Progress) but how good are you at limiting red time? Red time is when you have compilation errors and/or failing tests. A growing group of practitioners have learned how to effectively reduce red time while test-driving and refactoring code. To understand how to limit red time, it helps to visualize it.

In this talk, I demonstrated various strategies to limit your time in Red. We also analyzed a live programming sessions using graphs that clearly visualize red time. Participants learned what programming processes help or hurt our ability to limit red time and gained an appreciation for the visual cues that can help make you a better programmer and fellow member of the Limited Red Society.

Slides from the Presentation:

At the Agile Bengaluru 2010 conference, Sai Venkatakrishnan and Harikrishnan express their concern on the monotony that has crept into the way we develop application and how it affects us being Agile.

We follow agile, but are the systems we are building Agile?

During the Agile Bengaluru 2010 conference, J.B. Rainsberge, in his Keynote highlights the top 10 things he wished people would stop doing on Software Projects.

This post is moved to Industrial Logic’s Blogic.

Mike Bria of InfoQ interviewed me yesterday to find out what is happening with SDTConf. Here is the interview notes on InfoQ. Enjoy!

At the end of the Programming With the Stars @ the Agile Mumbai 2010 conference, based on public demand, J. B. Rainsberger and yours truly did a 6 min public demo of Pair Programming. We started with an Ugly Pairing session, trying to show-case some pairing anti-patterns.

Followed by an average pairing session:

Enjoii madi…

Usually when I’m wrapping up my 3 day TDD Workshop, I make it clear to the participants that they will have to deliberately practice, every single day, for a few years, to get better at TDD. In addition to practicing on their own, on pet projects and on production code, I also suggest they take 2 hrs every week on a fixed day of the week, as a whole team, to practice Test-Driving (TDD) the same problem as a team. During these sessions, I strongly recommend people practice Pair programming also.

Logistics: Before the meeting, one of the team member sends out the problem to everyone. On practice day, the whole team gathers in a conference room/team area, picks a pair, sets aside 90 mins to TDD the problem. After 90 mins, few pairs do a quick code walk-thru and explain their solution with important decisions they made during the session. Followed by an open discussion. I also recommend everyone checks-in their code in some common repository, so it can be used for reference by others.

Sample Problems: Next big question is, what problems do we use for Test Driving?

Usually I recommend starting with simple programs like:

• Games – Tic-Tac-Toe, Snakes and Ladders, etc
• Utility Programs – Convert Roman Numerals to Decimals, Diff 2 files, etc

Once you’ve done enough of simple programs, then I would suggest you take some large design problems from DesignFest and try TDD on them. The beauty of these problems is, they are quite big, can take up-to a week to finish it completely. Now we are talking real world, where

• We have limited time to solve/program large complex problems which needs to be simplified.
• Try to find a relevant System Metaphor that can help you visualize the design
• Do a quick and dirty, low-fi Interaction Design to understand how the user will use this
• Identify and prioritize the crux of the problem, figure out what is the most important, what will give us fastest feedback
• Further thin-slice the identified piece of functionality and
• Then try TDDing it.

This will truly help you get better at:

• Evolutionary Design
• System Metaphor
• Low Fidelity Interaction Design
• Thin Slicing
• Prioritization
• Divide and Conquer – Simplify large problems by breaking them down
• Eliminating Accidental and (to some extent) Essential complexity (Embrace Simplicity)

Deliberately practicing this way for a few years, even though you are practicing TDD on your production project, will really help you appreciate the depth and benefit of this approach to development.

I’m planning the Simple Design and Testing Conference (SDTConf) for the first time in India around end of June.

SDTConf is:

• All Practitioner conference (No Jokers giving lectures)
• All Open Space (discussions and lots of hands-on workshops)
• Invitation Only Conference
• I’ve organized this conference in the US for the last 4 years.

Just because you know the syntax of a programming language, does not mean you know programming

Just because a toddler can make some sounds, does not mean she can speak

Similarly, just because you write tests before you write code, does not mean you know TDD.

TDD is a lot more than test-first. IMHO, following concepts let’s you truly experience TDD:

• Evolutionary Design,
• Acceptance Criteria,
• Simple Design,
• System Metaphor,
• Thin Slicing,
• Walking Skeleton/Tracer Bullet and
• Interaction Design

How long does it take a dev to be well-versed with TDD?

Depends on the dev, but atleast a couple of years of deliberate practice on projects

What can we do to become TDD Practitioners?

Start with deliberate practice in safe env. Then gradually start on your project.