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 a normal pairing session:

Enjoii madi…

When I start and finish my 3 Day TDD Workshop, I make it clear to the participants that they will have to deliberately practice, on small pet projects or toy code, in a safe-environment ( in-the-nets, if you will), every single day, for a few months (if not years), to get really good at TDD. Deliberately practice on their design, testing, breaking-user-needs-down, pairing, and many other skills using TDD before they can use TDD for prime time.

However, post the workshop, the participants are very excited and they ignore my humble advice. Next day they go back to work and start applying TDD on their production code. While this might look like a good thing (also making managers super happy too.) Over the years, I’ve realized that this pattern is actually destructive. Without the required amount of practice, the excitement soon dies out. And developers start falling back to old habits. Many times leaving a total mess behind.

I was surprised to see very few companies or teams continue and build on these practices, while 80% of them would only use parts of it and fall back. Every time I went back to a company and saw this, I would be very depressed. So I studied what the 20% did, which the 80% did not.

• Were the 20% way smatter or talented than the 80%?
• Did the 20% have better management support, less delivery pressure compared to the 80%?
• Or the 20% worked on simpler projects with no legacy code and so on?

What I found was the 20% quickly realized that they did not have enough skill to apply TDD on their projects. So they:

1. Watched Screen-casts: Watched experts do TDD on real projects. Good starting point: Let’s play TDD by James Shores or this stackoverflow answers

2. Open Source Projects: Studied and gradually started contributing small patches to open source projects, which used TDD. JUnit, Cucumber, JBehave, Fit, FitNesse, etc. are all great examples.

3. Small Pet Projects: Started TDDing small pet projects. Gradually practiced in a safer environment and once they acquired enough skill and confidence, then they start applying TDD on their production projects.

In addition to practicing on their pet projects, on their own, they also took 2 hrs every week (on a fixed day of the week), as a whole team, to practice Test-Driving (TDDing) the same problem. During these social-learning sessions, they practiced Pair programming too.

Logistics: Before the meeting, one of the team member sent out the problem to everyone. On practice day, the whole team gathered in a conference room/team area, picked their pairs, set aside 90 mins to TDD the problem. After 90 mins, few pairs did 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, or any other board game.
• Utility Programs – Convert Roman Numerals to Decimals, Diff 2 files, IP to Country Mapping, etc

Once they practiced enough with simple programs, then they would take some large design problems from DesignFest and try to TDD 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 something semi-real world, where

• We have limited time to solve/program a complex problem, 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/essence 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 truly helped them get better at:

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

4. Code Smells Poster: Created a big poster with all the code smells listed on it. Paste the poster in their team area. Every time anyone from the team found a code smell in their project, that person gets up and adds a dot next to the code smell. This makes everyone more sensitive to these smells and increases awareness by making things visible. (Simple game mechanics.)

5. Refactoring Fest: Picked one of the pungent code smell from their code, and organized a RefactoringFest. Meet as a group (once a month.) Developers pair with each other and everyone tries to refactor the same code on their project to eliminate the specific code smell. [Make it clear that the code will not be checked-in after refactoring. Its a learning exercise and we need a safe environment where people don’t fear touching code. Also if you need some real world code snippets to try refactoring, check out my refactoring teasers.]

6. Blog/Diary: Started writing a blog/diary to capture their learnings and list of issue that got in their way of applying TDD on their project. Writing things down really helped them internalize their learning. [Many times when I’m stuck with a problem, I start writing things down, and the answer becomes obvious to me.]

7. Form a Book Club: As a group, they picked any TDD related book of their choice. Then they decided on a chapter and met over lunch once every week. Everyone came to the meeting after having read that chapter. They used the meeting time to highlight the key-takeaways, debate on the subject and if possible demonstrate it via code.

8. Hands-on Geek-Conference: They participated in a geek conference like Code Retreat, CITCon or Simple Design and Test Conference where they got to meet other practitioners and experts. Got an opportunity to pair with them and learn from their experience plus share your own experience. [Stop wasting your time on stupid marketing conferences.]

9. Teach: They taught a course on Unit Testing or Design Principles at an induction program for new employees or at a local user group. [Teaching is the best way of learning.]

Deliberately practicing this way for a few years to really appreciate the depth and benefit of TDD.

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.

Here is a quick list of differences I found between AS3 and Java 6 (mostly language syntax and concepts)

• AS3 places classes inside package blocks. Which allows AS3 to have multiple package definitions per file
• In AS3 the variable have function scope not block scope
• AS3 is a mostly type safe language with Dynamic behavior. This means you can add new capabilities (functions and properties) to existing objects at run time.
• AS3 has metadata while Java has annotations
• In AS3 semicolons are options if you have one statement per line
• In AS3 casts look more like a function call through the type being cast or we can use the as operator
• AS3 does not support generics and typed collections, except it has typed arrays through the Vector class
• AS3 has E4X integrated into the language to query/manipulation XML
• In AS3, constructors are always public
• AS3 does not allow properties on interfaces. Only functions can be declared on interfaces
• There is no concept of “abstract” in AS3
• In AS3, because functions are Objects, they can be passed around (like Function Pointers)
• AS3 has the concept of anonymous functions useful for declaring callbacks or event handlers inline
• In AS3, the override keyword is required if the subclass declares a function with the same name
• AS3 does not support Function overloading. Default parameter values might help you achieve it to some extent
• AS3 has properties as a first-class citizen of the language. get and set keywords are defined as special getters/setters for properties
• AS3 allows Property access via strings
• AS3 supports Untyped property access – allows accessing property through the String accessor, even if the property is not present at compile time (you’ll get run-time error)
• All AS3 objects can act like String maps
• AS3 supports Untyped variables (mostly type safe language). This allows you to told references without declaring its type
• AS3 allows Initializing dynamic properties using JSON-like syntax. Create and Initializes the object in one statement

Thanks to Chet Haase for his insightful article on ActionScript for Java developers.

I run into a lot of developers who say:

Our biggest problem today is that we don’t get stable, well-defined requirements.

Sure, as a developer even I would like stable, well-defined requirements. But what do these developers mean by requirements?

Detailed Use-cases with Class diagrams and Sequence diagrams. Actual UI Mock-ups and detailed Workflows. Clearly explained Architecture with Sample Code. Set of Test-Cases with Sample Data. Basically a pile of extremely well crafted, up-to-date documents.

When I hear stuff like this, I can’t control myself but ask:

Then, what would you do? Yeah, I mean, what will YOU DO? Can’t I replace you with a program?

Its high time you grow up Kid! Take the freaking ownership. Figure out what is a real user’s/business’ need, build the simplest possible thing that not only works but is also sustainable (maintainable). Of course, its unrealistic to expect one developer to know everything (let it be technology or business or soft skills). That’s exactly why we work in teams. Pull help when you need rather than expecting everything to be served hot to you.

Want Freedom and Growth? It comes with Ownership and Responsibility. Don’t forget to have Fun and Learn new stuff along the way.

Am I not clear yet? Read Who is a Developer?

Since I’ve started working for Industrial Logic, I’ve spent a decent amount of time pair programming with folks in the US. Yes, we do Remote Pair Programming.

Quite a few people have asked me:

• What special editor or tool we use for remote pairing?
• How effective is the pairing?
• How much time is spent in setup each time?
• How long does it take for one to get used to remote pairing?

Here is my answer:

The most important part of pairing is free flow of ideas between the 2 individuals. Its about the brains of the 2 individuals being at the same wavelength so communication can truly take place. Tools can certainly disrupt or get in the way of this flow. But IMHO the individuals contribute 80% towards the success of the pairing experience, tools contribute 20%. Skype with Video Sharing lets us achieve 80%. Better tools might improve that. We’ve experimented with some Eclipse based plugins, all of them have their trade-offs. There is no clear winner. Also on our team since we’re all used to Skype for conference calls, the threshold to get started is very low. So my recommendation is to get started with simple tools, something that you are already familiar with. When starting anything new, focus on the crux and not on the peripheral stuff.

For a more introductory material on pair programming refer to Pairing FAQs.

Based on an open space discussion at GOOSgaggle, Rachel Davies wrote this interest post on Is Working Outside-In Always Better? (in the context of TDD)

This is one of my favorite topic. So I’ll freely express my thoughts here:

When I was doing my little “Avatars of TDD” experiment, I found TDD practitioners could take the same problem and approach it using either the Outside-In or the Inside-Out approach quite nicely. Obviously each person had their preferences. Also the tool used, the choice of programming language and paradigm influenced their technique quite a bit. I could see trade-offs in both scenarios. So I don’t believe in ONE best way.

Personally I don’t choose just one style. Depending on various criteria (listed below) I choose which approach I’m going to start with. I & most programmers I know go back and forth between Outside-In and Inside-out.

I tend to make the decision based on the following criteria (just a list of things that comes to my mind right now, I’m sure there are many more criteria):

• Familiarity with the problem – How clear the problem & its solution is.
• Stage of the feature/Project
• Prior Knowledge/Experience with the technology stack and implementation details
  • If its completely unknown, one might spike it out or build a throw-away prototype. Having the prototype in front of you, can influence which way you start.
• Whether your goal is to go breath first or depth first.
• Whether your goal is to get low hanging fruits first (easy first) or core first (highest risky items first)
• Whether you are driving the design or validating the design (test driven or test first).

Inside-Out and Outside-In also applies at a product level. Which massively influences our development style. For Ex: if the original idea about a feature/product is about a core feature that needs to be built. We could start building just the core idea, getting feedback and then slowly flush out the rest of the system as we build inside out.

It appears to me that, this topics needs a lot of context. Any discussion outside that context might dumb down the importance of this topic.

A lot of people think, if they can write some code, they qualify as a software developer.

IMHO don’t call yourself a developer if you don’t take ownership and responsibility for solving the overall, real business/user problem.

A good developer

• understands the overall problem and its context.
• has good problem solving skills (we are in the business of creative problem solving)
• has empathy for the users and is a user and business advocate.
• takes ownership by being a part-of the team and having a sense of belonging.
• makes investment into continuous learning & improvement

[Agile and Software Craftsmanship movements has made great strives in this direction. However some Agile folks don’t get it. We can’t draw a line and say this side is business and that side is development. Its ONE team working towards a common goal. Unfortunately, I’ve seen a lot of teams who end up creating artificial boundaries between people wanting the software and people building it.]

Anyway, having the ability to just writing some code does not qualify you to be a developer.

Almost a year ago, I wrote something more insightful: Programming in the 21st Century