When you’re creating an application, such as a client’s database, or complex workbook, do you start with a prototype, or do you dive right in?
At the Unstructured Ventures blog there’s an article entitled How To Fail, which lists 25 business guidelines, and alternative idea for each guideline. Number 7 discusses prototypes, mockups and samples.
“7. Build prototypes, mockups and samples.
Instead: Start building in a format and medium as close to the finished product as possible, and iterate, iterate, iterate.”
I’ve read numerous books and articles that list the merits of prototypes and mockups, but I’ve never created one. I always start working in the actual application, where I can test as I go. I’ve got notes from my client meetings, or their list of specifications, and maybe a rough sketch of where I’m headed, but that’s it.
This approach works well for me, especially in a database, where I can build a little, then test it with sample data, before building the next piece.
What’s Your Approach?
Do you create prototypes? Always? Sometimes? Never?
What benefits do you get from your approach?
Hey, you stole my code lib system!
Jan Karel, too bad you didn’t patent it. 😉
I just plaster all my reusable code in personal.xls, a project-wide keyword search usually turns up the relevant section.
–JP
JP, I keep a bunch of generic code in my personal.xls file too, so it’s pretty easy to find. It’s that client specific stuff that’s a bit trickier. The hard part is finding the latest version of code I’ve used in multiple projects.