Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

January 24th, 2010 at 7:20 pm

Proofs of Concept are evil. Get away from them!!!

with 4 comments

They are evil!!

It always comes the time in almost every project when some difficult task needs to be performed and so the team will ask themselves: “How are we going to implement it?” is usually at this stage, after several meetings, brainstorming and debates, that an approach is decided, and a proof of concept is arranged… And that’s when the team fails in realizing that they are about to waste their time.

Proofs of concept look ideal on paper; they are supposed to be an excellent mechanism to validate the approach that is about to be taken in the project, but the reality is that they are not, and that’s what I would like to talk about in this article.

Why proofs of concept are bad.

  1. They don’t tell you if you are about to do the right thing, they only tell you if that specific approach is feasible. Most of the times, is not about if what we are proving is valid or not, is about how much overhead there is in maintain or integrate what we are proving, but proofs of concept are usually very limited telling us what these boundaries are.
  2. People who sponsor a proof of concept get emotionally attached and loose their objectivity. After a proof of concept, a decision needs to be taken, but the people who sponsored the proof of concept, because their ego, will have their objectivity affected and will push to have the proof of concept accepted no matter its output.
  3. Proofs of concepts tend to be very specific and focused; they leave outside of the picture many critical areas that need to be proved. For instance, if proving a reporting tool: The proof of concept may be focused in generating some particular type of report, but it may leave outside of the picture some other areas, as the integration of the reporting tool with the application being developed or how customizable the generated reports are.
  4. Designing a good proof of concept requires a full understanding of the domain. To design a good proof of concept, is important to identify upfront what are the different risk areas, so they can be proved, but for most situations that’s impossible, so is very likely that after adopting some approach the team is going to hit some unexpected limitations on the approach.
  5. Proofs of concept distract the team from the main goal and make them switch to an R&D mentality. Teams doing proofs of concept usually switch to a R&D mentality, with a R&D mentality is very easy to focus in gold platting the application.

All this disadvantages may translate in the following four real major issues in your project.

  1. Waste of time
  2. Technical debt
  3. Fail to deliver all the requirements.
  4. Integration issues.

How to avoid Proofs of concept

These are my 5 key practices for avoiding proof of concepts

  1. Find the next baby step. Usually when a proof of concept is kicked off is because the team fails to split the biggest problem into smaller issues. Tackling the smaller issues one at a time is easier and is likely to produce a more integrated solution.
  2. Keep it simple. Is usual to find proofs of concept to validate at the start of the project how the latest technologies, frameworks… would fit in the application, but I wouldn’t even consider them, I like to start simple, and if necessary add them as we go. I think adding them upfront can become a huge risk factor to the team as they introduce new learning, complexity and integration factors into the project.
  3. Just do it. When a team is stuck, I find that the best remedy is just find what the next baby step is and implement it.
  4. Work several options in parallel. Sometimes is just impossible to determine in what direction the next baby step should be, for these occasions just work in parallel all the different solutions. The overhead of working in parallel is paid back early in the project because it will be very clear what solution is the most adequate.
  5. Delay decision for as late as possible. The general rule of thumb for the whole article can be resumed with the lean principle “Delay your decisions for as late as possible”, find baby steps, work on parallel… but don’t commit to an approach that may cause your project to fail.

4 Responses to 'Proofs of Concept are evil. Get away from them!!!'

Subscribe to comments with RSS or TrackBack to 'Proofs of Concept are evil. Get away from them!!!'.

  1. Hello Alberto,
    If you need to test a framework or library, what do you recommend instead? Keep it simple and reinvent the wheel for every technological need?

    Professional people do prototypes and POC to validate a technology choice. That will save time in the medium term and will prevent problems with external library.

    If you prefer rush, you do as you want but POC are good for professionnal projects.

    Best regards.

    Cyril

    25 Jan 10 at 4:11 am

  2. Hi Cyril,

    What I’m trying to say in this article is that, if you need a framework, just use it, and if you can’t pick one, because you are not sure, I would suggest to start development with a couple of options.

    Expending x days trying to prove which one is going to fit better in your application, is, in my opinion, and for the reasons listed in this article, a waste of time, basically because is impossible to figure that out until you actually use it for your application.

    Anyway, I understand what your point is, if in your experience you have found that proofs of concepts have drove you to the right directions, then just keep doing it, I’m just writing this article from my own experience.

    In any case, thanks for you comment.

    Alberto Gutierrez

    25 Jan 10 at 5:14 am

  3. Hi Alberto,

    I’m not sure I totally understand your definition of a proof of concept. For example, I needed to create a widget that could be easily included on any webpage. I’ve created them before using an iframe but I wanted to move forward with a full javascript on demand implementation.

    As it was, I just went ahead and did it with the javascript with the knowledge that it might not work and I’d have to fall back to the iframe approach. Would that be considered a proof of concept or would it fall in the just do it category?

    Hudson

    27 Jan 10 at 1:58 pm

  4. Hi Hudson!

    What you describe is absolutely what I meant in this article, it will fall in the “Just do it” category… To me expend x days proving if something maybe right or wrong is a waste of time as you woud only find out once that you actualy try it for real.

    Thanks for your comment!!!

    Alberto Gutierrez

    27 Jan 10 at 2:49 pm

Leave a Reply