Secrets of a Prototype Project

Prototyping is a key ingredient to determining a way forward in a software project. It comes into three categories, loosely coupled with phases of a prototype project. Some of these categories also occur when the project itself isn’t a prototype, but has an element of prototyping to solve sub-problems.

  • Proof of concept experiments
  • Comparison of options
  • Going Pro

Proof of Concept Experiments

The secret to these:

  • Keep it small
  • Focus on one problem at a time
  • Get lots of feedback
  • Use a realistic use case
  • Don’t worry about quality, but do worry about relying on impossibly unsustainable techniques

It’s easy to get lost in the swirling void of possibilities, so a small POC should be focused. It may, and perhaps should, extend its focus to neighbouring problems the more it succeeds at smaller ones. It should be constantly reviewed to ensure it’s on the right track.

There’s very little value in a POC which cannot be applied to real world data/environments/nor coding techniques. For example, we may find a POC that works great on tiny data sets, but won’t scale, or can’t cope with real-life edge cases.

In terms of quality of engineering, quick and dirty is fine, unless the only way EVER will be quick and dirty, in which case this may not be a productionisable approach. c.f. half the monstrosities built on Talend that could have been done much simpler another way.

Comparison of Options

There’s no such thing as a choice of one

It’s very important to consider alternatives while prototyping. The favourite should always be simplcity, but it’s rarely simple to determine which is the lowest chaos solution to a problem.

The team should determine success criteria to help determine any solution that they may prefer. They may also weight those success criteria.

Each candidate solution should be honestly, and as objectively as possible, scored against the success criteria. Each member of the team, even if they have a favourite, should be able to openly correlate each candidate against those criteria, because everyone should be able to agree on the existence of pros and cons of each candidate solution against each criterion.

Finally, the winning candidate can be the one which scores highest, or the one the team prefers, having considered all the data.

It’s possible for a second or third place solution to be selected because the team have an agreed undisclosed weighting for the criteria which only comes out in discussion. This technique isn’t meant to take away instinct completely, though the choice should be rational, nonetheless.

Going Pro

Here “pro” means “production” and most importantly “professional”.

Any possible blockers to real quality software and continuous deployment should be ironed out in the first days of going pro. If it turns out they’re insurmountable, an alternative choice should be made.

Software that can’t be maintained or easily deployed is not worth investing in at this stage. That said, early successful results in product terms – i.e. the prototype proves there’s a product – may allow a technology change at this stage in order to scale out to a real production scale solution.

To go from a bunch of experiments to a viable product:

  • Set low expectations and exceed them
  • Set up an operating rhythm
  • Work incrementally
  • Openly discuss and demonstrate progress to gain realistic feedback
  • Shelve feedback on areas not yet developed
  • Consider keeping the doors open on the future, but don’t lose focus on the present
  • Keep quality high to keep the delivery rate consistent
  • Balance breadth of software with deployment pipeline

It may be desirable to keep early versions entirely on development workstations, with only CI, in order to prove out the combination of technology and focus on test automation to keep it green.

Invariably, we feel we’ve gone to a live environment late, and have been slowed down by a lack of it, but if we go to live too early, we may lose the pressure to build non-deployed testability.

Regular demonstrations of tangible successes that could be applied to subsets of the whole in the real world will buy enough trust to grow the MVP and decide exactly what is an MVP along the way.

Conclusion

Prototyping is about focus, open-mindedness, working incrementally, being realistic, and not forgetting the real-world challenges of the final product and quality software engineering.

Managed well, it can make a lot of people very happy.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s