I’ve been talking to the team at Walkit.com over the last few days. They’ve got a fabulous website, that creates walking routes for people, showing them calories consumed and CO2 saved if they walk instead of driving, and today they launched walkit.com for Edinburgh, just in time for the festival. The team is tiny, and they’ve produced something that works really well, generating enormous amounts of public interest and PR.
And then there are my friends at Zoomf.com, who’ve produced a fully functional property search engine that spiders websites, has the most attractive Ajax user interface and all sorts of web 2.0 bells and whistles in the pipeline. Again, small team, massive result.
The output of the teams building these sites is phenomenal, when I compare it with some other projects that I’ve seen, and that’s got me thinking about the variables that drive productivity in software development. Both of these teams are immensely self-motivated (driven by love of a cause, their personal work ethics, the possibility of building a business that has value to investors), both have almost total freedom to choose the process and technologies they use, and they make extensive use of software that others have built. Whether it’s Google Maps, Drawlive, Wicket, Thinkingcap, PHP, Apache or whatever, they’re leveraging the work of thousands of coders to create their products. They’re re-using, and making that an art in itself. They’re building mechanisms that allow people to contribute even once their sites are live: feedback, new walking routes, star ratings and comments … So in the end, all their customers become product developers too.
As for the low productivity projects, I see lack of clear, timely decision making on every one of those.
Oddly enough, the problems with technical projects are almost never technical.