Back to List

Proof-Of-Concept: Experiments with Short Feedback Cycles

Joe Vetta Joe Vetta  |  
Mar 03, 2017
 

Value and Risk

Technology is pervasive in life these days, and has been a critical part of business success since the industrial revolution. Not every project, however, is a guaranteed success story. You have to take on risk in the hope of achieving returns. But risk, as they say, is risky. 1 Such scenarios are the perfect chance for a proof-of-concept project.

It's crucial when experimenting to create value as quickly as possible to test the market. A market study or panel might tell you they love an idea, in concept, but consumers can't touch your idea. There must be something concrete, even if imperfect, with which the customer can interact.

A lack of perfect information is a human problem. It affects everyone without mercy. In fact, the hardest part of problem solving is understanding the problem well enough to be sure you're solving the correct problem. Your client and your software are all trying to solve a consumer's problem, but until a version of the solution is in the consumer's hands, there's always a risk that you've solved a non-existent problem, or at the very least a slightly different problem. Let's take a look at a few ways to reduce the risk associated with such experiments by getting to potential value as soon as possible.

None of the ideas below are wholly original, and some of them might be familiar to you already. These are simply ideas I have found valuable while experimenting on various projects.
 

Make It Work

Perhaps the most famous expression of this idea is Kent Beck, who is often attributed with the saying, "Make it work, make it right, make it fast.". [Cunningham 2014] His Mastering Programming post is full of gems, and I share it with every new developer I meet. However, the most memorable discussion of this concept that I have come across is Casey Muratori's post on Compression-oriented programming. [Muratori 2014] Casey's idea goes well beyond the simpler idea of making things work first, and I encourage folks to take a look at it. Even if you disagree, exposing yourself to different or conflicting ideas is another great tool to help when doing more creative and experimental projects.2

Use the above concepts to experiment and get a rough idea working as quickly as possible. However, do not expect someone to pay you to experiment for a week.
 

Seek Feedback

The goal is to turn an experiment into value as quickly as possible in order to mitigate the risk associated with a proof-of-concept project. I recommend trying to get something done and in front of the client in one day.

It's almost impossible to get an answer if you ask someone what they want, but if you show them something, it ignites their creativity. It's either way off base, or they start to see what's possible.

If the feedback requires more work than can be done in one day, that's fine. The important thing is to get something working and get it in front of the client so you can adjust course or confirm that you're on the right path.
 

Overcoming Analysis Paralysis

I first came across these ideas of compression-oriented programming and the "make it work" approach when at a point in my life where analysis paralysis had begun to ensnare me. No projects benefit from that, but a proof-of-concept project would be dead in the water with a design-up-front approach.

Being paralyzed at the beginning of a project comes from too much focus on trying to make it right, and a fear of it ever being "wrong." I'd argue that it's not even possible to make it right up front, especially on an experimental project. What does it even mean to be right? How can you start to make it work, if you don't know what "right" is? The client doesn't even know what "right" is yet, so you can't possibly know. Take a deep breath. Don't let the unknown create stress. Instead, let it free you.

I was recently watching "Abstract: The Art of Design" on Netflix. [Neville 2017] In the first episode, Christoph Neimann is covering his approach to illustration and mentions the Chuck Close quote, "Amateurs look for inspiration; the rest of us just get up and go to work." Christoph says about that:

The one thing I really love about that quote is it relieves you of a lot of pressure. It's not about waiting for hours for a moment when inspiration strikes. It's about showing up and getting started, and then something amazing happens, or it doesn't happen. All that matters is you enable the chance for something to happen.

This approach encourages failures and missteps instead of dwelling on them, and is the only way I know to move beyond a paralyzing fear of your project being just right.
 

Software Craftsmanship This Ain't

Proof-of-concepts are about producing value as quickly as possible and shortening the feedback loop. They are not about refining your TDD practice or tinkering with the latest framework or pattern. However, they do often involve working with some new, never-before-used technology. The key is focused learning. Figure out just enough to make something work and get it in front of the customer. Do not refine (make it right) or optimize (make it fast) until you have client feedback assuring you that you're on the right path.
 

