Monthly Archives: August 2005

We’re getting closer

Today was a big day – I managed to ride 120km in under 5 hours. This is more than half the Round the Bay In a Day distance (220km), it’s also nearly the 150km we’ll ride in Adelaide next year.
We started early to miss the wind. Made it down to Mordy (45km) in a couple of hours, but this is where it all went bad. Northerly wind blew up (not due until Sunday) and we had to content with 30km/h winds gusting to 60 all the way home.
Susi decided she’d had enough and went home after 90km, and I pushed on for another 30km. I felt pretty good for the achievement after I finished, but I am shattered.
Be very interesting to see how I fare tomorrow. The ride today is probably the hardest physical thing I’ve ever done. That includes a 60km MTB ride in 40 degree (Celcius) heat.

Building the Sydney Opera House with a rubber chicken

One interesting problem that occurs in large organisations is how to distribute the skills and knowledge of people with experience in both the domain, as well as technology, to those with less experience.
Historically, this has been a document driven approach with chapter upon chapter of architectural direction, pattern usage, framework description and mandatory tool use.
I find this approach to working in teams similar to trying to build the Sydney Opera House witha rubber chicken. The teams are given the plans to this beautiful building, magnificently specified, but are left holding a rubber chicken with which to attempt this feat.
While it is all very nice to want to build the Sydney Opera House, a group of people with rubber chickens aren’t going to do anything of much use, other than bemuse passers by, and occasionally entertain themselves. I’d much prefer to help people learn how to use the hammer, saws, slide rules, nail guns required to build all sorts of structures, and guide them in the direction of the Sydney Opera House, knowing that we’ll end up with a nice school hall, rather than nothing.
There is too large a conceptual gap when dealing with domain and technology experience to expect that inexperienced people can build _anything_, without having a good command of the basic tools of the trade.
The next time that you’re working with a team, make sure that the list of things that are part of the project initiation include “do we have the right team of people, with the right basic skills”.
Otherwise, you may as well hire some professional clowns, at least they’re going to know exactly how to use those rubber chickens.

Privacy – the real deal

I read in an SMH opinion piece by Anna Johnston
“For every pub you visit, video you rent, domestic flight you take, bank account you open and gift you post overseas, there is a fair chance your RTA card number will soon be the key linking all these disparate bits of information about you into a comprehensive profile. That is something governments and marketers have only been able to drool about since the Australia Card proposal of the 1980s was abandoned in the face of overwhelming opposition”
However, it’s quite clear in the legislation that government issued identifiers are not allowed by the privacy legislation to be used as identifiers for information. You’re not allowed to use a medicare#, passport# or any government issued identifier (ABN doesn’t count) as a means of identifying an individual in a data store. If you ignore this, then you’re breaching the privacy legislation here in Australia, and can be prosecuted.
There’s so many more fear-mongering elements of that article that if they were enacted would breach some, or all of the nine national privacy principles or eleven information privacy principles that are part of Australian law. These include collection, disclosure, aggregation etc. Admittedly, this legislation on is relevant to the Private Sector, and the Goverment has slightly different requirements which can be found here.
One would have thought that “[the] chairwoman of the Australian Privacy Foundation [and] the NSW deputy privacy commissioner from 2001 to 2004” would know the legislation a bit better than some random programmer. Or maybe she’s got some other agenda ?
I mean, I can understand how you could be confused, the Privacy Act has only been around since 1988 and the privacy principles since 2000.
This is not pro- or anti- any political party or person. I’m anti-stupidity and fear-mongering. I can’t quite work out which one this article was. I should probably listen to the wise words of my grandfather – “Never attribute to malice that which can be explained by ignorance”.

Tools are a warm blanket

I was prompted by a blog entry from Andy Marks about tools used.
In my new role I’m looking at transforming the way that software development is performed, and I’m constantly reminded of “the old school” tools driven approach which I’ve always hated.
Putting it bluntly, tools are a warm blanket, useful only if you have a roof, 4 walls and a nice fire. If you’re out in the open, snow all around you, a warm blanket looks like it will help, but face it, you’re going to catch hypothermia and die. Without the blanket, you’re going to die faster, which is probably much better. In the case of software development (rather than my grandpa analogies) failing faster is the key. Fail fast and try again with new learnings, or succeed – failing slowly is the worst possible outcome.
A long lingering death of a software project, propped up by tools that are inadequate or inappropriate guarantees recriminations, witch hunts, and the festering “business .vs. IT” mentality that is entrenched in the corporate computing world.
So, what are we to do ? We have to always remember that its people that are the key to success. I’ll stretch that a little bit more, it’s people and their skills, not process and tools.
Where does that leave tools ? I mean, they’re useful, because it enables work to be done with greater productivity. Who doesn’t use a refactoring editor these days ? Extract method is one click away, rather than following the 8 steps in Martins book.
I was talking to my manager about this phenomenon, and I was able to articulate my view more clearly about the value of tools in software development.
“Tools should be used to automate tasks that people understand how to perform, not provide a crutch for people to perform tasks that they don’t understand.”
If the people don’t understand how to perform a task, don’t use a tool to hide it, help them learn how to perform the task first, then use the tool to automate it, make it less error prone.

100.29 km

As my wife has mentioned we went for a ride on Saturday.
This is my longest ride that I have attempted, and has been a pretty good test for my arm. Sadly, it’s my aching back that’s giving me more grief, and shows that I need to put more effort into flexibility as much as strength and endurance.
I pulled up at the end of the ride OK. My legs were tired, but I was far from shattered with exhaustion. I probably could have ridden another 50 without too much trouble.
We rode the 100km in just under 4 hours (3:56), which I’m pretty happy with, given that there are significant parts of the ride where we have to pootle through city streets to get to the open road, have traffic lights etc. On the open roads (and even with a very nasty headwind at one stage) we would sit on 28-35km/hr which I didn’t think was too shabby.
Ok, so it’s not going to win Le Tour, but that’s not the reason. We have a 220km ride in October, and 150 km ride in January as our aims, and provided I can finish those with a bit of a spring in my step, I reckon I’ll have made a pretty good comeback to fitness.
It’s important to keep looking forward at what you _can_ do, not always worrying about what you _can’t_ do. And that goes with everything in life. Set goals, stretch yourself, find something you enjoy and do it more. Live life and be a participant, not just a spectator.