Code written by a novice programmer is full of hard-coding. All sorts of values are indiscriminately thrown about inside the code, which makes it the program much more difficult to maintain. Any time you want to change the behavior of the software, you have to change the source code and run the application again. This is a well-known problem in the software field and one that you will frequently come across in your work. So I will not elaborate on that.
The opposite of hard-coding is soft-coding, which means that you provide mechanisms to users (usually at the administrative level) to configure the system without having to change the application. The mechanisms are dialog boxes for application options, configuration or property files and special database tables. The mechanisms increase in complexity based on the average technical level of the end user. That is why you will see dialog boxes for configuring a consumer product like Microsoft Word while open-source server software is more likely to have configuration files.
Soft-coding is generally a good thing. It provides end users more power in adapting the product to their special needs. The software development company benefits by not having to create custom versions of the product or change functionality repeatedly based on user feedback. The company can provide the generalized functionality and provide guidance, training or documentation to end users to customize the product for their demands.
So if hard-coding is bad and soft-coding is good, what is the problem? Well, when the soft-coding in the product outweighs the customization needs of the end users, it negatively affects software development activities in the form of additional (and perhaps overwhelming) complexity, thus increasing the overall effort and expense incurred in the project.
Why would this happen?
- Users do not bother to customize the software to their needs, even if it is more helpful to them. If you look at the computers of most users, they hardly change any of the default settings, except perhaps the desktop wallpaper. In several years, I have only seen a handful of non-technical users ever changing any application settings (other than graphical look-and-feel) by themselves. In all other cases, they must be trained and given checklists if they have to do some operation in a system.
- Even if you teach users how to customize the software, most of them still think it is complex and insist on default behavior being the correct one. This is true even if the customization is very simple in absolute terms. You can tell someone, “Click Tools > Options, select the second option instead of the first and hit Save.” And they still think it is really complex. I have seen users become literally scared and worried because it is yet another thing for them to worry about remembering.
- The first two points relate to individual users, but you could possibly argue that different customers (each with multiple users) may have a few technical people who may customize the software. Or that some important users may be technically savvy enough to do that. But even here, you may be mistaken, because even technical people may not be interested in customizing your software because doing so may not have sufficient value to them.
Ironically, the better your software is out of the box, the less customization it needs and the less customization that will be used. If most users get their tasks done through the primary interface of the software, they will be less inclined to learn about the software to customize it. In that sense, it almost seems that the more you know your users, the less you need to do soft-coding in your application because you are more confident that this is exactly what the user needs.
The primary overhead in unnecessary soft-coding is an up-front cost in analysis and design. You are designing for sections of the software that you wrongly think the users may want to change themselves. Such design is not trivial. You will have to design additional screens and/or data storage for such elements.
One of the biggest dangers in providing configuration options to the user is error-handling. Let us consider a program that only manipulates data and does not provide any customization. Such a program can tightly control the data going into the system and being displayed. You also clearly know the code that is being executed and can easily find the bugs in the code.
When you allow customization, the code itself is dynamic because it is based on user input (albeit from administrative users). So now you have to examine the informational data, customization data and the program itself to locate any errors. If the customization data is in a readable format (like configuration file or database table) to which the administrative user has access, you will encounter activities that you really didn’t bargain for. The most egregious instance is the person who wants to “experiment” with the feature and breaks the product.
Upgrades to the system also become complicated. Any behavioral change in the software must accommodate for past customized behaviors of the product by users. In simple terms, you cannot lose the customization settings of the users in addition to the data that you are storing. Even though they may be able to restore their custom options manually, it will cause user anger and frustration.
Soft-coding can sometimes degenerate into trying to create the “ultimate software framework” where everything can be customized and nothing is hard-coded. This sort of thing can be fun as an academic exercise, but you find yourself chasing an ever-elusive dream. Also, much time is lost in attempting this that you sometimes cannot take advantage of newer technologies and tools in the market.
At the beginning of this essay, I mentioned that soft coding is a good thing. The reason for writing the rest of the essay bashing the concept is simply that soft coding can be taken to extremes to the detriment of the business needs of the project.
As always, the answer lies in what your users truly need. Talk to them and understand them. But don’t just rely on their words. In fact, many times I have seen users request customization only to never use it or request the programmers to do it for them – which they might as well have done in the code. Above all, don’t rely on customization to save your software if it doesn’t meet the needs of your users.