Best way to write a Proof of Concept (PoC) app?

Question

I am currently working on a project with which I need to program up a bit of a proof of concept app. I have written PoC apps before but they have only been really small and haven't really had lots of layers where as the app I'm writing now has a:

• Form layer - talks to data layer.
• Data layer - talks to Database and Interop layer.
• Interop Layer - talks to a COM object.
• The COM object

What would be the best way to write a program to show that I can get from A to B and the process that is needed, without needing to invest a lot of time in writing the PoC.

I already have the idea in my head on how it should all go together but I'm having a bit of trouble showing my team mates what I mean.

Can anyone recommend any tips/tricks when coding up PoCs? Or would there be a better way to explain what I mean rather then having to write code.

Answer 1

In my experience the best way to get this moving quickly is to code it all as fast as possible in one (or as few as possible) layer, real nasty and heartbreaking. Then once your code-barf is working, start with one of the layers in your list and separate. Repeat until you have the layers you want.

This also has the added benefit of being able to pull up a specific bit and ask your colleagues to pretend it is separated out. If they can do that, you don't have to spend the time actually doing it.

Answer 2

As a proof of concept - I'd take each bit individually and write fake wrappers for the rest. One of the dangers of making prototypes and proofs of concept is that if they are close enough to functional, they tend to end up as an end-product.

Answer 3

It might take a little longer to setup initially, but if you can use a dependency injection/IoC framework right off the bat, it will make it a lot easier to swap out various implementations of things. Spring/Spring.NET have helped me immensely.

Answer 4

I find that drawing pictures and diagrams always helps me get my point across. It also helps me think things through for myself when I run into problems.

You might be able to give your teammates a better understanding of what you're talking about just by showing them some drawings of what you have in mind.

Answer 5

For prototyping proof of concept apps it can sometimes be useful to use programming languages that are well suited to Rapid Application Development.

Python is a good example. You have a huge framework to leverage and create the various layers of abstraction you mentioned in your post while still keeping the proof of concept apps code size to a minimum.

Working applications speak louder than words so if you could whip up a quick prototype for your team to see and play with it helps make the tumblers fall into place for them.

Answer 6

I agree with other responses about getting a prototype up. One way to make sure that your prototype remains as such is to use a language or toolchain that would definitely not be used in the final product, thus forcing it to be rewritten as production-quality. Some ideas I've used:

• Write a pre-scripted network client using shell scripts (netcat and a lot of bash)
• Write a server in Python, Ruby, or another RAD language you're familiar with
• Use a technology that is simpler than your production technology (communicate via static files instead of TCP, or use a very simple RPC mechanism instead of a middleware product)
• Use software with incompatible licensing, so the product cannot be released (GPL is good for this, for anything that actually gets distributed).
• Write a web form as a static HTML page (no styling or anything, ugly as sin)
• If possible replace any remote interactions (database, network) with local object interactions, with handwaving to say "really these two steps would occur separately"

Answer 7

Write as much as possible in a unit test framework in a high-productivity language such as Python.

Python unit testing uses reflection to deduce things are tests and catches the normal asesrtions. All up, it requires very little effort to get started - I've used Python in this manner to work out networking protocols as well as wrap command-line XSLT transformations using Saxon jars.

By playing with the fragments in a test-driven manner, you will keep your PoC app from becoming too entangled and you will set the basis for testing in the future implementation.

Even when you're committed to a particular language for the main app, consider something more lightweight for any helpers, such as simple servers testing a network protocol.

Answer 8

I once did a similar project using Delphi 7 and MIDAS. Implemented the Interop layer (in-process AppServer in my case) as dll files allowing the project to access various data sources (e.g. SQL, Access, Excel and COM objects, etc).