Soft Coding
Over at Worse Than Failure, Alex Papadimoulis has an article on soft coding. Hardcoding is when something is written in the code when it ought to be in a header constant or an external config file. Soft coding is the opposite, when something is put in a config file that really ought to be in the source. For instance, the number of days in a week isn’t likely to change any time soon, so you may as well just use “7” in your code. You might
#define DAYS_PER_WEEK 7 #define WEEKS_PER_YEAR 52 #define LOAN_DURATION DAYS_PER_WEEK * WEEKS_PER_YEAR
to make it clear what you’re calculating, but putting it in an external, user-configurable file is just absurd.
I’m guilty of softcoding, myself. In my experience, it comes from trying to be too generic. Code that’s too specific, too hardcoded, is hard to maintain and extend, so a good programmer will ask himself, “What requirements might change in the future? How should I write this so that when it changes, I can do it without too much pain?” This leads to things like declaring configuration constants at the top of a script, in a Makefile, or in a header file; or having the code read messages from an external file, rather than hardcoding them as strings.
But it’s also easy to overcompensate, and start making everything customizable, or overly generic. So it’s important to remember that at some point you have to actually make the code do something.
My first project for the company I currently work for was a scary example of what can happen when people place too high a premium on configurability. It’s one thing to make sure that things like integer constants can easily be changed. It’s quite another to add branch after branch of functionality, and that’s essentially what our management demanded.
We were working on a next-generation biometric device with a huge number of features and a very vague specification. Every time we had a question of the form, “Should the device do X or Y in these circumstances?” the answer was always, “Make it a configurable option.” Instead of being a relatively sensible system with lots of tunable cut offs, we ended up with a branching monstrosity that the QA team had a nightmare of a time handling. It was trivial to come up with totally irrational combinations of settings, and there were far too many of them for us to hardcode rules that prevent people from choosing them. Of course, the resulting device is almost always used in more or less its default configuration, but we have a database of hundreds of settings that have rarely (if ever) been tried.
The last time management asked for a “make it tunable” option like that, I was tempted to say, “Why don’t we just ship them a C++ compiler and let them write their own custom software? What we’re giving them is going to be just as complex and not quite as flexible.”