Keep plugging on!

Imagine a rectangular enclosure. Let's say that it has only one exit. Consider some toy such as a toy car. This toy car, once set in motion, will continue to move unless it hits an obstacle. In this case, obstacle will be hitting any of the four walls. When this toy hits any wall, it tries to turn 30 degrees at a time till it enables itself to move forward. It continues to do so forever. We can assume that it has enough energy. Don't forget that the enclosure has one exit thru which the toy car can pass thru and get out of the enclosure. Now the question is how long the toy car has to move around before it gets out of the enclosure thru the exit.

This problem is really  a nice candidate to write a neat simulation program. There are quite a few variables that determine the outcome. Some that come to mind are 1) length 2)breadth 3) location of the exit 4) speed of toy car 5) starting coordinate of the toy car 6) departure angle and may be few more variables.

Simulating this must be a fairly straight forward exercise. We can imagine the enclosure to be 2 dimension coordinate system. Initialize above mentioned variables to some values and execute a loop whose exit condition is if and when the toy car makes it to the coordinate matching the exit.

But, more importantly, is there something else we can take away from this toy car which turns  by 30 degrees and continues to do so till it enables itself to surge forward?

This is the way successful people plug along. Eventually they succeed. Every time they hit a wall, they turn until they enable themselves to surge forward. Two things to note 1) they remember to recognize that they have hit the wall and turn without delay 2) they do surely persist till they get out.

Point 1 is very important. Many times when we hit a wall, we do not want to admit that we have hit the wall. Especially if it is our pet wall (i.e. close to our heart or ego). We waste so much energy banging against the wall that we destroy ourselves in the pursuit of a pet idea that has proven to be impractical.

Above mistake is so common in software companies especially ones that are managed by old time executives who have come from manufacturing or some other hard engineering background who think software can be engineered the way you build machines or bridges. Of course, certain variety of software can be engineered that way and it should be when requirements are stable, architectures are well understood and do not have many unknowns. But, it is utterly foolish to take that road to deliver cutting edge technologies. Problem is that executives fail to remember "software is like pan cakes. first one is always tossed out.". New product development ideas are not fool proof. More things are unknown than known. So, when you hit the wall in terms of requirement or technology or whatever, always remember to turn 30 degrees and change. Change as in CHANGE. Hitting the first wall may have costed you only a couple of hundred thousand dollars. But, not turning but continuing to bang will flush millions of dollars down the drain. Executives who are not spending from their pockets are more than willing to do because it just bothers their ego to come clear and admit that previous approach was not workable.

I think one of the best examples of this was by famous Coral software when at the height of Java trend  it tried to rewrite its flagship product Draw in Java. After many months they had to abort it as it was not worthwhile. I think the management team deserves to be complimented if they decided to drop the idea and not that they were forced to drop it because market told so in no unclear terms. In another case a Nasdaq listed software company tried to develop some kind of thin client framework and abandoned it only after customers dumped the technology. This was after 4 years and a few millions short. It had such a devastating effect that the that particular RD division was reduced by 60%. Other factors contributed too but precious dollars that were wasted on this could have been spent on something else. Morale problems from internal bickering and frustrations from having to use immature and unstable technology also caused many intangible problems. In this case it was management's utter stupidity and big egos that helped make this happen. Big deal!

In innovative pursuits such as new product development there is no such thing as a mistake or failure. When originally conceived idea does not work, it is just a result from an experiment. The blunder is when people do not learn from it quick enough and continue down the wrong path just because their ego or some other reason. In software, rule of thumb should be, 3 months, <100,000, get usable alpha with minimum feature set. If that is not possible to accomplish, pull the plug at the end of 3 months and choose some other path.

Cheers!

Powered by Qumana