September 2007
Mon Tue Wed Thu Fri Sat Sun
« Aug   Oct »
 12
3456789
10111213141516
17181920212223
24252627282930

Month September 2007

Scrummaging for unk unks

In 2002 Donald Rumsfeld was ridiculed for his infamous “known unknown” speech. However, despite the ridicule he was in fact quoting an accepted project management theory. That of managing unk-unks.

unk-unks n. especially in engineering, something, such as a problem, that has not been and could not have been imagined or anticipated; an unknown unknown.

Reports that say that something hasn’t happened are always interesting to me, because as we know, there are “known knowns”; there are things we know we know. We also know there are “known unknowns”; that is to say we know there are some things we do not know. But there are also “unknown unknowns” — the ones we don’t know we don’t know.’

When NASA were working on the Apollo programme they realized that, despite their considerable expertise, they had a lot of new problems to solve – including some problems that hadn’t been identified. And because they knew that once the astronauts were in space/on the moon it would be too late to discover they hadn’t thought of something NASA coined the term unk-unk. The engineers then focused on identifying all the unk-unks and solving them before blast off.

With most software projects you are also faced with unk-unks. After all if you’re not solving a new problem why are you writing code? So what should you do about it?

Well you really only have two options. Either, you hedged against by developing on parallel lines and hope that one works out. This is the approach many designers take – they prototype lots of ideas knowing that only one will be picked, and no one can predict which one before all have been seen. Alternatively you can manage the unk unks as they emerge, by changing the approach in response to new information.

If you want to take this second approach then the team needs to be empowered to solve problems en route (rather than only being allowed to build to an existing design and plan). However, in my experience the senior management and/or product owner must also be intimately involved in the project, have sufficient knowledge to check the plausibility of changes, and be supportive of the mid-course corrections.

The project also need to be managed and structured to allow this to happen. And this means the project needs adopt an adaptive, agile methodology, such as Scrum. So the project team are encouraged to solve problems in little steps as they arise and adapt as they learn more.

Graphing a website

Aharef has a nice app built using Processing (an open source visualization framework) that graphs the HTML of a webpage.

HTML consists of so-called tags, like the A tag for links, IMG tag for images and so on. Since tags are nested in other tags, they are arranged in a hierarchical manner, and that hierarchy can be represented as a graph.”

This is what derivadow.com looks like.

Graph of Derivadow’s HTML

And the BBC’s music site:

Graph of /Music’s HTML

And loads more graphs on Flickr.

Google’s strategy to win the next API war

Joel has recently published an article speculating on the future standardization of the Ajax user interface:

So if history repeats itself, we can expect some standardization of Ajax user interfaces to happen in the same way we got Microsoft Windows. Somebody is going to write a compelling SDK that you can use to make powerful Ajax applications with common user interface elements that work together. And whichever SDK wins the most developer mindshare will have the same kind of competitive stronghold as Microsoft had with their Windows API.

Imagine, for example, that you’re Google with GMail, and you’re feeling rather smug. But then somebody you’ve never heard of, some bratty Y Combinator startup, maybe, is gaining ridiculous traction selling NewSDK, which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features. Not just cut ‘n’ paste: cool mashup features like synchronization and single-point identity management (so you don’t have to tell Facebook and Twitter what you’re doing, you can just enter it in one place). And you laugh at them, for their NewSDK is a honking 232 megabytes … 232 megabytes! … of JavaScript, and it takes 76 seconds to load a page. And your app, GMail, doesn’t lose any customers.

But then, while you’re sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug, new versions of the browsers come out that support cached, compiled JavaScript. And suddenly NewSDK is really fast. And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things.

Interesting. I wonder if this is exactly what Google’s strategy is – develop a standardized Ajax SDK, a speedy JavaScript engine and tied into Firefox. Clearly this could all be launched alongside a new version of Google’s office suite and Firefox 3.

Follow

Get every new post delivered to your Inbox.

Join 1,236 other followers

%d bloggers like this: