The following is a true story about an art teacher who decided to experiment with his grading system. It had an interesting side-effect relating to the dilemma of quality versus quantity. David Bayles and Ted Orland document the story in their book, “Art and Fear: Observations on the Perils (And Rewards) of Art making “
“The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pounds of pots rated an “A,” forty pounds a “B,” and so on. Those being graded on “quality,” however, needed to produce only one pot—albeit a perfect one—to get an “A.” Well, come grading time and a curious fact emerged: the works of the highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes—the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay”
The above story certainly rings true of my experiences in OSS integration. I remember working deep into the night for days at a time to get naming conventions and data models working correctly or creating data parsing / cleansing / loading scripts. Or evaluating data by the ream to pick out the specific attributes that were key to delivering a functional auto-discovery solution. Process measurement and refinement is another that springs to mind. There is no doubt that these trials and errors produced more useable solutions for those customers.
What aspects of your OctopOSS have taken countless attempts before the quality has begun to appear?