Eric Ries and the Lean Startup movement seem to have become the hottest trend since Agile. The Financial Times already ranks Ries’ book alongside Clay Christensen’s Innovator’s Dilemma and Geoffrey Moore’s Crossing the Chasm for changing the way we think about innovation and entrepreneurship.
While the book includes “Startup” in the title, and startups are where the ideas were first formulated, its principles are applicable to almost anyone building something new; including point releases of a desktop application!
At the heart of the movement is the concept of the “build-measure-learn” feedback loop.
Ries argues that in order to improve a product you need to track the effect of changes you make to your application. If you’re not measuring these changes then you have no idea whether you’re actually improving the product. Increasing sales might be attributable to better marketing and not a better product. In fact, unless you measure what you’re doing you might actually be making your product worse, not better. It’s fairly obvious when you think about it; by being more scientific, formulating hypotheses and running experiments we can eliminate a lot of the opinion and guesswork that can lead a project to ruin.
The Lean Startup movement, borrowing from the Toyota Way, also encourages us to work in smaller batch sizes because “finding out sooner is much better than finding out later”. The shorter the feedback cycle the quicker you can adapt. The risk of spending six months working on a feature that nobody wants can be completely eliminated.
Many website and web applications have already taken the principle of smaller batch sizes to its logical conclusion and have adopted continuous deployment. Releasing new updates everyday takes discipline, especially with regard to testing, but is not uncommon. Well-established analytics solutions make tracking improvement simple.
By contrast, adopting build-measure-learn for desktop applications is much harder.
The tools for tracking feature usage of desktop apps are less well-established, so measuring improvements is much harder. Worse still are the deployment issues. Whereas a website can be updated by rolling out the latest build to a single server, for a desktop application to be updated every client needs to be upgraded.
As the end user of the application has to do this themselves, it is impractical to release at anywhere near the same rate. Asking them to update on even a weekly basis results in disgruntled users (iTunes) and a proliferation of versions when they fail to upgrade.
Instead of employing a continuous release cycle, most desktop vendors seem to have resigned themselves to the status quo: release cycles measured in quarters not days, imprecise usage data, and long spells of coding in the dark.
If we’re lucky, we try to validate what we’re doing with UX tests and beta programs but this is imprecise compared to the web’s best practices.
This doesn’t have to be the case. With Chrome, Google completely eliminated the pain of updating. As a result they are able to release as regularly as they like, and this has helped give them a major edge in the browser wars. Dropbox, another big name, have also been silently updating for years.
Implementing a comparable system, even using Google’s Omaha framework, isn’t easy though.
That’s why at Red Gate, we’re currently trying to build a service that lets developers silently update their application. We want desktop developers to enjoy all the same advantages as those who code for web. Desktop software shouldn’t become a second class citizen just because it’s too slow to adapt.
We’re currently trying to get as much feedback as possible, so if you’re interested in learning more please check out Quiet Deploy or leave a comment below! We’d love to talk to you.
* We’re also expanding our desktop analytics effort. If you’re interested in learning how people are using your desktop app visit Application Metrics.