There are many times when a proof of concept (POC) is required for either a project or a body of research.  Often these are used to demonstrate an idea to examine if it is suitable and the POC may never become a fully fledged product.  There are some key differences when it comes to POC vs production (or release ready) code and some of these are covered here - this is certainly not exhaustive.

Breaking the rules

Developers will often have to comply with a coding manual of style and these can differ between establishments.  A POC is often a “quick and dirty” demonstration of an idea, so compliance with styles may be ignored.  If the developer is using an Integrated Development Environment (IDE) this might automatically apply the style (line spacing, indentation etc.) but this isn’t guaranteed.

Some Software Development Kits (SDK) and standards also set rules, a good example being Android apps.  In Android app development it is not permitted to perform network operations on the main thread in order to avoid a non-responsive user interface (UI).  This can be bypassed and while that may be appropriate for a POC it would provide an incredibly poor user experience in a full product.

Branding is another set of rules a developer may need to comply with, with marketing departments keen to ensure a uniform look for clients and for internal staff.  POCs can be very bland examples, with the marketing team only getting involved once the project has been approved.

If breaking the rules, it’s important to ensure they’re adhered to when moving from POC to production.

Documentation

This is problematic at the best of times, with many developers finding the process of writing documentation a bore and a distraction from “the real work”.  Nonetheless, good documentation is essential to the ongoing maintenance of a product.  Not only will it be a useful tool for the main developer, to jog their memory, but it will ensure any newcomers to the team can develop with relative ease.  Many IDEs have plugins to generate documentation based on comments (that’s assuming the developer bothered to add any).

When it comes to a POC, documentation is less important.  Firstly, the POC will not be as large as the full product and, secondly, the POC may never become a full product anyway.  Companies are reluctant to direct developers to write full documentation for non-production systems - it’s simply not economical to do so - and even less likely to require it for a proof of concept that’ll be re-written long before the code enters production usage.

In-code comments and output

Comments are the lesser of two evils here, as they are rarely seen by end users.  A POC may have very few comments (see breaking the rules) as the code is often very simplified to show only the essence of an idea.  Conversely, a full product should have comments wherever needed to aid the developers, saving time.  That said, it’s still worth trying to avoid some comments in POCs, in case that code becomes part of the full product:

// TODO - Bob: Uncomment the line above when all is gravy
// TODO - Alice: What on Earth does that mean Bob?!

Output is the real risk, and I’ve seen plenty of occasions where developer frustrations (or developer jokes) have ended up exposed to users, both in my code and other people’s.  This particular risk is common to both POCs and production software and my advice is simple - don’t swear or be silly in your code!  That said, a system that I and my coding partner wrote still says "forage, mine, make crystals out of belly button fluff".  Fortunately that system is used in quite a relaxed environment (for a LARP system) and the staff find that humorous (although most have never noticed).

A POC is very useful for the early stages in the development life cycle.  They can save months of code by proving if an idea is valid so they’re worth doing.  Keep in mind the differences and use best practice wherever possible.  Happy developing!

Banner image from OpenClipart, by dear_theophilus.