There's been a lot of fuss on Twitter and the technology blogs about the news that "fixing" the clock on the BBC homepage would take "100 staffing days". Is it really that complex to show an accurate clock?
There had been a complaint that it wasn't necessarily accurate, as it was a simple JavaScript clock showing the local time on the user's computer. From the article in Ariel, the BBC's internal magazine:
The decision to remove the clock follows a complaint from a member of the public, who said it merely reproduces the time stored on a computer's internal system, whether this is accurate or not.
He added that there is no labelling which makes clear the clock isn't independently verified and, indeed, may not be 'factually accurate'.
Reaction
"In fact it should be possible with a single line of JavaScript and
perhaps a single line of say PHP back on the server. The clock wouldn't
be millisecond accurate but in most cases it would be correct to the
second." -- IProgrammer
"I always assumed it showed the correct time. But what gets me is further on in the article it states that it would take around 100 staffing days to make the changes involved in switching to an independent clock. Whaaat?" -- 4Networking
"After being forced to remove its website clock BBC estimates it would take 100 days to build a proper one! Really?!" -- @JamesBarnesEsq
"The joys of working for a large corp. 100 days to give a clock widget :)" -- @mischat
"BBC claims it will take them 100 days to fix a clock on their website #jobopportunities" -- @roytries
This reaction is pretty common from enhancement owners when they get any seemingly high estimate for what's perceived to be a simple requirement; but is this reaction reasonable?
Analysis
Those who've been in professional software development, particularly of web applications, can probably see how a requirement of 'show a clock' - in fact, a factually accurate clock - could balloon.Let's look at the crux of the requirement that will have been estimated:
Show a clock on the homepage that is 'factually accurate' for the user's current location, without relying on any features of the user's local configuration.When looking at requirements, I like to find the edges of the scope; to look into the corner cases and see if an internally consistent approach can be developed. My train of thought here goes:
- We can't use the user's computer's local time, so we will have to use the server time.
- The server time is - probably - GMT, UTC or UK local time (GMT, or BST in daylight savings). This is also excluding the complexities of the CDN and the multitude of servers involved (although with NTP they should all have accurate time).
- Showing the user time in the UK is not acceptable for our international users: it'd be a regression as they previously saw their local time (probably).
- We cannot use the user's computer's local timezone as that would violate the original accuracy complaint.
- The BBC already uses geo-IP services for localisation. Will this be accurate enough? Our first item requiring further research/prototyping.
- We'll probably have to update it: the current one updates, and viewers don't see a static clock on the News Channel, so would expect to see it update on the web.
- Can we send one initial time with the server, and update it with JavaScript?
- Does that violate the original accuracy complaint if the user's computer can't deliver a timer exactly every 1.0s? (This is known as clock skew)
- If so, some form of COMET/push of time will be required. Do we want this handled by the existing servers/CDN?
- How accurate does the time need to be?
- Does it need to take into account network latencies? (Not insignificant on 3G, for example)
- What about browser rendering time, if the page started at 11:59:59.900 and the user is on an older/slower computer?
I'm not sure I'd've got to the 100 days estimate, but I can see it not being far off. Mark Stickley's In Defence of the BBC and its Clock makes similar points and brings a BBC focus to it as well.
