Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
go ahead... be a heretic
 
PerlMonks  

Does Anyone Use Rapid Prototyping?

by Sherlock (Deacon)
on Jun 25, 2001 at 21:03 UTC ( #91347=perlmeditation: print w/ replies, xml ) 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.

Conclusion
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. ;)

- Sherlock

Skepticism is the source of knowledge as much as knowledge is the source of skepticism.

Comment on Does Anyone Use Rapid Prototyping?
Re: Does Anyone Use Rapid Prototyping?
by bikeNomad (Priest) on Jun 25, 2001 at 21:32 UTC
    I've done projects with and without prototyping (I'll avoid the term Rapid Prototyping because it's associated with GUI builders, VB, and the like, which I've not bothered with).

    One problem is that prototype means different things to different people. I've seen the term applied to:

    • GUI mockups to show the users/marketroids
    • proof-of-concept to try a particular strategy or collect statistics
    • the simplest thing that could possibly work
    • a failed first version of a program
    To me, one of the problems with the "build one to throw away" model is that it assumes that one of the following is true:
    • the techniques/tools/languages used to build the prototype are somehow different from the final version
    • it's too hard to convert the prototype into a shippable, high quality product.
    This doesn't have to be the case. If you look at the practice of Extreme Programming, the emphasis is on gradually iterating a system design through constant refactoring and testing. So you don't have one to throw away, you just evolve the system until it meets all of its responsibilities.

    I think there's a tendency in many organizations to view massive restructuring of code as something that is just not done, rather than as a part of normal development. That's sad, and may have something to do with deficient tools (it's much easier to refactor in Perl or Smalltalk than in C++, and the Refactoring Browser makes it simple and foolproof in Smalltalk).

    By minimizing the work done (i.e. not writing anything until it's actually needed), and by testing constantly as new capabilities are added, you always have a working version that will do something. So your system is always its own prototype. This seems more efficient than throwing one away.

Re: Does Anyone Use Rapid Prototyping?
by tinman (Curate) on Jun 25, 2001 at 21:36 UTC

    I use it all the time, usually to meet deadlines :o)

    A good method to prototype would have the benefits you mention, namely, gives a lot of information about the problem domain, helps you figure out exactly what the usability and requirements are... however, reducing development time doesn't necessarily happen...

    In my scenario, Perl (and sometimes Python and sometimes even PHP) are used to build a prototype. At the start of a project, we (the development manager and I) sit down and try to identify what features we will present in the prototype, and what we will not...then, I build it.

    As far as person hours go, what I seem to do is produce a working model of the system. I work in an offshore company, where there is a huge difference in timezones between the client site and where the actual developers reside. We actually find that building a working prototype is a far more effective means of communicating with developers than simply producing a requirements document. Obviously, there are some other advantages as well. Firstly, building a prototype allows a rough estimation of timelines to be made. I can honestly say that I have limited experience in project management, and actually building something (with the core features included) gives me a general idea how much time to ask for (of course, asking and getting the time I want are two entirely different things... :o)

    So far, so good.. now here's the bad part. In our case, the prototyping environment is seldom the same as the development environment. This means that the development times for the prototype do not always scale properly with the development times for the actual product. Secondly, I have seen a tendency (I try to avoid this as much as it can, but it creeps in somehow :o( to underdocument and code somewhat sloppily. The general reason is that I usually *know* its a throwaway application. So, neither my development manager nor I are really worried about maintaining all the coding or documentation standards that would accompany the real product. In the rare cases where the prototype actually evolves to become the product we deliver, this means a few sleepless nights rewriting some sections, documenting and generally sprucing up things.. So, writing to throw away can mean that standards drop (hey, you know its destined for the trash can, so you don't make it as tight as it can go). A reference that I will mention a bit further on also makes this case, that a prototype is usually written using a slower language, and is only optimized for feature presentation. Sometimes, the amount of redesign and re-engineering involved in making that production code can be significant.

    Another negative thing I've noticed is that its very very difficult to convince a customer that you need at least double the time, when you show them a prototype that has all the features that they need. Regrettably, this has been the reason some of my "prototypes" actually made it to production: a demand for a faster delivery time by the client. Therefore, through hard-won experience, we never spend more than 20% of our forecast development time on the prototype.
    Side note (because I can't resist sticking it to the "other" development language in our company): using Perl, I can generally build the entire thing with 20% of the development time :o) yay Perl :o), double yay CPAN

    The references that I mentioned are:
    Software Engineering by Roger Pressman (now in its 4th or 5th edition): I think almost everyone who is into software development should take a peek at this book if they haven't already. (Update: thanks to princepawn, its actually Software engineering, a practioners approach. you can find it in the reading list here, also here)
    Rapid prototyping by Vonk (I think this has a study on prototyping)

    I'll probably update with a few links when I can find them...

Re: Does Anyone Use Rapid Prototyping?
by DrSax (Sexton) on Jun 25, 2001 at 21:58 UTC
    As a software designer, one of the things that I have noticed on several projects is that the road from prototype to product is much too short a one. At least, in the mind of management. I have seen numerous prototypes turned into products by the pressure to "get it out there". You must be very careful to use good, open design in these prototypes, because the powers that be will often bless them into production while you only intended to use the prototypes as a 'proof of concept'. I have also seen these same prototypes become bloated pigs of code because they never should have taken that journey. They were only supposed to exist to show what the product could do if we had a real one. One year and thousands of lines of kludge later, the prototype is still around. Hanging around your neck that is.

    The moral of the story is this. Design everything, even a proof of concept or prototype, as if they were going to grow up into full-fledged products. If you have a manager or director around, odds are that they will.

    Brian - a.k.a. DrSax
Re: Does Anyone Use Rapid Prototyping?
by Sherlock (Deacon) on Jun 25, 2001 at 22:31 UTC
    Maybe I'm jumping the gun a little bit here, but it seems that most people feel that if they make a prototype, that prototype will often be pushed into production without that really being your initial intention. After reading bikeNomad's response, I was ready to go off about adding functionality to a system that wasn't deisgned for it, but DrSax did that for me. So nice of DrSax, don't you think? ;)

    I guess I've always felt that the point of developing a prototype is to get a better idea of what is happening and possibly make some better judgements about how much time it will take to actually make the final product. One way to minimize the time spent on creating that prototype is to drop some of the standards (i.e. documentation, ground-rules, etc.) so that you spend as little time as possible on this "proof of concept." Of course, if your prototype is eventually going to be forced into production, this could (as some of you have already pointed out) come back to haunt you later.

    So, as if the list of questions about prototyping wasn't long enough already, let me add to it. Has anyone ever convinced someone (be it a manager or a customer, etc.) that the prototype really should be thrown out? I guess this is somewhat aimed at bikeNomad, but of course anyone is welcome to answer - How do you deal with the "kludge" (as DrSax called it) that seems to result from adding features to an application that wasn't initally designed to have those features? Doesn't your application become difficult to maintain, or are you constantly redesigning as you go? And, if that's the case, isn't that a lot of work? (okay, so it was a slew of questions - sue me.) Finally, have people found that prototypes are more trouble than they're worth? If you're constantly forced to put prototypes into production and that is causing you more headaches than if you hadn't created the prototype at all, is it really worth it?

    I'm still a firm believer in prototyping, but the problems that people have run into with them has surprised me. I'm very interested to hear what you all have to say about the practice of prototyping.

    - Sherlock

    Skepticism is the source of knowledge as much as knowledge is the source of skepticism.
      Interesting questions, Sherlock!

      Has anyone ever convinced someone (be it a manager or a customer, etc.) that the prototype really should be thrown out?

      There have been times that this has been a problem for me.

      I worked for a company that made tape backup software. One of our big customers (for whom we wrote a backup app that was included in a version of one of their products) was a huge software firm in the Pacific Northwest. They had an immense corporate network (thousands of servers), and their internal IT people had hacked up an enterprise backup system using a language they had developed that is often used for rapid prototyping. For some reason (partly because we didn't have the enterprise features that they wanted), my company actually paid them for this prototype-quality code. Unfortunately, it wasn't exactly robust (this is an understatement). It was an interesting proof of concept, but hardly product quality. We tried to convince our company that it was a bad idea to ship this code, or even work on it. Since they had paid for it, they had the mistaken impression that it was worth something. I left shortly after that, but I think they actually shipped it, and then came to regret it.

      Other times, prototypes have been useful while doing hardware/software co-design (I've worked with embedded systems a lot). If you don't have a fully working machine, you don't really need a fully working program to run it. In these cases, it was easy to say "the prototype only worked on the lab machine".

      How do you deal with the "kludge" (as DrSax called it) that seems to result from adding features to an application that wasn't initally designed to have those features?

      Well, if you do your development right, this doesn't happen. That is, don't over-design up front and then try to patch things on, and be willing to scrap (or at least edit) large amounts of code as you iterate the development. If the design is getting in the way, change it. That's what refactoring is all about. Too often, a "design" becomes sacred and no one wants to change it. Some people even think "design" should be done by different people than the ones who "develop" (don't even get me started on this silliness).

      Doesn't your application become difficult to maintain, or are you constantly redesigning as you go?

      You're constantly designing. Not re-designing. If you do it right (that is, not trying to gingerly tack on changes), you don't end up with a brittle system.

      And, if that's the case, isn't that a lot of work?

      Well, it's no more work than building a prototype to throw away and then doing it again a different way.

      Finally, have people found that prototypes are more trouble than they're worth?

      It depends on what they were intended to do. Generally, you don't have all the answers up front; it's a peculiar belief that systems can be designed up front in their entirety. So always having something that will at least partly work will answer more questions than just thinking about the system during a long "design" phase.

      If you're constantly forced to put prototypes into production and that is causing you more headaches than if you hadn't created the prototype at all, is it really worth it?

      If you don't have something that's explicitly a prototype, that won't happen. You'll just have a version of your program that is either complete (that is, it does all of what it is supposed to do) or isn't. If it isn't complete, you'll know it, and you'll tell your managers. No problem. That's why it's better (IMO) to evolve a program through iteration than to have an explicit prototype. You always have a version that does something, and you know where you stand with respect to its requirements (because you've already collected all the "stories" about what it is supposed to do).

Re: Does Anyone Use Rapid Prototyping?
by fmogavero (Monk) on Jun 26, 2001 at 17:21 UTC
    I use rapid prototyping.

    As a consultant I took a web interface design class. The instructor was extremely knowledgable in this area. The on ething that I took away from that class was drawing the web pages on paper or making them on construction paper. She explained that by doing it this way the client would realize that this was indeed the design phase.

    The other benefit of this was an initial usability testing phase. "People off the street" were asked to physically press buttons drawn on the paper to navigate the website after they were given a specific task. This indicated the "ease of use" of the layout.

    The interesting thing about the class was that we never got near a computer. It was all paper. Big 3M sheets that stick to the wall, post-its, construction paper. Anything but a real computer and all of the class were web programmers.

    I have found through experience that rapid prototyping also helps to manage client expectations when used properly. It kind of gives them that "Little Building" that architects model for their clients while they really design the thing. I am sure everyone is well aware of how much client expectation management plays into the daily stress level.

    I my current position, rapid prototyping has put me light years ahead of other newcomers in regards to the product. It has helped me to ask the proper questions. When I started I knew nothing about the industry I am in now. Within a couple of months I was asking questions that others didn't ask until 6 to 9 months down the road.

    Good thread to initiate Sherlock

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://91347]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (6)
As of 2014-04-20 10:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls