Silver Stripe Blog

I came across an interesting post on TDD today. Before I come to that though, here are three questions on unit testing:

1. How many of us do unit testing?
2. How much of those unit tests are written by developers?
3. How many of those are TDD (tests before code)?

I’m bringing this up because of this intriguing post by Scott Ambler on the Extreme Programming mailing list. Quoting:

Good news, bad news on this one. The data is also in that we’re not doing anywhere near as much TDD as one would come to believe based on all the chatter we see on the mailing lists.

…

Apparently, agilists are more likely to do some up front modeling than they are to do TDD. They’re also more likely to write status reports than to do TDD, so if that’s not a sharp stick in the eye I don’t know what is.

…

There’s also a very clear trend for adopting easy practices such as daily scrum meetings over difficult practices such as TDD.

For the record, at my company we do a lot of developer unit tests, but almost all of them after coding. In other words, its more for regression purposes and as an aid to refactoring, than it is for guiding the design.

What about your company? Do you do unit tests? Developer unit tests? TDD?

A general rule of estimating is that the more you know about something, the easier it is to estimate. The less you know, the harder it is to estimate.

As a project goes on, you learn more and more about the project, modules and tasks. So that means the start of the project is when we know the least about the project. Applying the above rule, estimates are least accurate at the start. Yet, thats when almost all the estimates are done!

Continue reading ‘Rolling Wave Planning and Progressive Elaboration’ »

According to Wordle, Sprint, Scrum, Product Backlog and Team are the most common words appearing in this blog. Click the image below to view the whole list.

Pradeep has a really nice presentation on interviewing candidates. It focuses on interviewing testers, though many of the principles can extend beyond that.

One of the points that has always baffled me is how the candidate is never asked to actually do anything. Instead they are asked a whole bunch of meaningless questions. I’m constantly reminded of this quote from Peopleware:

Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.

Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.

Manager: Do you work with flaming objects?
Candidate: Sure.

Manager: … knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.

Manager: Do you have a line of funny patter that goes with your juggling?
Candidate: It’s hilarious.

Manager: Well, that sounds fine. I guess you’re hired.
Candidate: Umm … Don’t you want to see me juggle?

Manager: Gee, I never thought of that.

In my previous company we made candidates actually write some code. We would give them a simple program to write in half an hour and they could use a computer to code it. They had access to online help, so they could check up on syntax. And sitting in front of a computer allowed them to work in a natural environment. This process of selection worked out pretty well for us. I’ve always wondered why more companies didn’t do that. Any ideas?

If you have been even half alive in India over the past month you would definitely have seen the IPL. I think one thing that the IPL proved was the importance of the team and man-management. It’s not the rock stars that matter, but the team that plays best together. Throughout I was thinking about the agile philosophy of valuing the team over individuals. Check out this fantastic interview with Darren Berry, director of coaching at Rajasthan Royals where he talks about their management style:

http://content-ind.cricinfo.com/magazine/content/current/story/353445.html

Continue reading ‘The importance of the team and man-management’ »