Color to Grayscale (4); a Design Folly:

This morning I weighed 223.4 pounds. Weekends are difficult for me, filled with tempting treats. And I must attend a dinner party on Sunday. Good luck to me...

In the second installment of this story, I mentioned that in order to design our software changes, we had to agonize about whether our CRT displays or the operator workstations were more important in our system. Such distinctions are likely to be meaningless to users of the finished product, but a wrong decision in design can make the software much harder to write and debug. I faced a similar situation – this time, a horror story – 25 years later.

I was working on software for a TV Set Top Box, one of the first commercial ones to support digital TV channels. The base of the software had been written before I arrived. I and my co-developers only needed to make some changes newly requested by the customer and swat a few hundred bugs.

The original software design assumed that the tuning frequency of a channel defined its nature. (Over-the-air and cable channels, which can be digital, still have to be tuned to, in order to receive the channel's video and data.) If the software knew the frequency of a channel, everything else about it could be inferred, such as its channel number and its broadcaster (e.g. ABC or CBS).

There were many, many layers and separate units in the software to handle many necessary functions that might not directly concern the TV viewer. We were under great pressure to finish the software and get paid, and it was with horror that I discovered the major design error: the overall software should have assumed that the Broadcaster, not the channel frequency, was the primary identifier of a channel. I shall explain why, and you won't need to know about software to understand.

HDTV standards allow a channel to specify what channel it “really is”. For example, the analog frequency that we might use to capture channel 2 (whether over the air or by cable), might specify that it is really channel 42, broadcasting Bravo. And a few hours later, the frequency for channel 66 might take over, specifying that now IT is really channel 42, broadcasting Bravo. Shifts like this take place “under the cover” within the software. The viewer will tune to channel 42 at all times to see Bravo.

In our software, what had seemed like a straightforward design became a mess. For example, suppose the viewer wants to record a program on Bravo at midnight. Our original software assumed that it could schedule this request at once, knowing how to tune the STB at midnight to see Bravo. But now, we knew that our software actually had to figure out, at midnight, where Bravo was, before tuning to it. There were hundreds of cases like this.

The software cried out to be redesigned, so that the broadcast channel would be the unique identifier for every tuning action. You can rarely convince anyone that redesign is the fastest way to finish a software project, so instead we patched and patched our logic until, miracle of miracles, it worked.