Hard coding vs Generic coding : Where to draw the line?

Question

I'm not exactly sure how to word this but I'll try.

Suppose you have some settings in some piece of your program where your 80% sure you won't ever have to modify again. How do you know where to draw the line on changeable code? You know that taking the settings all the way to a user defined XML file is overkill. However, you also know that there is a slight 20% chance that these settings may need to be changed later on so coding it at the place where the rubber meets the road isn't optimal either.

I guess what I'm trying to ask is, how far up the abstraction tree should you allow your program to be easily changeable?

One of many examples is writing the HTML code for a website manually vs having the program automatically generating it. Writing the HTML code directly doesn't take too much time. Writing the a program to automatically generate the HTML code takes much longer.

Answer 1

This is a good question but there is no absolute answer for it:

As noted by Einstein:

Make things as simple as possible but not simpler.

Simplicity is relative. Making the best decision about the amount of abstraction layers in a design is what makes a great architect great. A good architect should always evaluate the particular situation and make the best trade-off. There aren't any silver bullets.

Answer 2

I'll give this a shot, my philosophy is as follows:

1 - Keep a config file & parser class/function that are extremely dumbed down and simple as possible to give you the peace of mind that whenever you need something from it, you can get it without having to instantiate a ridiculously overbloated XML crunching configuration file parser. My config file looks like this:

DBHostname -> XX.XX.XXX.XX
DBUsername -> foomonger
DBName -> fooDb
DBPassword -> xxxxx
ImageUploadsDir -> /uploads/images/
...

I extract what I need from it using either a static helper method (small apps) or a singleton instance (large MVC driven apps) generated by my idiot friend ConfigHelper, who is so dumb, he doesn't know how to generate overhead.

I have this dilemma several times in my average working day: should I put this in config.txt or should I make it a class constant? My answer is I just don't know - until much later on. If it turns out that it needed to be put into the config file, nothing beats a decent IDE with a stable 'Find & Replace In Projects' implementation for changing references.

3 - Config files take the nightmare out of application deployment when development involves a testing server followed by deployment to production - there is no real practical alternative. Different database instances on different machines have different IPs in the world I understand.

One of many examples is writing the HTML code for a website manually vs having the program automatically generating it

This is so true. While we as developers enjoy building machines, we tend to waste a lot of time building machines to build the machine we initially intended to build. While this can be extremely gratifying, from experience I can venture to say that in most situations the more machines you have, the more systems you have to support, the more points of failure, the more hand smacks you get from the business owners - and that is not fun. Furthermore, you will tend to run into situations where the intermediate HTML generator thingie cannot produce the desired output. So what do you do, waste time fixing the bug in the generator thingie, waste time devising a voodoo workaround, or simply hand-write the HTML? It really depends on the particular circumstance, but I prefer the latter.

Was a bit of a rant, but hope it helped answer your question, at least a little.