Proof of concepts are often underrated, overlooked, and an incredibly valuable form of preparation. Proofs are a way to test and idea and move on. They honestly should not take long at all. And when your done, you should have better estimates and a better final product.
Underrated:
Most managers are looking for ways to cut time down for the end product, so spending time on throw-away-code (and it is throw-away-code), is a waste of time and money.
Overlooked:
Most developers want to just dive in to the code, and get their project done.
Incredibly Valuable:
Have you ever finished a project and thought, "If I had this to do over, I would have done it all the same!" BAH! If you even make it to the end of a project, your typically thinking, "This is f****d up. CHANGE ALL THE THINGS!"
Rules of a Proof of Concept: (according to Dan)
1) Determine a part of your project you have not built before.
2) Produce a project with no code.
3) Race through it. - Yes, you read that right.
4) See how it feels.
5) Review.
6) Throw it away.
7) Repeat - Maybe.
So now I'll go over the parts in a little more detail.
1) Determine:
Its easy to think you understand it all, since you understand some of the base coding principals, but in truth, you are typically most excited about project ideas that introduce a challenge to you, something that involves learning at the same time as maintaining a comfort zone. So another way you could look at this, is what are the most interesting parts? That is probably a good sign that there is a bit of a challenge, something you want to try. Try a proof first.
2) Produce:
Make a test project that does only the bare minimum to test the concept. If it is adding to a larger, existing project, that's fine, but just build it in a copy.
3) Race:
You don't need pretty code, you don't need the best style. You need something quick to prove the concept, and nothing else. How fast can it be testable, playable, pr
4) Feel:
While there are obvious technical things, does this feel good? Did it feel complicated? Now that you can try it, does it seem like it could be better? This is the point to do a gut check and measure the parts that have no metrics. Are you happy with the way it works?
5) Review:
From a technical stand point, what are some of the key take away's? Were there any changes to your original plan? What information is needed for the architecture? What communications, management and other methods are important to keep in mind? Does it work with your existing plans for architecture?
6) Trash it:
Do not reuse this. The practice is sloppy to give you a chance to try it. This doesn't mean delete it. You might want it to look back to see how you handled something.
7) Repeat:
If it didn't work the way you wanted, don't just consider how you would do it differently. Repeat this process with the new idea. What happens if you make it through the new idea, in the real project, but find it has the same issues or worse? And now its mixed in with your real code.
But if you are happy with the results, then you are good to go.
