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.