Share your progress

Get feedback from everyone who will listen. It's not just about client feedback on the results, but colleague feedback the implementation as well. Put your efforts in front of your coworkers. In my experience, they're always happy to tell you they think you're wrong. But, be careful of the ones trying to derail you with the latest bells and whistle tech they saw on a blog once. You don't need it yet, and might not ever need it.

The project that inspired this post was launched to experiment with Azure Cognitive Services Bing Speech API, so there was no reconnaissance done with regard to other options. Sharing with a colleague pointed me in the direction of webkitSpeechRecognition, an up and coming specification that's actually crucial to the functioning of the project at this point. That's the kind of new technology worth exploring. Once it started working well, Azure's speech to text results went downhill, and Chrome's implementation of webkitSpeechRecognition saved the day.
 

Think Critically

It's as dangerous to focus too intently on the process surrounding the creation of something new as it is to take these tips as gospel. I encourage you to experiment with some of the ideas presented here on your next project. Seek feedback from client and colleagues alike. But, as with any piece of advice, think about it critically. Look at how these tips might help your project, and fit them in where they do. Take this advice like you would any individual piece of feedback from a friend or co-worker. Most importantly, do not let fear of the imperfect solution imprison you. Enable the chance for something incredible to happen.
 

Footnotes

1: I just made this up. No one says this, but you get the idea.
2: I am careful to say experimental when discussing this approach to software development, because some projects definitely require more rigor, but be sure that I am conflicted about it. There is definitely a relationship between these ideas and agile development processes, especially with regard to the lack of perfect information. As with any tips or advice, do not be afraid to use these tips, but always be mindful of their success or failure in your particular environment.
 

Bibliography

Cunningham, Ward. (November 27, 2014). Make It Work Make It Right Make It Fast. Retrieved from http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
Beck, Kent. (June 7, 2016). Mastering Programming. Retrieved from https://www.facebook.com/notes/kent-beck/mastering-programming/1184427814923414/
Muratori, Casey. (May 28, 2014). Working on The Witness, Part 11. Retrieved from https://mollyrocket.com/casey/stream_0019.html
Neville, Morgan (Director). (2017). [Christoph Neimann: Illustratrion] Abstract: The Art of Design New York, NY: Radical Media Retreived from https://www.netflix.com
 
InsuranceManufacturingHealthcareFinance

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 

Comments
Blog post currently doesn't have any comments.
 Security code

Related Content


Wisconsin Kentico User Group - Using a Publishing Workflow
Jun 26, 2017
Location: Ascedia 161 S. 1st Street, Milwaukee, WI
Blog Article
Microsoft Build 2017 Day 3 Recap
Brandon MartinezBrandon Martinez  |  
May 13, 2017
Day three of Microsoft Build 2017 did not have a keynote, but that doesn’t mean it ends without content to fill the day. Today will be focused on sessions, “The Hub”, and catching some of the Channel 9 Live production happening right here at the conference. Here’s a...
Blog Article
Microsoft Build 2017 Day 2 Recap
Brandon MartinezBrandon Martinez  |  
May 12, 2017
Another beautiful day in Seattle, and another amazing day at Build 2017! Today started off with another fantastic keynote followed by a wide array of awesome sessions. Here’s my recap of today’s events. Keynote Today’s keynote was heavily focused at improvements and...
Blog Article
Microsoft Build 2017 Day 1 Recap
Brandon MartinezBrandon Martinez  |  
May 11, 2017
I’m very excited to be here in Seattle, Washington to attend the Microsoft Build 2017 conference! It’s an honor to be amongst the geekiest of the geeks in the Microsoft community and to be able to absorb a ton of knowledge over the next few days. I’ll be posting daily recaps of...
Blog Article
A Noob’s Journey into Unity
Nathan FellomNathan Fellom  |  
Apr 12, 2017
My first meaningful exposure to Unity came during my senior year of college, after I was asked if I wanted to figure out something fun to do with an Oculus Rift that our Computer Science department had acquired. With absolutely no previous experience in game development, let alone VR development,...