April 5, 2005
Tim Weaver, channelling Robert Glass, on the five laws of prototypes:
- The answer to any prototype / feasibility question is always yes
- Whatever poor coding practices you use to build your prototype will be replicated in the final production version
- No matter how poor the performance of the prototype the production version will be much worse
- Once in production a prototype will never die
- Any controls used to build the prototype will be used in the production version even if they aren't appropriate
How do we avoid these prototype pitfalls? According to The Pragmatic Programmer, it takes discipline. Prototypes are designed to be thrown away. If you can't bring yourself to throw the prototype away, then stop prototyping and start writing tracer code:
You might think that this tracer code concept is nothing more than prototyping under an aggressive name. There is a difference. With a prototype, you're aiming to explore specific aspects of the final system. With a true prototype, you will throw away whatever you lashed together when trying out the concept, and recode it properly using the lessions you've learned.
For example, say you're producing an application that helps shippers determine how to pack odd-sized boxes into containers. Among other problems, the user interface needs to be intuitive and the algorithms you use to determine optimal packing are very complex.
You could prototype a user interface for your end users in a GUI tool. You code only enough to make the interface responsive to user actions. Once they've agreed to the layout, you might throw it away and recode it, this time with the business logic behind it, using the target language. Similarly, you might want to prototype a number of algorithms that perform the actual packing. You might code functional tests in a high-level, forgiving language such as Perl, and code low-level performance tests in something closer to the machine. In any case, once you'd made your decision, you'd start again and code the algorithms in their final environment, interfacing to the real world. This is prototyping, and it is very useful.
The tracer code approach addresses a different problem. You need to know how the application as a whole hangs together. You want to show your users how the interactions will work in practice, and you want to give your developers an architectural skeleton on which to hang code. In this case, you might construct a tracer consisting of a trivial implementation of the container packing algorithm (maybe something like first-come, first-served) and a simple but working user interface. Once you have all the components in the application plumbed together, you have a framework to show your users and your developers. Over time, you add to this framework with new functionality, completing stubbed routines. But the framework stays intact, and you know the system will continue to behave the way it did when your first tracer code was completed.
The distinction is important enough to warrant repeating. Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.
Dave and Andy elaborate more on the distinction between prototypes and tracer code in this Artima interview. I think it might help to develop prototypes in a totally different language or environment. That'd reduce the temptation to code around the prototype. If you don't have the discipline to throw away the prototype, you're defeating the very purpose of prototyping.
Posted by Jeff Atwood
I'm in this very position at the moment - I have built a prototype to design the UI and how the application hangs together. Strictly, I should now through this all away and start again - laudable - but I simply don't have the time to do this.
I need to deliver the website to the testers in six weeks. I needed to prototype to show the users what to expect and to flesh out some UI concepts, but now cannot bring myself to dump it all because if I do, I doubt I'll hit the dealine.
I think that's the crucial point: developers (in my experience) end up basing production applications on prototypes because they don't have the time to do anything else.
I'm with Andy on this one. I run into the same issues of hitting deadlines. Many organizations don't do projects according to textbook SDLC. Now with .NET, RAD development seems to take a whole new spin here at work with prototypes becoming full-fledged applications that are supported on a 24/7 basis. Our group's motto usually is...if you write the code, be ready to support it...so take the time the *first time* to do it right...regardless if it's a prototype. Don't be sloppy.
I agree with the above comments... The ideal solution is indeed to build a prototype which allows you to form a more rounded UI/UX and then based on what you have learnt in the prototyping stage, start building the true application with a blank canvas only using the prototype for reference.
Unfortunately the vast majority of developers do not have this luxury and because of time constraints will have to use the prototype as a starting point!
As a head of development I am trying to foster a more clinical approach to our development efforts where we prototype correctly, develop the application in insolation to the prototype and then have appropriate testing strategies but unfortunately as we are a small company we often find ourselves having to cut corners due to resources issues and time!
All we need is a perfect world!!! :)
If you're running into deadline problems and need to use your prototype you are spending too much time on your prototype or developing a prototype that is too feature rich/polished for a prototype.
A prototype shouldn't take you more than a day (if that), precisely because you should be throwing them away. If you go into it thinking, "I can just reuse my prototype code and save time later!" You will automatically spend more time on the prototype that you could/should be using to just develop the final product.
It's kind of funny that the majority of the article deals with what to do if you can't throw away your prototype and the first comment says something along the lines of, "... but I can't throw away my prototype! What should I do?"