Proof of Concept

     In my years of experience, one of the biggest problems I've found is a disconnect between management and programmers.  One that says that both sides really know what their doing.  As soon as a programmer says a timeline looks good, they are telling management that they decisively know everything that needs to be done, how it will all work together, but in truth they do not.  Most don't.

     Most all programmers don't realize they deceive management, but its true.  I'm guilty of it, everyone I know at various companies, including Microsoft does it.  The problem is that we think we've built something like this before, so we know what needs to be done.  While our past experience does give us clues to how things will pan out, when is the last time that a request came down from management to "rebuild" something EXACTLY like what you have done.  The point there, is that all these projects may be like something that previously existed, but they always have some new, often strange, way of doing things.  Some new feature, or method of control.

     The problem that we face, and often blame feature creep entirely for, is once we start building something, we come to a cross roads; either we go back and rebuild part of it to work with some odd portion of the project, or we need to hack a small portion of the project to make it fit into the whole.  The reason this happened, is because we are facing something we were not prepared for.  Despite the fact we had an idea of how it could work, once we are here developing it, it almost always deviates from that original plan, some of it being made up as we go.  If we really had our head wrapped around everything it would take when we submitted a timeline, we wouldn't be surprised by this;  our original architecture would work fine for all this.

     So how can we fix this?  With Proof of Concept!  Why yes, its the magical solution that solves every problem!  ;)  Or not.   Proof of Concepts are the key here, but I want to emphasize that no amount of experience can fully prepare you for the future.  Respect that, remember it and apply it.

     To really understand what is involved in the project, start stepping through the requirements, and existing design.  Create a list starting with the most basic abilities to be used.  Even if you've already know them really well.  Then start adding on the layers.  "Show a text box" > "Limit the amount of character" > "validate they are in a phone number format" > "Check if the number exists in the database" > "geocode the region for the number" etc...  And as you start to look at this list, find anything in it that you have not built before, and go build it.  For instance, Validating a phone number format, when you start considering that, you have to ask yourself what formats are acceptable.  Well, there are many, and other countries.  So, the requirements either need to list what type of phone number's are acceptable, or you need to accept all of them.  That's immediate feed back on the requirements, and if you waited until you hit that point to start asking these questions, you may already have database options limiting against what you need, and other parts of the project that already work with one style of phone numbers.  You wouldn't know this until you actually address it.  and by then, having to go back and change everything leaves a lot more openings for errors to occur.

     So, always outline a list of what approaches you need to use in the project, including how things interact.  This will also help for feature creep.  When someone says, "now I want you to add this", you can break it down, and see if you have any proofs existing to cover it all.  Chances are, that you do not.  And chances are, it might require changes to the architecture or hacks to make it fit.  This makes the things you do much more clear.

    

     Argument, "Management would never let us spend that much time defining something out".  You are possibly correct, but that is only because of the first sentence about the disconnect between management and programmers, followed by the idea that they don't know what they are doing.  (given the paragraphs that followed it would be easy to assume I was leaving management blameless. :) )

     By demonstrating to management that using proofs will make timelines far more accurate before the project even begins, is a huge value.  How many projects have you been on where everything was on time, and under budget?  While a few might get through like that, in general, that is not how it works.  Things get pushed out with bugs, pushed out late, or dropped altogether.  Often a combination of all three.

     Yes, this will take more time up front.  but, as time goes on, and this practice is adhered to, everyone will start gathering more proofs, more practice, and the proof of concept stage will get smaller and smaller.  (depending on what is being requested)  Eventually, the companies become very streamlined, and the proofs help shape exactly what areas the company has real experience in.

     Also, a proof can be used as a reference to say, "it can work like this", or "here is another option to try for it"  Also, proofs help shape additional questions, like "What phone number formats?" and "What security levels?"

     Again, I don't expect every company to just jump up and start acting on this. but do take a serious look.  Watch when projects fail.  Watch when those cross roads reach you.  Once you start keeping track of it, it becomes more clear, and you'll see why this practice, or something similar is absolutely necessary in the real world.