POC ≈ Piece of Crap
Wind tunnel model of an F1 car

POC ≈ Piece of Crap

Some context for you - I’ve just joined a team that’s in the midst of productionising a Proof of Concept (POC).

*groan*

In fact, *goan x2* because there’s two things that immediately set me on edge with this situation (and I imagine a fair few of you who are reading this will have the same reaction). Thankfully it is an enjoyable one to try and tackle!

  1. You can’t “productionise” something. It’s silly word and one that is, as far as I’m aware, not actually a real one. That tells you something in itself.
  2. “Productionise” is always used in conjunction with a prototype or a Proof of Concept. These things are, by their very definition, not something that should go into production.
proof of concept
noun
evidence, typically deriving from an experiment or pilot project, which demonstrates that a design concept, business proposal, etc. is feasible.

POC’s exist purely to test something out to see if it’s viable. Now I know you could argue that every feature you build should, technically, be a POC because you’re testing a theory out when building a new piece of functionality. This is what is known as the Minimum Viable Product and there’s a very big difference between that and a POC...or there should be. MVP’s are the minimum amount of production quality work that you need to do in order to test a theory that a certain feature will have a certain impact.

A POC on the other hand, that’s usually used to test out how a new piece of technology may work (could be a new piece of hardware, a new library or a new framework) and if it will be suitable.

Build a Piece of Crap

So then, back to the team I’ve joined and their quest to “Productionise” their Proof of Concept. They’ve fallen into the common trap of building too realistic a Proof of Concept that people think is just a short step to get it into “Production”, regardless of the protestations of the team - they’ve seen it “working” so the devs must be sandbagging.

Specifically these guys built something that looked like it might do in the live app and then, crucially, made some changes to make it look even more production-like based on some feedback and requests from when it was demo’d. This is clearly wasted effort, but also it goes further to solidifying people's expectations that the thing they’ve just seen is close to being ready to be shipped.

So here’s my suggestion (okay...not really my suggestion - it’s a widely held view by people who understand what a POC is for - here’s my way of communicating that view) - build a piece of crap that looks nothing like it’s going to in Production and is clearly held together with sticky tape, lolly sticks and, possibly, prayers (optional). Don’t spend time making it pretty, don’t fix the performance (again, it’s wasted effort - all you’re trying to do with a POC is test if something is even possible, not to make it good enough for Production) and don’t make it work properly.

Got a text field? Sure, let a user enter a value if you want, but hardcode what is actually sent through so that no one using it gets the impression that anything is actually hooked up and working. It’s hard to mistake something that looks like it will fall apart at any minute/require a lot of work to do properly as something that could imminently be shipped.

Analogy Time

Imagine you’ve taken your car into the garage because there’s a problem with the engine.

Let’s say the mechanic has had it for a week and they think they’ve worked it out and have invited you to come and check it out.

If you got there and saw the engine removed from your car, sitting on a bench with the fuel being hand pumped into it, but apparently running fine….you’d appreciate that there was a fair chunk of work left before you’d get your working car back.

Now let's say you went to the garage and saw your engine being demoed to you working, still being hand pumped with fuel but this time the engine is actually IN the engine bay. It’s not connected up to the gearbox or anything but from your perspective the engine is in the car and it’s working - you don’t know any better because you don’t have the knowledge or the insight to understand that an engine can be in the engine bay but still require a lot of work to actually get it integrated and working as a whole.

This is what you’re doing when you’re demoing a POC that looks like it could be in Production. People will not understand that it’s all smoke and mirrors because they don’t have the insight or knowledge of what has been done to make it look like that - they just see something that looks like it should and it looks like it’s working.


Paul Chaplin

Technology Leadership @TUI ?? | Analytics & AI | Global Communication Services | Strategy & People ??

7 年

Gary Williams the new one... POC

回复

"MVP’s are the minimum amount of production quality work that you need to do in order to test a theory that a certain feature will have a certain impact." Although I agree with your post, my understanding of MVP differs from yours. At the places I've worked at, MVP is the acronym that defines the most minimal form of the product destined to market. There may be 100 features defined but the business may feel to ship the product they can release it with only 30 the 100 features, growing the number as it gains traction. POC on the other hand should be standalone, minimal, and quick.

回复
Chris Davey

Value delivery coach

7 年

Depending on your POC criteria you can also demonstrate all of the POC functionality but very separately. Further re-enforcing that the POC is not a finished product just a collection of experimental proofs. We have proved that widget A, B and C work on their own there is no reason to think they won't work together. However putting them together will take considerable time and effort. Admittedly much easier when you are working further away from the UI.

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了