On my recent trip to the UK to work with Results Base (see this blog entry), I spent a day working at the L'Etape London by Le Tour de France, a cycling race starting and finishing at the Olympic Park velodrome.
As timing goes this should have been an easy gig, and actually it was, with one small, but potentially very problematic, issue.
Firstly, bear in mind we were using a UHF system using patch antennae. Anyone who has used patch antennae in cycling events will know that they are capable of reading tags from a  considerable distance away, an issue that has created many problems for race timers, and which has to be carefully considered when setting up.
The riders did a final 1 kilometre stretch on the riding course around the Velodrome. We had a 'spotter' timing point at the start of the kilometre. And as you will see, this really saved our bacon.

The problem was that the cyclists rode past the finish line on their way to the spotter point. They weren't all that close and initial testing with a UHF tag indicated that there was no way they would be read as they went past. Ha ha, famous last words! Around 10%-15% of competitors got picked up. We will never know why our testing didn't pick this up, but of course by the time the competitors started finishing it was too late.

If you think about this from a software point of view, there is no way for RaceTec to know that those early reads were not a valid finish time. Unless of course you use the logic that any finish reads BEFORE the spotter must be ignored. Sounds easy, but at this stage RaceTec did not have this functionality.
Fortunately I was able to haul out my laptop and write a quick hack into one of the results procedures in the database, to do exactly this, and the day was saved. (by 'saved' I mean we were then able to relax and focus on normal timing matters such as keeping gear powered up, handling results queries, entering DNFs, etc)

So this got me thinking, if I could write a quick hack during a race, then why can't I make this a permanent feature of RaceTec? The ability to specify that a particular split 'depends on' another split. Or in other words, don't create split B until we have a split A.

Another example: You are timing a triathlon, and a slow competitor finishes the swim, fetches his bike, and exits the T2 timing point instead of T1. He realises his mistake and goes back into transition, then exits at T1.
You have a minimum time on T2 to protect yourself against mistakes like this, but this guy is slow and finishes the swim very late. RaceTec creates a T2 split, and later you realise something weird has happened and you 'fix' his data. But by then it's too late. You've sent out an incorrect SMS, the website leaderboard is all messed up as this slow guy is now in the lead, and you as the race timer are feeling foolish.
So now, with the new split dependency functionality, you tell RaceTec NOT to create a T2 split until the competitor has been seen at the cycle end split. All chip reads at T2 that are before the cycle finish, will be ignored. Problem solved.