As an agile developer I still prototype but I tend to do it differently than in the past. I now make a distinction between a prototype and a proof-of-concept. A proof-of-concept is code that verifies an approach to solving a problem. I use a proof-of-concept as a sanity check to make sure I am taking an approach that will accomplish what I want. Since I often build things that I’ve never built before using services I’ve never used before I find that a proof-of-concept can help me evaluate implementation decisions early in the development cycle and that can save me a lot of time.
By contrast, a prototype is a mock-up. I use prototypes to help me and my clients visualize how we will interact with a system I am building. I used to build prototypes like I build proof-of-concepts but I now I rarely use a computer for prototyping.
The problem with showing users prototypes is they almost always focus on what is missing as opposed to what is there. My wife is a filmmaker and she has a similar problem when showing rough cuts to her clients. With a rough cut she is looking for general feedback on the main points of the video but she often gets feedback about the audio quality or that colors don’t match from shot to shot. Guess what? Those things are fixed at the end of the project once all the content has been agreed upon so that kind of feedback is not valuable to her in the early stages of a project.
The same is true when building a software system. Prototypes are rough sketches without the robustness of a final product and it is often confusing to users when we show them a half-baked version of their project for feedback, even though they know it is not yet finished.
There’s an old trick in the film industry my wife now uses when showing a work in progress. Rather than bring the client into the studio to see the rough cut my wife has this meeting by phone. She just holds the phone to the speaker and plays the audio for a show to her client who is no longer distracted by missing shots or the need for color correction and can focus on the audio content of the show only.
I’ve learned from my wife and now I very often draw my prototypes away from the computer. In fact, I prefer to draw dialogs for customers to review on napkins for this kind of work; it feels less formal and clients don’t get hung up on what is missing.
When I started to do this I found that I was building far better code and here’s why. When I created a quick and dirty prototype on my computer and then used it as the basis for my product I ended up with code that had coupled the business rules to the user interface. Yes, there are patterns that could help, such as Model-View-Controller, but I found that when I build a system completely apart from the user interface I end up with a far better organized program where all the business rules were encapsulated and apart from its presentation.
Rather than drive a program from main() I use unit tests to exercise each business rule in isolation. I also get the benefit of having a pluggable user interface since it is encapsulated from the rest of the program. And as an added bonus I can mock out the user interface altogether and drive everything a user can do through the UI programmatically so I can automate UI testing.
Difficult problems can be often be simplified when they are broken down. One way to break down a program is to separate the user interface component from the rest of the system. Doing this often makes the program simpler to write, maintain and makes the system more testable.
-
Pingback: A Roundup of Popular Agile Articles - WebsitesMadeRight.com
{1 Trackbacks }
- A Roundup of Popular Agile Articles - WebsitesMadeRight.com
Previous Post: « Prototyping Caveat
Next Post: Don’t Forget to Wash Your Hands »