Google Wave: Panacea or daydream?

I finally got around to watching the Google Wave developer preview video last night. I'm a great fan of any tool that helps people work better together. If you've not heard of Wave, or not had time to investigate, it feels to me like a hybrid of e-mail, instant messaging, Wikis and SubEthaEdit. Users can create new waves (documents/conversations/communications), make them available to others, and work on them. Wave manages to (surprisingly elegantly) bridge the gap between e-mail, instant messaging and wikis. When you edit a wave, the other person can see your changes as you make them, one character at a time. On the other hand, if they aren't online, the next time they come back online, they'll see your wave waiting for them. This is pretty difficult to describe, but beautiful to watch, and it scales. Watch the video to see what I mean, but suffice to say something which starts off feeling like an e-mail can transparently become a discussion and the reverse is just as true.

There's no doubt in my mind that the technology involved is amazing, but from my perspective, the most interesting thing about the video is that it makes the scale of Google's ambition clear. Google are pretty openly hinting that this thing could become a rival to, or even replace e-mail, IM, Wikis and a whole bunch of other collaboration approaches with a single unified solution. Read that sentence again. A replacement for e-mail; a protocol and metaphor for communication that's been around in more or less its present form since 1982. That's 27 years. 7 years before Tim Berners-Lee wrote his first proposal outlining the workings of the World Wide Web. Google are either seriously confident, or seriously arrogant. Or both.

But. They might just succeed. Unlike many other Web 2.0 services such as Twitter, Google are (at least outwardly) trying hard to ensure that Wave doesn't become a walled garden. Even services such as Google Sites, which offer integration with the outside world using standard protocols (in the case of sites through HTML linking and RSS) don't provide the same level of integration seen in the standardised protocols that support e-mail, IRC and other 'old school' services.

So, what makes Wave different? Google have built, and more importantly released to the public a protocol that allows any old Tom, Dick and Harry to create and implement a Wave server. Moreover, because the protocol is not trivial, Google have open sourced reference implementations of the protocol, and in the video suggest that they're intending to open source the majority of the code-base of Google Wave itself so that competitors can download, tweak and run their own competing Wave services. These services will all federate, and make the experience broadly seamless regardless of which provider you choose to use. Like E-mail, USENET and IRC, information is only sent to the servers supporting users actively involved in the wave, opening the possibility of the (perhaps justifiably) paranoid running their own organisational Wave servers to ensure that content only leaves the corporate network when it is actively shared with a third party. This approach potentially eliminates a major barrier to adoption in the commercial world. Lastly, Wave provides support for Robots (intelligent agents) that can accomplish a multitude of tasks. Google demonstrated Robots that did things like integrating with Google's blogger service and it seems clear this technology could be extended to support integration with existing communication mechanisms, and in particular the big threat: e-mail.

How this all pans out remains to be seen. Google are not an academic organisation, and they must deliver value for their shareholders, but it's fair to say that they have a history of taking relatively large risks by taking on large scale projects with no obvious revenue model that would scare your average VC witless. Despite this, they're still here, and still profitable. I think it's reasonable to say that there's an excellent chance that Wave the product will be a success. I'm much more sceptical about Wave the global infrastructure, due in part to the complexity of the technology and consequent barriers to entry for competitors, but mainly due to something much more human: Inertia.

Regardless of the success of the Wave platform, the debate Wave is likely to stimulate can only be a good thing. The Wave preview opens its doors on September 30 2009 to the next 100,000 users. I have my fingers crossed.

Lies, damned lies and statistics

A client I'm working with that the moment has been doing some work around calibrating an estimating model. This model is based on allocating deliverables passing through the project a number of 'points', based on their perceived complexity, and then creating a weighted estimate based on these points. We decided to calibrate the model using a more detailed estimate of a random sample of these deliverables.

A quick review of these figures yesterday revealed a strong correlation(around 0.85) between the number of points allocated to an item, and its resulting estimate. "Hurrah!", we said. Then we said: "This model is useful, and can give us a reasonable estimate of any given subset of the overall project and therefore in particular, of each of our planned iterations." Things were good. Then we twigged.

