Tea-Driven Development

Rob Conery has kicked up a bit of a stink posting about the use of inline scripting in modern ASP.NET apps.

I may post more on this subject when I have time, but I had to just weigh in with my support for disciplined use of this technique, which can save you hundreds of pointless lines of code and execution cycles in a large app if used wisely.

One trick we use is to replace all those silly asp:LinkButton tags with a good ole anchor tag, and a call to a special utility class called LinkBuilder which knows how the site’s URLs hang together, like so:

<a href="<%= LinkBuilder.Show(catalogueItem) %>">Cancel</a>

This sort of markup can hardly be acused of being spaghetti code (the LinkBuilder method has a single line inside it), and means that we avoid what you might call ’spaghetti execution’ when you actually come to spin the thing up.

Think about what a sequence diagram of the equivalent use of an asp:LinkButton with a wired OnClick event would look like. Eugh.

Maybe NMock supports this, but I can’t see how.

[Update 20/10/2007 - of course it does! See the comments for Aybars and Rob's solution.]

Let’s say I have a dependency of my SUT (system under test). That dependency looks like:

public interface IDatabase
{
  void Get<TTypeToFetch> ();
}

Now in my test, I want to expect that the SUT will try to fetch a Widget.

NMock gives me something which looks like it could help - a matcher. So I can code something like this:

Mockery mockery = new Mockery();
IDatabase db = mockery.NewMock<IDatabase>();
Expect
  .Once
  .On(db)
  .Method(new GenericMethodMatcher(Widget));

So I code up a little GenericMethodMatcher which casts the object passed to it as a MethodInfo and takes a look at the result of a call to GetGenericArguments() to see if it fins a Widget. So far, so exceedingly proper bo.

Unfortunately, the MethodInfo which NMock passes to the matcher is ‘open’, meaning that it still contains just the templated definitions of the types that could be passed to it at run-time. What I need in this instance, is a ‘closed’ MethodInfo object.

I guess this is hard for NMock to do, since it only works with the interface and not a concrete class. I have no idea what’s going on under the hood… Maybe it it possible but I’m just too stupid… I wonder how other mocking frameworks handle this scenario.

How important is it to measure how long something took?

Well, so the received wisdom goes, by comparing how long it took you to complete your a task against the estimate you made before starting it, you get an idea of how good your estimate was. So far, so good.

But what if your estimate turned out to be wrong? What are you going to do about that?

One of the culture shocks I think scrum introduces it the idea that we almost always just look forward. I don’t care how long you’ve spent on a task, I just want to know how long you think it will take you to finish it, based on what you know right now.

Tomorrow, if you turned out to be wrong, that’s OK. All we need to know is how much longer it’s going to take to get it done.

Except it’s not OK.

Because if your task, which you originally estimated would take 2 hours has taken you two days, and it’s still not done, then something is impeding you.

Fortunately in a team practicing scrum, we have a daily 15-minute meeting where impediments like this are made visible to the entire team, and someone takes away the action to resolve the impediment.

Rather than having to retrospectively scan reports of esimates vs actuals in a spreadsheet, the problem can be highlighted as it’s happening, and hopefully resolved.

Agile teams also have a second line of defence against more stubborn impediments: The retrospective.

With these two facilities in place, it becomes unnecesary to track the details of estimates vs actuals. The administrative overhead on developers is reduced, and they can get back to writing solid code.

Some people find this difficult to accept - there’s a familiarity to the recording of the numbers. We’ve allways done it. It makes me feel safe. Somebody will ask us for them.

If someobody asks you how good your estimating is - show them your burn-down chart.

It’s bloody obvious from the shape of the chart if your estimating is any good. And if they want figures, measure the difference in area beneath your real curve (blue line) and your ‘ideal’ diagonal curve (red line). Every hour above the diagnoal line is an under-estimated hour. Show this to your team. Get them to look at it and reflect on how realistic they’re being when they estimate tasks.

If somebody asks you why your estimates were too low - listen to people. Look at your impediments log, and the write-up of your retrospectives. You need a culture where impediments get surfaced quickly from the team, where it’s OK to say things aren’t going well, and where problems raised get solved and cleared out of the way.

Like a few other people, I’m over kGTD. In the first flushes of my infatuation with the way of GTD she was good to me, showed me a few tricks I’d never seen before. We had some good times, syncing away. But my iCal started to fill up with billions of pointles calendars, my projects started to indent to the point where I couldn’t find them anymore, and I never quite got the hang of those… unique keyboard combos needed to navigate around Omni Outliner Pro. Sometimes, important things would go missing, and I gradually started to trust her less, and go back to paper and pens for my lists.

Until now. Todo.txt is a series of command-line scripts for slicing and dicing a text-based todo list. If you stick to a few conventions, you can use the scripts to suck out relevant information as and when you need it. Combined with the humble yet awesome power of the bash shell’s pipe, there are a multitude of ways you can shove your action lists in front of your lazy face. Trust me, if you keep or have ever kept your lists in a text file, you owe it to yourself to check the site out.

Something I always wanted to do with kGTD but never managed to in satisfactory manner was to sync my digital lists to index cards for perusing whilst (gasp!) off-line. Enter linux’s lp command:

todo.sh list | lp -o PageSize=Custom.3x5in -o page-top=10 -o page-bottom=10 -o page-left=5 -o page-right=5 -o lpi=8 -o cpi=15

See here for an explanation of all those crazy lp options.

I just love this stuff. Sometimes it’s almost as good as being back at the terminal of my faithful BBC Micro.