Proof Of Concept
· From the 2010–2013 blog
I have been struggling a little bit lately with the difference between building a piece of software, and building a proof of concept to be used as a stepping stone towards a piece of software. I'm a little bit gung-ho about building the tool, releasing it, and making it better: 1,2,3 were done. While Steve has been doing a very good job of keeping me focused on the fact that we don't know which of these things we can actually do - and focusing me on the critical subset. So that in an effort to prove that what we are trying to do can actually be done, we don't write a whole pile of shit that needs to be thrown out. The big thing we are getting tied up on right now relates to one of our object models. assuming we can prove the concept it will eventually hold a whole pile of information some of it very well categorized and related to other parts of the tools, and the rest is just a storage place for our customers. We have a lot of concerns over being able to find similarities in the data stored in these models, work with subsets to reduce bandwidth and increase performance, and over how we collect and encourage the entering all of the datagrams that makeup the model. So the current strategy, and I think its probably the right one for now, is to take a functional and storage subset of what we want to be able to do in the end and test our handful of hypothesis. Assuming things change and become more refined through this process we get something better or in the very least an answer out the other side. and then it should really just be an exercise in repetition to add more detail to the models. Here is hoping we are on the right path. and if we can arrive at a proof I may get my wish soon enough - and we will be a big leap closer to a product.