When we ran the calibration workshop, we asked people to estimate each deliverable. When we described these deliverables, we gave a brief description of the scope of the deliverable, and mentioned the number of points allocated to the deliverable. Nothing wrong with that, right? Well, we decided to do a little experiment, and re-ran the same test, with the same people, but a different set of deliverables. This time, we didn't tell them the number of points allocated to each deliverable.

The correlation was now 0.19. By most definitions, this means there is no correlation whatsoever. Our model is broken.

So, what's going on there? I think (and I'm no statistician) that we're seeing human nature at work. If you tell people something is twice as hard as something else, they're inclined to estimate it'll take roughly twice as long. If you estimate something is three times as hard, the estimate will be three times as long. When we estimate, we don't know we're doing this, as our gut (rather than our head) is doing the heavy lifting here - it's hard to apply a lot of intellectual muscle to something that's ill defined. Gut bases its decision on whatever information is easily available; in this case, someone just told us this thing is 'hard, twice as hard as the last thing', so the number we come up will start off roughly twice as high. If we get some information that makes us believe it's simpler than this, then we might try and adjust Gut's estimate downwards a little, but we'll likely never estimate it totally objectively after being told initially that it's 'hard'.

Thankfully, for us, this hasn't caused a problem. We're mainly interested in the overall averages rather than the specific estimates. We can still predict reasonably accurately the overall length of the project, even if we're a little out on the fine details. The lesson here is clear though: Be careful how much trust you put in these kinds of estimating excercise. They may not be as scientific or accurate a you first believe.

Can SOA governance technology be distracting?

In a recent post, David Linthicum asks "Can SOA governance technology be distracting?". His answer is yes, and he offers the following sound advice:

First, only purchase SOA governance technology, if it's indeed needed, after you have a complete semantic-, service-, and process-level understanding of the problem domain. Never before.

Amen to that. In my opinion, for all but the most mature and involved environments, the procurement of an SOA governance platform should be well down the list of priorities. I'd add to David's list of things that need to be 'worked out' before you get that cheque book out:

• What is your vision for governance itself? Do you want to adopt a 'iron fist' or 'hand in glove' approach? Is your registry going to be a mechanism for governing or a side effect of it?
• Who's going to populate it? Have you got your analysis, design and development processes sufficiently honed that your repository isn't going to turn into a dumping ground of candidate services?
• Have you actually got any services live yet? Governance is a whole lifecycle thing. Until you've worked out how you're going to deploy and manage services in the production environment and demonstrated that this works, how do you know what capabilities your governance platform needs to offer?
• Most importantly: What are the use cases for your governance platform? Can you demonstrate that these use cases can't be addressed using your existing tooling (even if that's Microsoft Excel)? Be honest with yourself about when you're likely to implement these use cases. If the answer is further than one year away, then for the time, you might be wise to forget them. There is little point in spending good money on runtime governance or automated deployment technology when in a year's time you'll be able to get more for less.

A lot of projects using SOA governance tools at the moment treat them as glorified databases. If that's where you're at, consider using something less specialised that allows you to evolve your ideas, understanding and schema before you commit to something that will make this innovation harder and more time consuming. When you've spent six to twelve months getting your ducks in a row, so to speak, you'll be in a much better place to make decisions.

I'd really welcome stories from people about how they've implemented governance platforms in the past, whether they're informal (e.g. Wikis, bugtrackers, spreadsheets) or formal (e.g. IBM Websphere Registry and Repository, CentraSite from Software AG): What did you implement? What worked? What didn't? What would you do differently next time?

Choosing an Open Source 'ESB' technology

I'm currently working to find the best Enterprise Service Bus for a project. Nothing unusual there. Something I've done a few times before. Except this time the requirements are a little more unusual than which kinds of transformation the tool supports.

Functional requirements:

