Dreaming in Code
Friday, February 29th, 2008In between developing the Woosabi product and building practice placement systems for Universities (www.inpractice.org) I’m trying to finish this book Dreaming in Code (this is why I’m doing my blogs at 6am in an attempt to claw some of my day back). The book documents the development of an Open Source Calendering/Personal Information Manager (PIM)/Email project that’s been in development for the past 5 years. It’s interesing in that it has quite a few functional similarities to Woosabi - I should stress that the similarities are quite generic and are shared by a whole slew of Web2.0 projects 
One Vision
The main part we share is this vision (Vision):
Chandler - “Our goal is to serve the way people actually work, independently and together, particularly in small groups, a market segment we believe is underserved. Our belief is that personal and collaborative information work is by nature iterative and that the existing binary Done/Not-Done, Read/Unread, Flagged/Unflagged paradigm in productivity software poorly accommodates the reality of how people work.”
That could quite easily describe Woosabi, if we had sat down and articulated it that consicely! But we never did and I’m hoping that where we succeed will be down to all the things we “didn’t do”. I’m not sure if that sounds dumb, belligerent or both as it’s 6am and my vocabulary is still sleeping downstairs (I’m in the attic) but bare with me and I’ll explain that bit of triteness (that’s the word I was searching for!)
God is in the (right) detail
The part of our little project that sets us free from the pitfalls of other large-ish development projects is we’ve thus far kept ourselves largely free from bureaucracy and the meeting moth syndrome - aka the overwhelming desire to plan and attend meetings, usually to discuss what you could be doing if you weren’t currently at a meeting and then to plan the next one, to usually co-incide with some large project milestone.
What we do have is a great development team that understand the product we are building. We didn’t spend months writing white papers and technical specification documents because we never had the luxury of time to waste on something that is superceded by working code and a usable product. Is that a chicken and egg situation? In my opinion, and I could be proved wrong if our product sucks, it’s not. If you have a development team that fully understand the goal (and it could be as simple as ‘to build a login screen” or as complicated as “build an email client”), you use your code as your project plan with the build’s usable functionaility as a meaure of progress.
Teamwork or no work
The one major document we do have is the product’s “Style Guide” which is totally indespensible and almost entirely visual (i.e.without text). This is pretty much the only document that the developers refer to (on a daily basis). Woosabi is lucky in that we’ve a very talented Product Designer who’s able to visualise with the developers the entire product before it’s built.
Which means the other thing your team needs is ‘trust’ which comes not from a creaking shelf of documents that people are pushed toward (”hmmm, it’s all in version 1.2 of the MRS+TFS, now go away I’m trying to look busy”) but from outward, visible signs of work.
Successful IT projects come from having the right people and a good product that is visibly improving. Getting there isn’t easy but in my opinion you need to trust in your idea and build your product. Not just a dream of one.
