Shaneka works on software for an embedded device for a very demanding client. In previous iterations of the software, the client had made their own modifications to the device's code, and demanded they be incorporated. Over the years, more and more of the code came from the client, until the day when the client decided it was too much effort to maintain the ball of mud and just started demanding features.

One specific feature was a new requirement for turning the display on and off. Shaneka attempted to implement the feature, and it didn't work. No matter what she did, once they turned the display off, they simply couldn't turn it back on without restarting the whole system.

She dug into the code, and found the method to enable the display was implemented like this:

/***************************************************************************//**
* @brief  Method, which enables display
*
* @param  true = turn on / false = turn off
* @return None
*******************************************************************************/
void InformationDisplay::Enable(bool state)
{
  displayEnabled = state;
  if (!displayEnabled) {
    enableDisplay(false);
  }
}

The Enable method does a great job at turning off the display, but not so great a job turning it back on, no matter what the comments say. The simple fix would be to just pass the state parameter to enableDisplay directly, but huge swathes of the code depended on this method having the incorrect behavior. Shaneka instead updated the documentation for this method and wrote a new method which behaved correctly.

As you can guess, this is one of the pieces of code which came from the client.

[Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.