One of the strongest themes to come out of Wellington’s Webstock web development conference last week was the practice of fast, iterative and agile applications development, informed by constant contact with users.
Seasoned US developer Eric Ries, according to the Webstock programme, would teach attendees how to “ship new software at a dizzying pace: multiple times a day while improving quality and lowering costs.” Quality improvement, it seems, can be achieved by starting from a low base, and this need not mean irreparable damage to reputation.
Ries was chief technology officer of IMVU, developer of a social networking application based on a three-dimensional virtual world. The product was developed in six months and released still full of bugs, he says. Almost no-one used it; but the few people who did, the early adopters, shared the company’s vision of the product as it would become.
Their adoption “meant that from almost day one of the product’s life we could be in constant dialogue with actual customers”, Ries says. This enabled rapid improvement centred on customer needs.
The IMVU network now has tens of millions of users; the company booked US$20m revenue in 2009 and is profitable.
Ries gave his audience a number of neat take-away ideas: developers are often dogged by “shadow beliefs”, which waste their energies unproductively.
These include the belief that merely passing to the next stage of a pre-defined plan constitutes progress, that you can accurately predict the future and that you know at the beginning of the project what customers want.
In connection with the last he introduced the idea of the “pivot”, an agility metaphor taken from basketball. A player can spin on one foot and take the play in another direction. So a startup can achieve success by not being afraid to move from its original objective to a related aim that still draws on some of the work done to date, but satisfies a bigger and more lucrative market.
It helps if what has been done to date is always expressed in small reusable modules of running code, rather than large chunks of uncompleted work. Agile development implies development of small parts of code at a time; a lesson which, after many unsuccessful high-profile major projects, is finally common currency, delegates say.