1. The ESB must fit with Smart421's SOA patterns.
2. The ESB need not be a one-box solution. We're happy to mix and match tools around the outside. BPEL in particular is not necessarily a mandatory part of the core product.

On the face of it, not too tricky. In practice, maybe a little harder: In our view, the ESB isn't a piece of software in the first place, it's a collection of (continuously changing) standards and policies that govern the interactions that take place across the essentially empty void between two services, so we're looking for something that's compatible with that view, rather than something that wants to sit at the centre of the SOA universe (more on this later, perhaps). Let's look at the non-functionals:

1. The ESB must be Open Source, be based on an Open Source product, or there must be an Open Source version available.
2. The ESB must have an established presence in the market - the latest and greatest features aren't enough. We're looking for something that has some industry buy-in.
3. It must be possible to buy in support for the product from a third party, should we need it.
4. The ESB must support light weight development. We must be convinced that easy things are easy achieve, and hard things are proportionally (and not disproportionately) harder.
5. The ESB must offer a non-functional envelope that allows it to support a large scale enterprise application, preferably without restricting us to vertical scaling.

I'm intending to follow a fairly standard product procurement process to help select the technology, so the next step is to set some more formal selection criteria and identify some candidate products to form the ESB core.

At the moment, the obvious candidates for me are:

• Mule
• OpenESB
• Apache ServiceMix + IONA Fuse
• JBoss ESB
• Apache Synapse + WSO2

I'll keep you posted as I progress... Comments/suggestions/vitriol welcome!

Battery Statistics

Simon Wilson recently explained that you can get information on the original and current capacity of your battery using the following command:

ioreg -w0 -l | grep Capacity

This works great on my machine, but just thought I'd mention that for those afraid of the command line, as I've previously mentioned, there's a great little utility called CoconutBattery which provides a GUI interface to all this. Try it, you might like it.

The start of a trend?

From MacWorld:

Huge newspaper makes Mac switch move - Mac - Macworld UK:

One of Europe's largest newspaper publishers, Axel Springer AG, has announced plans to migrate its 10,000 employees and 150 newspapers in 30 countries to the Mac

Speaking in a video message that's now available through YouTube, company CEO Mathias Döpfner notes the following four reasons for the shift:

• 'Most of the company’s layout work was already being done on Macs
• 'Macs are more user friendly than other computers
• 'Apple creates the most elegant computers
• 'Macs are cheaper to buy and easier to maintain than they were in the past.'

Could this be the start of a trend? I'm not expecting an avalanche of such announcements in the near future, but the world is changing. Microsoft seem to be suffering from horrendous PR problems at the moment, with people (regardless of the reality of the situation) starting to view them as dazed and confused. I saw a magazine cover the other day which posed (if I remember correctly) the question: "The end for Microsoft?".

The $64000 question for me is "are Apple really any better than Microsoft?" I think the jury is still out on that one...

Battery Woes & Coconuts

Why is it that all laptop batteries eventually die?

Whenever I charge my MacBook Pro completely, the battery meter stops at 98%, and the battery says it's charged. I'd like to think this just means that I get 2% less charge than I used to, but the reality is far less appealing. When I unplug the juice, my laptop informs me I've got 1:33 to live. I used to get at least 2:30.

I know it's a reality that laptop batteries behave like this, and I'm aware that nothing short of a breakthrough in chemistry is likely to change this, but what I would like to see is some kind of transparency about the state of the battery - an advanced battery meter if you like. Something that shows the theoretical battery capacity, the charge attained last time it was full and it's current level. The meter could also show the number of 'charge' cycles the battery has been through to provide a view of the likely useful life of the battery.

I guess it would look a little like this:

Thankfully, someone's gone to the trouble of doing exactly that. CoconutBattery provides all of the above information at a glance, allowing you to understand exactly the position you're in. Which in my case is that I'm the proud owner of one of the oldest MacBook Pro's on the market (29 months? Has it really been that long?), and its battery is getting a bit weary. Perhaps it's time to buy a new one...