The phrase “common sense” can be very misleading. There have been many occasions in the projects that I have been involved with over the years, where progress called for an approach that either defied the obvious approach or
one that appeared to make no sense.
An example of the first case occurred during a large and complicated project. We were attempting to build a system around a custom design that depended on a critical ASIC. We had spent two years trying to make this design work, going through several iterations of the ASIC in the process. The common knowledge (or desperate hope) was that the next iteration would work.
A small group of us decided that the entire approach was flawed and began putting together
an alternate approach based on off-the-shelf technology. We got the whole thing put together while the rest of the group was discovering that the next ASIC spin still had problems. Our approach got the project moving again.
The second example is illustrated by an 11th-hour debug session. This time, the system was operating correctly, but it was simply too slow. We had to quickly find a way to speed it up by an order of magnitude. There was no time to optimize code, switch to faster hardware, or any
of the other normal, common-sense ways to get there.
The answer was to decouple one of the processes from the rest. Although we had no empirical evidence that it would do the job, I had a feeling that this particular process was significantly slower than the rest of the system. As it turned out, I was correct, and we did very well on the customer demonstration.
The common thread running through these stories is that the correct path may be the one that defies the current definition of
“common sense.” If the common-sense definition is not working, it’s up to us to redefine it.
Larry Mittag,
Stellcom, Inc.
Puzzled by a network processing design issue?
