Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

At last team meeting I heard from managers that we need to create proof of concept (POC) before main prototype and integrate this concept with the main system for proving a new feature.

  1. Could you explain me the main features or this method?

  2. Do you use the POC in your projects before implementation?

  3. What is the main advantages and disadvantages of this method?

share|improve this question
1  
I don't recall having 'team meetings' when I was given homework. –  Garry Jul 2 '12 at 9:33
1  
semantically these terms proof of concept and prototype are so close together in the software industry that for all practical purposes they mean the same thing. –  Jarrod Roberson Jul 2 '12 at 13:23
    
What is a "main" prototype? –  JeffO Jul 2 '12 at 14:01
    
proof-of-concept mean you make the components work together. Prototype mean you actually have some of the functionality you want from the final product –  user1249 Jul 2 '12 at 18:30
2  
I've built 2 proofs of concepts in my career. They are both still in production. –  Wyatt Barnett Jul 2 '12 at 18:45
add comment

3 Answers

up vote 9 down vote accepted

The terms "proof of concept" and "prototype" are so similar that you should probably ask your managers what each of them means in the context of your company.

I've worked in a few places where proofs-of-concept, prototypes or whatever you want to call them are used, for different reasons:

  • to understand a technical risk, such as the performance of a product or its ability to integrate with external systems.
  • to evaluate different technology options for later selection e.g. choice of web server or database
  • to demonstrate how the product might work with a view to informing UX, design and business decisions over its features.

Notice that in each case there's a clear done-ness to the work: you have useful performance numbers. You have a justified choice of database technology. You have a usable prototype. That means that work on the prototypes or proofs-of-concept is bounded. It's usually also time-boxed (matching with the concept of a research spike in iterative development) so you agree what the problem is you're trying to solve and how long you've got to explore the solution.

Typically the PoC is "one to throw away"; it's built such that you can get something working quickly on your box to show that it can be done but it's not actually going to be part of the finished product. You might use the code to guide your production implementation[*], or you might just take what you learned and build it again from scratch.

[*] Where I'm using the proof of concept to learn about an API, I sometimes take the things I learn from the PoC and write them as unit tests. Those tests can be part of the real product's test suite without copying PoC code into production.

Advantages:

  • you quickly learn whether what you want to do is achievable
  • you quickly learn whether what you want to do is desirable

Disadvantages:

  • it can be hard to argue that what you're doing adds value when it isn't going into production
  • seeing the PoC functioning, even if it's smoke and mirrors, can lead to a false illusion of progress when you demo it to other people.
share|improve this answer
2  
should also add that there should be a clear understanding of the scope of the POC - i.e. there is a clear line between it and a fully fledged implementation... –  Nim Jul 2 '12 at 12:30
    
@Nim great point, I'll incorporate that into my answer. Thanks! :) –  user4051 Jul 2 '12 at 12:43
    
We tend to use them pretty interchangeably. Either tend to be to prove feasibility...though we tend to use PoC more for implementation stuff and prototype for more customer facing stuff. Entirely depends on the company like you said. Last company didn't understand the concept of either and always wanted to make prototypes production :'(. –  Rig Jul 2 '12 at 12:45
1  
@Rig that's why I linked to the other question. The problem of prototypes going into production is partly one that we need to do better at arguing against. –  user4051 Jul 2 '12 at 12:47
    
@GrahamLee Ours was exceptionally bad...still have nightmares. Probably why I spent more time on the phone than developing. –  Rig Jul 2 '12 at 13:54
show 5 more comments

Where I work, we typically use proofs of concept to verify that a given technology can actually be used to perform a particular task (e.g., we can write a connector that permits us to write callback routines in a DSL). PoCs are always disposable and are almost never used as a basis for a prototype. Prototypes are more formal and typically either implement only one of the functions of the complete system or are more of a shell with a mostly-complete UI and stubbed-out functionality that simply logs operations. Prototypes follow coding and documentation standards, and often evolve into the final application, whereas PoCs are typically hacks or cut-n-paste mashups.

share|improve this answer
add comment

In the softwaredevelopment company where i work for, we use the term "prototype" for "Gui-prototypes" where the screen-maskes are painted so the customer will see, how his app might look like.

Instead of the term "technical prototype" or "prove of concept" we have "spikes" that show that some technical interop is possible (i.e. that an android app can talk to a sap-system")

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.