I have never met a developer who doesn’t like building proof of concepts (POCs). The chance to build something new from scratch to test a theory/process/technology…. I get excited just thinking about it.

There’s something about them that gets your creative juices flowing. Maybe it’s that you don’t have any constraints. Maybe it’s just the thrill of greenfield development. Whatever it is, developers like it.

Part of the appeal of building proof of concepts is the wide variety of use cases. You could build a POC for anything! Whether you want to build something funny, teach somebody about an unfamiliar concept, build an idea for a business, or learn how to use a new technology to solve a problem, you have options.

But be careful with your expectations. Time and time again I’ve seen developers asked to just put their POC into production. Don’t do that!

A proof of concept is just that - a concept. It’s not a production workhorse that adheres to best practices, established patterns, and dev processes. It is a tool to convey an idea in a short amount of time.

Today we’re going to talk about 4 reasons why your POC should never go to PROD.

Image by Alexas_Fotosfrom Pixabay

Production Changes How You Build

One of the nice things about building a POC is that you don’t have normal development constraints on you. You can write in whatever language you want, throw something in quick and dirty, and hardcode the crap out of it.

It doesn’t really matter how you implement as long as you prove your point. It’s literally in the name.

If you went in assuming that this POC was going to be used in production, you’ll code it a little differently. You’ll make different design decisions, intentionally build with different patterns, and be more meticulous with your error handling. Another way to say all this is that you will move slower.

You should spend most of your time building the real thing, not the POC that sells your idea to the product owner.

A proof of concept should convey your idea in as short amount of time possible.

Software isn’t built by a single person. It’s built by a team of diverse thinkers to push creativity and drive innovation. A POC is likely built by a single person. When you want to implement it for real, you need your team there to push the envelope and increase the potential.

Image by Steve Buissinne from Pixabay

It Wasn’t Made For That

Your POC was made to illustrate a point. It’s an idea. It wasn’t made to support a production workload.

When you’re remodeling a house, you sketch out your ideas on a napkin to show your friends, family, and contractors your thoughts. Everyone understands what you want, but you aren’t going to give that scribbly napkin to the construction crew.

No, you’re going to have the contractors draw it out in their CAD software, crunch numbers, find load bearing supports, and formalize the design before starting.

Your proof of concept is the napkin drawing. It served its purpose and showed a clear direction. But you aren’t going to toss that into production as is. It needs to be elaborated, properly designed, broken down into stories, and documented.

If your development team follows agile methodologies, your process would look something like this:

• Create a POC
• Demo it in a sprint review
• Have an analyst come up with the full solution
• Break the solution down into discrete workable stories that add business value
• Work the stories over the course of a couple sprints

Following this process ensures proper measures are taken to build software that is intended for production, offering higher reliability and security.

Proof of Concepts Are Fragile

You did good. You built your POC with the sole purpose of providing a working example for a new concept. It took you almost no time at all, and all the stakeholders loved it. Nice work!

As expected, the product owner asked you to just put it in production because to them, you have a working product.

But you know the truth.

There is no error handling. You built a piece of software that only works for the happy path . As soon as you deviate from the one workflow you coded, it breaks.

There’s a reason you didn’t deviate from your demo script in the sprint review. The moment you click button X instead of button Y the whole thing falls apart. But that is ok! You built what you were supposed to build. The proof of concept showed what it was supposed to show.

While situations like this are definitely considered to be bugs in production, they are not bugs in a proof of concept. Remember, this is a napkin drawing, not a blueprint.

Expect feature gaps, funny bugs, sad path failures, security holes, and a lack of observability. These come later with your real build. But for now, set the expectation that your POC is buggier than a Louisiana swamp on a hot summer day.

Photo by Jude Beck on Unsplash

It’s Always Better The Second Time

Live and learn. Iterate. Practice. Better luck next time.

What do all these phrases have in common?

They imply that your results will be better the more you do something.

Do you think that NFL teams run plays they haven’t practiced in a game? No, they do not. They practice, practice, practice, and practice some more with the expectation that the more they practice, the better they will perform.

The same concept applies when you’re building software. The first time you build something (like your POC) you’re in a discovery phase. You learn the ins and outs, and manage to piece something together.

The second time you build it, you move faster because you’ve learned some of the nuance. You write code that is easier to maintain and more performant. You write better.

You’ll never know less than what you know right now.

Take the POC as a learning experience. Illustrate the idea and learn how to code the concept. Pick up on gotchas. Be prepared to do it again. Get ready to build better software.

Conclusion

A proof of concept is almost always worth the time. Even if the outcome proves you do not want to use something, at least you didn’t spend too much time figuring it out.

POCs give you a chance to experiment with something new and weigh your options for your real build. They ARE NOT your real build. While it may be tempting sometimes to just toss the code into your production app, don’t do it.

Use it as a reference. Use what you learned as a guide to make something better. Tighten up the buttons on what you made. Iterate.

Keep your focus tight and narrow on your POC builds. Get it done as quickly as possible. Spend as much time as you can building the real software with security, retry-ability, fault-tolerance, and proper error handling.

But most importantly, enjoy it! Have fun writing code without constraints!