Feature Creep

One of Cain's Laws™ says "To the extent that the budget will allow, put the complicated parts in software rather than hardware" [1].  Recently I've been working on what is now the annual reprogramming of The World's Most Sophisticated Whole-House Fan Controller™.  While taking care of that chore, I found myself thinking about the flip side of the Law, and one of the larger risks associated with systems implemented mostly in software: feature creep.

The fan controller has been a good platform for feature creep.  There are no physical controls per se, only a 320-by-240 pixel graphic display with a simple resistive touch screen.  Every single part of the actual user input controls is defined in the software running on the microcontroller.  Over the two-year life of the controller, there have been at least five different styles of UI used: little dynamically labeled virtual buttons, big virtual buttons, a virtual slider, a virtual keypad (shown to the left), and a virtual five-way keypad [2].

The complexity of the UIs and software behind them have varied considerably.  At the low end of the scale was the interface with three big buttons: off, low, and high.  At the other end is what the code comments call the "target temperature" mode: the user specifies a target temperature they'd like to reach using the ten-key keypad and the software decides what speed to run the fan and for how long [3].  Last summer the target temperature mode was the one used most frequently.  At least I think it was -- I haven't taken the obvious step of having the controller count the number of times each interface is used to start the fan.  My usability friends would be disappointed with me if they knew I wasn't measuring things.

If I ever redesign the controller guts, one of the things I would add is something that can make noise.  The feedback of an audible click when a virtual button gets pressed would be helpful.  As it turns out, it wouldn't really cost any more, or take up any more board space, to have a component that produces tones rather than just a click.  Of course, that would open up a whole new range of questions.  How many kinds of noise should the controller make?  Should there be a menu of noises from which the user can choose?  How loud should the noises be?  How complicated should the noises be?  The microcontroller doesn't have enough memory to play back sampled audio, but has plenty to store a pitch-plus-duration definition of several little tunes.  Are there any conceivable circumstances under which having a fan controller render part of "Blue Suede Shoes" is useful?  Should there be a part of the interface to allow the user to enter their own pitch-plus-duration tunes?  Is there a market for selling (probably copyright violating) tune definitions to be keyed in?

One of the existing capabilities of the controller that I've never taken real advantage of is the radio receiver that I built into it.  The idea was that the controller would be able to receive messages from a remote control so that it wasn't necessary to climb the stairs [4].  The man who originally installed our whole-house fan says that would be popular with some of his elderly clients.  The only remote I've built is a little breadboard rig that sends simple messages.  But with even a simple display, and a few more buttons... well, the wireless protocol I'm using allows up to 27 bytes per message, which is enough to send complicated instructions.  Like, say, "Play 'Blue Suede Shoes'".  But that's a project for next year's reprogramming exercise.


[1] This Law grew out of a 1980s Bellcore project where I was building the physical layer for the world's first ISDN test set.  The applied research people had been working on a three-board all-hardware implementation of the physical layer for two years.  I was not popular with them when I convinced my management to let me build a software-based version using one of the new (and expensive) single-chip signal processors from TI instead.  The true value of the Law became obvious when we prepared to go into the field to test three switch manufacturers' products.  Each of the three implemented a different incorrect version of the physical layer link activation protocol.  With relatively modest changes in the software that ran on my board, the test set could interface with all three of those incorrect implementations.  The applied research boards wouldn't bring up the link for any of the three.

[2] One of those widgets with up, down, left, and right arrow keys, plus a button in the middle.  I've always thought there ought to be a spiffy name for such an input widget, but "five-way keypad" is all I've ever seen. 

[3] In both of these cases there was/is a fail-safe in the form of a hidden timer that will shut the fan off after twelve hours no matter what the temperature is.  One of the design principles has been that the controller should never run the fan forever.

[4] Assuming that the windows upstairs are already open, or that having the fan draw strictly from downstairs windows is desired.  Running a fan with a three-quarter horsepower motor in a house with no open windows can lead to some... interesting results as air is drawn through the remaining available paths.  One of the better stories I have heard is about pulling large volumes of air down the chimney, and what the soot and ashes did to the light-colored carpet.