Tea-Driven Development

A project I’ve been meaning to do for some time is set up a backup of the crucial folders on my home server to somewhere on the web. Preferably somewhere free, like my existing dreamhost space.

What I didn’t really consider is… and I bet you’ve already guessed it, dear reader: the piddly-poor upload speed on my ADSL connection. Quoted at 448 Kbps, by my reckoning that means I’ll get about 3.3GB up the wire in a 24 hour period… which means we may be here for quite some time. Better turn off that pesky Windows Update.

The nice thing is that, because I’m using rsync, once the initial sync is done, only the changes to files will be uploaded, so traffic should drop back to normal… some time in 2008.

I’m following Gina Trapani’s outstanding tutorials on lifehacker to get me some of that unix command-line joy on the rusty old windows box in the corner.

Note to other linux-naive cygwin users out there. If you want to install the ssh command, look for the package called ‘openssh’. No amount of staring at the packages squid and ssmtp is going to make it appear where you might expect it to.

The stand-up meeting has had quite a lot of attention on my team over the last week. At our last retrospective, it was brought up as a problem that we nearly always had at least one person missing when we started the meeting. Obviously this hampers us reaching the goal of having a rich and motivating exchange of information throughout the whole team. We still get a chance to adapt the plan, but not everyone’s going to know about that if they weren’t there. I also feel it really drags down morale when the same one or two people (and it’s nearly always the same ones) appear not to be as committed as the rest.

So, like all good self-organising teams, we got together and talked about it. Yep, we had a meeting about a meeting.

During this, at times heated, discussion it became clear that we were talking about two separate issues. As well as using the stand-up to synchronise our work, we were using it as our starting-point for the day. Those who like a lie-in will tend to get themselves in just in time for stand-up, and thus their day begins.

So while the first and most obvious issue for debate was what time to have the stand-up meeting, lurking in the background was the much more thorny issue of how late it is acceptable for a team-member to turn up for work.

Fortunately we spotted this pretty much in time before the mud-slinging between the early-risers and the alarm-clock-o-phobes began. On reflection of the benefits of the meeting as a whole, we judged that providing a start-point for the day was not as important as the other benefits about communication which require every member of the team to be present. So we decided to abandon the use of the stand-up as our start to the day.

So that we can still harness the motivation that comes out of a good stand-up, we decided to hold it at 2pm, when everyone should be back from lunch and ready to blast through the afternoon.

All we can do is try it and see how it works.

What time do your team have their stand-up, and why?

I just came across an article written five years ago by Richard Gabriel proposing a university course run along the lines of his own Master’s in Fine Arts in poetry. The idea evidently gathered some momentum at the time, but now seems to have come to a halt.

What a shame. I’ve had an idea to get back to university on a ‘some day’ list for a while, and this would have been pretty much exactly my thing, I think. Seems to me like it was just an idea ahead of its time… I wonder how popular something like that would be now, with the increased focus on Quality that is sneaking in the back door behind the noisy razzmatazz of agile adoption.

Anyone else hate this?

Doofer doofer = GetWidget(widgetId) as Doofer;

Then, somewhere miles away from this innocuous little line, I find that my doofer is unexpectedly null. This is a great way to introduce hard-to-trace bugs, unless of course it’s complimented with guard clauses everywhere to test for nulls, which most of the time means unneccesary clutter.

What’s wrong with good old…

Doofer doofer = (Doofer)GetWidget(widgetId);

?

In this second case, if the result of GetWidget() can’t be turned into a Doofer, I’ll get an exception thrown right there and then. Assuming that my code here works specifically on doofers, I may as well spit out an exception right up here – how the heck am I supposed to work with this other type of widget you’ve sent me?

I think the only time to use a soft ‘as’ cast is in the tiny minority of cases where you really don’t care if the result of GetWidget can be turned into a Doofer. It seems to me that 90% of the time, you really do care, and you’d like to know as soon as it’s not. Even in that 10%, you’d probably be better off using a null object.

It’s a shame, because the ‘as’ operator is a bit more readable, and we all hate having to slam all those brackets in everywhere. Fortunately, C# provides a little-known solution to this, known as implicit casting.