So I saw this post today – it’s by Paul Buchheit a former Googler (he is one of the founders of FriendFeed) and the lead developer of one of my all time favorite software applications – GMail (it was his 20% project at Google) and it’s about the concept of Communicating with code.
Paul writes (in his post) on the concept of using prototypes to communicate ideas and concepts. He talks about his work with GMail and how he threw together a prototype in order to show the idea of targeted ads in GMail – targeted ads was not a priority until the prototype showed how useful and interesting it could be. The post ends with a similar exercise that he has done using the Friendfeed API (it’s pretty cool – check it out :-)) The reason I read this post and decided to blog about it is that it talks about developer communication – a topic that I wrote about in another post .
Communicating ideas through prototypes is a great idea – I have always noticed that people get more excited about something they can play with and try out. In fact this is old news in other industries – the auto industry, for example, spends millions to make concept cars to introduce new ideas to the public and solicit feedback Architects likewise – build scale models of their ideas to present to clients. So why don’t we adopt these ideas ? After all we are always talking about “software architecture” and “software construction” and other civil engineering analogies when we talk of software development ;-)
My experience is that when the term “prototype” comes up in software development projects most people are thinking of mock-ups. This is especially true in the web-development shops where there is a separate team of graphics designers creating HTML and image pictures of the user interface while a separate team of developers get to “build” the application from the pictures :-) I think this is a very limiting thing.Prototypes should not be limited to the user experience or to presenting and communicating new ideas. I like to make prototypes of my technical solutions to software problems. For example, if you are trying out this great new idea you had on caching data – write a prototype application – the absolute simplest application you can use to exercise your idea. This would provide you with feedback on whether your idea is valid as well as show up gotchas or limitations in your design. The pragmatic programmers in their seminal book – The Pragmatic Programmer refereed to these applications as “Tracer bullets”.
Sometimes the concepts or ideas themselves are large and need a lot of programming to even build the prototype(tracer bullet). In these cases I still believe one must prototype the concept – so the question remains – how do you do this ?
Well one way would be to take the approach Paul took in building the initial GMail prototype – modify some existing code. I find sitting in front of a blank file makes the task ahead seem even bigger than it is – so I start with a piece of code to modify even if it is something as simple as a “Hello World” application. Another good place to look is in the open source forums (though this might be a problem if you are working in a company that does not allow open source software) – usually there is some variation on your concept that you could work with there :-). A third option is to accumulate code, links and other resources over time that you can use to jump start your coding.
So – Happy Prototyping :-)