Alan has a great post on “Release Priorities, Idleness, and Innovation”:http://www.drizzle.com/~asteele/2005/10/priorities-idleness-and-innovation.html.

Setting the right bar for features in a release– and resisting the temptation to ensure that everyone’s plate is full– is what creates space for solving the hard problems that really matter.

Really good ideas tend to happen when someone in product development gains an understanding of an huge, urgent and valuable problem that needs to be solved and goes and solves it with a really good idea. (The test of it being a good idea is that the solution seems blindingly obvious in retrospect…)

Imagine the situation in which the release bucket is actually half-empty of features, that there is actually “spare time” in the release. … what would you do?

Naturally, you’d scramble to fill the release bucket with enough work from the 1700 programmer-decade queue to keep those developers busy for the next little while. Wrong. The correct answer is: Do Nothing. A half-empty release bucket is a golden opportunity for innovation….

It turns out that good people won’t just sit at work and surf the Internet all day when their queue isn’t full – any more than they would sit at home and watch TV for 8 hours in a row. Instead, they will either (a) find something important to do; or (b) go find another job…

Idleness, discomfort and – key element – the right culture and management support – can be a source of really good ideas.

I am not suggesting that the formal process of understanding requirements, designing solutions, writing specifications, etc. should be thrown out, nor am I proposing that improvement requests from customers or internal users should be discarded unread. But the bar for putting something in the release plan should be very, very high – and if there isn’t enough stuff that meets that bar, then the idle cycles remaining should not be treated as waste.

“Read more”:http://www.drizzle.com/~asteele/2005/10/priorities-idleness-and-innovation.html

Web 2.0 applications are pushing the envelope on what is possible in the browser, but there are some things that are still simply impossible– robust real time notifications, and reliable persistence for instance.

The browser needs to evolve in a way that maintains its essential strength while enables these important features. Until these things happen, rich apps like browser based IM clients or office suites will lack essential functionality. I believe there should and will be an effort to solve these problems in a cross platform way.

In this message I’d like to consider notifications in particular. There are web email applications that pop up a notification “toast” when you get a new message, and instant messaging applications that display new messages in real time as they arrive.

But there are lots of important limitations. Notifications cease the instant you leave the page. Doing real time notifications in an AJAX applications comes at a high cost in terms of server overhead and complexity.

Many web applications rely upon email as their primary push channel, which results in a very “choppy” user experience as the user goes from the to the browser and back. Mobile notifications are even worse, often relying upon short SMS messages which can’t even include hyperlinks.

Other web applications have custom notifier applications that can be installed– the Gmail notifier, the bloglines notifier, etc– complicating users lives and sacrificing some of the essential goodness of true zero install, cross platform web applications.

The IE and Firefox teams are adding RSS feed handling into the browser, but not in a way that allows a particular web application to customize its notification experience, and they are doing polling only, not enabling real time notifications.

At a startup I worked at called Avogadro, we attempted combine the flexibility and zero install experience of the browser applications with a service and an architecture that enabled a real time push channel to applications. For a variety of business reasons, we were forced to focus primarily on cross-device instant messaging, but the basic platform idea was interesting and much more broadly applicable.

Perhaps now the time for something like this has come. Interesting, I think a notification system can be implemented as a small extension on top of existing browsers rather than an entirely new application. Think of it as an uber-notifier that you only need to install once.

This will have value even if it initially only support polled notifications, as long as it allows rich application defined presentation of notifications.

The trick to making this succeed is not to make the user buy into too many different new things at once– a new browser extension is probably OK, but not a new browser, IM service, or other significant behavior shift.