Build/Debug/Build vs. Discovery
37signals produced a great handbook for developing web applications - "Getting Real". But still make sure you do discovery, a requirements workbook and most importantly use cases.
Getting Real
A few weeks ago I brought an old book back out – 37signals “Getting Real”, dusted it off and handed it to one of our UI developers, Travis, to read. Today, while pouring a cup of coffee, Travis informed me that 37signals does not believe in the practice of developing Use Cases. I had to look into this more becauase I have been an advocate of this book. I agree with the 37signals web application development approach and I recommend the book to a lot of people but today I am more of an advocate for the discovery process and especially use cases. Our software application development methodology follows a rigorous discovery process with many deliverables. We took this process and implemented it into every type of project and that includes the simplest of web sites. By developing accurate Use Cases our projects have had much more definition and prevented scope creep. When doing a build/debug/build methodology relationships get tarnished, costs grow, timelines get delayed and scope creep is difficult to manage.
Everything else preached by 37signals is spot on. When developing complex web applications the project manager and the client need to define priorities that fit into the budget and the timelines so that the project can go live in a “simpler state”. After the first launch you better have a good game plan and dedicate yourself to the release schedule you promised.
When a project starts make sure you always go through a Discovery process and define the budget, timelines, priorities, functional requirements, design requirements and technical requirements. Develop a requirements workbook and from that define the use cases. Although it seems like a lot of upfront work it pays for itself at the end of the project.
One other thing….test, test, test, test.
