In a previous post, I talked about going through your old bag of programming tricks and eliminating those that are either outdated or just no longer practical. This post is along the same lines, as it about getting rid of things you don’t need. Many programmers, myself included, tend to fall into the habit of what I call “conditioned programming”. We program systems the way are used to and we don’t really stop to think about what we’re doing from one system to the next. This often leads to stubbornness or bullheadedness on the part of the programmer when asked why the system works the way it does. We get defensive; after all, it’s not our problem that the customer was sold a product that is way over his head, we just program the commands that are on the factory remote, right? Well, frustration with misleading sales staff aside, it is always in the programmer’s best interest to analyze and evaluate the needs of the customer for each system he or she programs.
Many end users can tell you right away that they never use certain commands for a particular device. This can clear up confusion from the get-go, reduce clutter on the touch panel and ultimately make the system much easier for the customer to operate. You can also make some executive decisions of your own and give the axe to buttons and commands that you’ve been including for years but are seldom used by most of your customers. I just recently had the revelation that the “stop” command could be eliminated from a number of devices for which I had been habitually including it. And if you’re still putting the “angle” button on your DVD pages you should really be taken out back and taught a lesson. Seriously though, if you are an efficient programmer it will be no big deal to add these obscure commands back in if the customer specifically requests them. I personally find it helpful to create an Excel spreadsheet that lists optional device commands and system features so I can fill it out when I meet with a customer (of course, this could be due to the fact that I am an organizational freak who will find any excuse I can to create an Excel spreadsheet).
If you are already following the programming practices I’ve outlined here, I’m sorry you just wasted your time reading this, but if you quite often fall into the habit of “conditioned programming”, I think you will find it helpful to start analyzing your projects a little more. It will make your customers happier, reduce service calls, and keep you in the habit of regularly revisiting your programming practices.
