So Simple It's Hard

David Croslin , United States

This is actually the very first time that I remember applying the concepts in my book, Innovate the Future.

I remember I charged them a one day minimum at $150/hour. So, I made $1200 (a whole lot of money in 1985) in 5 minutes and did something all the 'experts' had failed to do because they couldn't see outside the box. It was right then that I realized how people put on blinders and that it is virtually impossible for them to remove those blinders by themselves. Each expert had made the assumption that the problem was something far more complex that a simple coding error.

I am President of Innovate the Future, a consultancy specializing in the evaluation of market trends, defining corporate directions and building product and market innovations. My book, "Innovate the Future" (www.alturl.com/3o6r), has recently been published by Prentice Hall and praised as a seminal work on innovation by senior executives at ATT and other Fortune 500 companies. Previously, I was the Chief Technologist at HP and Chief Product Architect of Verizon. I was a member of the mergers & acquisitions committees at both HP and Verizon and reviewed over two thousand companies. I am a frequent advisor to technology firms, venture capital firms and fund managers.

When I was a young man, I had done a lot of work with Wang Labs and Fortran. This was probably around 1984. Wang contacted me about a problem an eye glass manufacturer was having with their automated bifocal grinding program which was written in Fortran and running on Wang equipment. In some cases, the lenses were being ground incorrectly and the manufacturer couldn't figure out why. Wang had gone to the extreme of bringing in compiler experts from MIT and engineering specialists from other universities and all were unable to resolve the problem. I guess I was their last hope (or maybe their last choice?)!

I told them to scroll through the code and I watched and scanned it as it went by. After five minutes of scanning and Q&A I told them to make one minor change, recompile and retest. The problem was solved! It turned out that they had a variable in two programs with the same name. But, the variable was not defined in a common statement so the value in the grinding subroutine was randomly being set based on what was in memory at the time of the call.

Next Story »