3

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?

Improve this question
5
  • 2
    I don't recall having 'team meetings' when I was given homework.
    – Garry
    Jul 2, 2012 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.
    – user7519
    Jul 2, 2012 at 13:23
  • What is a "main" prototype?
    – JeffO
    Jul 2, 2012 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, 2012 at 18:30
  • 3
    I've built 2 proofs of concepts in my career. They are both still in production.
    – Wyatt Barnett
    Jul 2, 2012 at 18:45

3 Answers 3

Reset to default
11

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.
Improve this answer
10
  • 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, 2012 at 12:30
  • @Nim great point, I'll incorporate that into my answer. Thanks! :)
    – user4051
    Jul 2, 2012 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, 2012 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, 2012 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, 2012 at 13:54
2

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.

Improve this answer
0

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")

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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