Paul Buchheit (wikipedia entry) is the lead developer for Google’s Gmail. In this blog post he talks about one of the things that he felt that Gmail did right and that was always have live (ie working) code. Here’s the money quote:
The great thing about this process was that I didn’t need to sell anyone on my ideas. I would just write the code, release the feature, and watch the response. Usually, everyone (including me) would end up hating whatever it was (especially my ideas), but we always learned something from the experience, and we were able to quickly move on to other ideas.
If you’re still with me this describes the process we used last year on our big project for a Fortune 100. In that project we used REALbasic as a prototyping tool and using the Agile process we spit out a major new release every three weeks. Even in Sprint 0 (technically the planning sprint) we gave them a working prototype of our ideas.
In this regard, REALbasic excels. Since the entire environment is integrated and the language is easy to use we were able to create incredibly complex user interfaces in a matter of days. The end result is that we exceeded their expectations on creating a user interface that solved their problem. This was, after all, why they hired our team because their internal groups had struggled for years to come up with something.
This company was used to web apps and we were obviously writing desktop apps with RB. This was causing a ton of comments from them because they couldn’t think in anything other than a web app which we obviously were not coding. So we took a sprint and took our desktop app and turned it into something that ‘looked’ like a web app complete with back/forward and home buttons. This was easy to accomplish in REALbasic using Container Controls and a little bit of extra coding. In the long run it accomplished the goal of creating a prototype that was more in tune with their expectations even though we never changed development environments.
Since the project was about prototyping a rather large and extremely complex user interface we had no real guidelines from the client other than this nebulous goal of fixing their problem. One team member would do some layout sketches on paper (and later in OmniGraffle) and get preliminary approval from the client at the end of a sprint. The developers would take the sketches and turn it into working code in week 1 of the sprint and turn it over to testing in week 2 and we’d do tweaks in week 3 for turnover to the client in the end of sprint review with what I (affectionately) called the developers “Dog and Pony Show”.
More than a few times we scrapped entire areas of code and completely rewrote it for the next sprint. This meant that the clients gave feedback early and often and could get changes that didn’t mean anything to the developers, in terms of time, but helped them sell the project internally. When the client goes into a meeting with a roomful of corporate vice presidents and during the obligatory PowerPoint demo they start chanting, “Demo! Demo!,” you know you’ve accomplished something.
All in all, the project was a lot of work and what we gave them at the end of the project was only minimally what we showed them in sprint 0. We could not have delivered as many fully thought out features without REALbasic. It’s an awesome prototyping tool.