|There's more than one way to do things|
Does Anyone Use Rapid Prototyping?by Sherlock (Deacon)
|on Jun 25, 2001 at 21:03 UTC||Need Help??|
A recent node entitled Coming up with code design by zdog interested me a great deal. As I read through the list of ways that various monks design their applications, I was rather surprised that not a single monk mentioned the use of rapid prototyping when doing application design. I had initially considered simply replying to that thread, but I felt that this issue warranted a discussion all of its own.
One problem that I've faced time and time again when creating an application is a complete lack of experience in the field for which the application is being developed. I've written web servers, gaming engines, an ARINC 429 protocol simulator (don't ask), scheduling software, and more. Now, I'm writing logistics software. In very few of these cases have I found that I've really had any prior knowledge of the subject area that would help me (imagine how I felt when I came upon the ARINC 429 protocol simulator).
So how does one go about designing a project that you have no knowledge about? How do you design an ARINC 429 protocol simulator when you don't even know what ARINC 429 protocol is? No matter how much time I could spend on the design, I don't think I'd ever be able to come up with something decent unless I really began to understand my problem environment. My solution has been to create a rapid prototype.
For those of you that might not be familiar with a rapid prototype, it's basically a quick "mock-up" of your intended application. Maybe it's a bunch of user-interface screens with nothing behind them, or maybe it's a very simplistic version of your final product. One way or the other, it's a "smaller" version of what you eventually intend to build. The beauty of the rapid prototype (although many managers fail to see the beauty in this) is that, after working on the prototype for some length of time and investing person-hours into it, you simply throw it away. For more information, you might want to look here or at What is Prototyping?. The idea behind the prototype isn't to generate a final product, but to learn how to develop that final product. You can see, ahead of time, what problems you might run into with your user interface, or what problems you'll eventually have to overcome with your data structures, etc. Once I've had a good look at the problem domain, I can more easily create a good design.
The Benefits of Rapid Prototyping
As you've probably already guessed, I'm a strong advocate for rapid prototyping. Let me try to point out some of the reasons why I believe it is a good practice.
1. Teaches you about your problem domain. As I have already mentioned, creating a rapid prototype will help you learn about your problem domain. I believe it's safe to say that you'll learn more about how to build a specific application if you actually try to build it rather than thinking about the different ways you could design it.
2. Irons out usability issues. Creating a rapid prototype (especially of user interfaces) allows you to quickly pinpoint and repair problems with your application's usability. By showing these screens to your customers right away, you can quickly determine exactly what your users really want from their application. I'm sure we've all been in situations where the customer tells you what they want and then, after you've built that for them, they tell you that what you created wasn't really what they wanted at all. Rapid prototyping can minimize that problem.
3. Identifies additional requirements. If you create a simple version of your final system, I would recommend that you, or your customer(s) attempt to use the system. In doing so, you're bound to find additional functionality that would be good to have from the system. It's much better to know right away that your customers are going to want to edit multiple entries in a database at once, rather than giving them a final product and finding out then.
4. Reduces development time. This point could definitely be debated. I believe that putting some extra time into a prototype allows you to create a more solid design and, in the end, can allow for even lower development times than if you had not spent that time creating a rapid prototype. Of course, many managers hate to see time spent on something that will never be used, so, like I said, this topic is of some debate. I've always been under the impression that creating a rapid prototype reduces your total development time.
The Drawbacks of Rapid Prototyping
Obviously, nothing is perfect. As much as I love rapid prototyping, it does have some drawbacks.
1. Your customers will think the project is nearing completion. Just as I had mentioned that showing your prototypes to your customers is a great way to get rid of misconceptions or errors from your design, be wary of how they perceive your prototype. Many customers see a screen that looks like a fully functional application and they expect that the project is nearly complete when you've only begun the design phase! You'll have to be very careful to explain this to many of them.
2. "Wasted" person-hours. This goes back to managers hating to see time wasted. For many of them (I really don't mean to pick on managers, either, they just work well for this example), they see developers sucking up bedgeted funds to build something that will be tossed in the recycle bin in under a month. What a waste! If you're looking to do a rapid prototype, it may require some extra convincing here.
I've found rapid prototyping invaluable to my work when I'm trying to generate a design. I try to figure out some initial design (without spending much time on it), then create a prototype from that design. Once I'm done with that, I recreate my design using my new-found knowledge. In every case that I've used a rapid prototype, I've created a much cleaner and more maintainable application in a shorter amount of time than I originally expected and usually with less difficulty.
What I want to know is how many of you use rapid prototyping. I can't possibly imagine that I'm the only one using such a well-known process. If you use it, how do you use it? Do you use the same development environment that you'll eventually use to create your application, or do you use something different, like prototyping software? How much time and effort do you put into your rapid prototype (obviously, this ranges depending upon the size of the project, but maybe in terms of percentage of total projeted time. i.e. This project will take me 400 hours, I'll allocate 10% for prototyping, that means 40 hours.)? Do you use throw-away prototyping, like I do, or do you use a more evolutionary method, where the prototype slowly develops into the final application? Also, if anyone knows of any actual studies done that show the relationship between using rapid prototyping and development time/application quality, I'd be very interested to hear about them.
To say the least, I was shocked when no one mentioned the use of rapid prototyping when developing inital system design. I want to know how people are using it to get the most benefit from it. I'm always looking for ways to increase productivity and reduce stress. ;)
Skepticism is the source of knowledge as much as knowledge is the source of skepticism.