I would like to offer a concrete example of simplifying the programming of a product.  Years ago I was privileged to be given the opportunity to realize the programming and design of a home automation controller.  This was the DHC Toscana home automation controller, still being manufactured by Leviton Mfg. Co..  When we first sat down with management, marketing, sales and all the other interested entities at that company I was literally buried in the number of features on this product.  One of the other senior engineers and software guru's there, Dr. Michael Ostrovsky, helped me along and gave me a simple suggestion that cut my project in half!

To understand his suggestion I have to give you a brief technical description of the product.  As you can see from the picture the device has a number of buttons and user interface elements to control lights, fan's, switches and other electrical devices you might find in a home.  It also has a communications interface where it can receive remote commands from other interfaces devices in the home to control the same electrical devices.  Therefore, an engineer might think he had two intertwined overlapping tasks to accomplish.  First would be to control the electrical devices from the unit's front panel and transmit that command to other keypads in the home.  The second task to control those same electrical devices from the commands received over the communications interface.  The contention that could develop from controlling the same devices from several inputs is a classical problem.  Mike suggested a better way.  Mike was old school, Mike was from Russia.  He knew how not to do the same task twice.

 He suggested I split my project into two simpler tasks.  The first was react to one of the front panel switches being pressed and to transmit the appropriate command indicating this on the communications interface.  The second, separate task, was to receive a command over the communications interface and to turn on the light, fan, device or what not.  To complete this scenario I had to let the device receive its' own commands, the one it just sent out!  This way I only had to debug two separate smaller paths, that were more or less independent.