Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Does Anyone Use Rapid Prototyping?

by Sherlock (Deacon)
on Jun 25, 2001 at 22:31 UTC ( #91380=note: print w/ replies, xml ) Need Help??


in reply to Does Anyone Use Rapid Prototyping?

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.


Comment on Re: Does Anyone Use Rapid Prototyping?
Re: Re: Does Anyone Use Rapid Prototyping?
by bikeNomad (Priest) on Jun 25, 2001 at 23:09 UTC
    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).

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2014-07-10 04:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (199 votes), past polls