XP always interested me. I always wanted to try out real-world live XP style development but never really got the chance. The problem is, at least in Israel, most people don't even know what this acronym means, let alone would be willing to try out pair programming (which, if you think about it a minute, you do almost daily but in short bursts instead of most of the time).

Although XP has lots of facets to it, the fascinating fact is that most developers I know don't even know how to do the most basic and fundamental thing when it comes to good coding practices: Test-Driven development and defensive programming. What do I mean?

Ask the developer next to you “have you ever done Unit Testing?”  its very likely that you'll get  a positive answer to that question. But ask the following questions:

1. How have you done Unit Testing?
2. Have you used any of the Unit testing frameworks?
3. Did you write or plan the unit tests before or after you've written the code?
4. Can you repeat those tests automatically to make sure nothing is broken?
5. What's the first thing you usually write inside a method body?

and so on. Here are some answers you might get(or you might answer them yourself):

How have you done Unit Testing?

• “Well, I opened the GUI and played around with it for a while to make sure the calculation engine was correct“
• “I created a small program that uses my component to do some stuff and make sure it doesn't crash or anything“
• “I had our junior developer come and play around with the code/GUI/component“

 

Have you used any of the Unit testing frameworks?

• “What testing frameworks?“
• “Oh, I've heard something about that. 'Unit' something wasn't it?“
• “I read some article about it“
• “I checked it out but didn't get enough time to play with it“
• “Nope“

 

Did you write or plan the unit tests before or after you've written the code?

• “After“
• “Write a unit test? I do it all by hand“
• “Plan a unit test? you must be joking. The code changes every hour!“
• “I wanted to do it before but my dev lead said we don't have enough time for that“

Can you repeat those tests automatically to make sure nothing is broken?

• “Probably. I remember most all of them“
• “Yeah right“
• “Not really, it was all manual“
• “We recorded some of them with [Insert GUI test automation tool here]“

What's the first thing you usually write inside a method body?

• “Uh.. the method body?“
• “What do you mean?“
• “Try{“

 

These answers ain't bad. They just indicate that there's enough lack of knowledge in the developer community about agile processes to make it scary. Once a developer does get to experience some of the agile processes (test-driven development for example) its very hard to go back to the old ways. It's infectious.  The problem is getting the developer to invest their time, or better yet, getting the company to invest its time in learning these new processes.

Even though agile methodologies have been around for quite some time now, its still very hard for developers and business managers alike to adept to them and learn them. There's a kind of “It looks pretty weird and silly. It's never gonna work” attitude , especially about pair programming, that is really hard to break. It has to come down from management, because sometimes developers just won't do themselves and their companies that favor on their own.

Another problem is that social behavior makes it hard to implement on your own. You certainly can get the feeling you're just being silly trying to get a developer to sit with you on a project when everyone else just sits there looking for the slightest hint of miscalculation or error to say “I told you it was stupid!“. Its never gonna work if you can't back it up with your dev buddies at the helm along with you.

Funny enough, this whole post was supposed to be a couple of lines about an XP link I came across on the XP mailing list: the XP quick reference PDF file.

Oh. and the first thing you usually write inside a method body? Asserts and parameter checking (if needed).