13 ms·

I think this "hard coding-phobia" is a left-over since the 60s, when it took a night to recompile the code. It has since been echoed in the universities for no

by kpil 9y ago

I think this "hard coding-phobia" is a left-over since the 60s, when it took a night to recompile the code. It has since been echoed in the universities for no clear reasons. Today, it's probably not that hard to recompile and redeploy unless it's an embedded application orbiting Mars. It's also most likely that you need to redeploy and rerun all test regardless if you change a source file or a config file. But the warning regarding a "rules engine" or a DSL is worth listening to. Express the rules in code to reduce the complexity and make sure that you can redeploy fast and without any fuzz. The maintenance will be so much easier. Simple flags or values that may change occasionally or needs to be changed really quick should most likely be stored in a database rather than a config file. Note that if changing a config value also requires changing the code, there is little point in maintaining a separate config option in a file. Don't be afraid of hard coding logic - If you don't know the logic yet, help someone find out the requirements rather than building super-flexible rules engines or DSLs.

flukus 9y ago
> Today, it's probably not that hard to recompile and redeploy unless it's an embedded application orbiting Mars. For most companies it still is that hard, the idea of clicking a button and deploying is still alien. This causes some rather elaborate workarounds, at my current company we have an sql procedure that looks up which sql procedures to call for instance. To them it's a life saving feature but to us it's an artifact of an awful deployment system.
- kpil 9y ago
  True. It should not be so hard. The obstacles to a smooth deploy is most often more related to bureaucracy rather than technical implementation. I'd say it's possible to automate almost any application update process, if you spend enough time and effort on it. Our applications also have indirections upon indirections, and the amortised time we have spent on maintaining that mess could easily have funded a one-click deploy and then some...
tannhaeuser 9y ago
While I agree, I think the problem is that coding your little interpreter or grand service framework or what have you is a whole lot more fun than coding business logic. Also, more often than not, business requirements are unclear at the begin of a project, so developers are attempting to anticipate each and everything at the meta-programming level.
- kpil 9y ago
  Indeed. All developers enjoy converting boring and repeatable task into interesting and complex problems. It's the essence of programming in a way...
smoyer 9y ago
You might be able to recompile quickly but if you're waiting 4 weeks for Apple to put your application in its store, there's still a benefit to having external configuration in sane amounts. As the article says, everything in moderation.
marcus_holmes 9y ago
For web servers, everything you say is true. I spent years writing desktop applications, and the config file was part of the whole application bootstrap process. It couldn't connect to the database until it knew where that was, and that entirely depended on the deployment environment. Using environment variables basically meant that bits of the application's config lived in whatever environment system the OS used. It was possible, but massively more painful than shipping a text file with the application. Creating a new executable for each customer install, with the config values hard-coded, was not an option, regardless of how fast it compiled. Keeping a copy of the text config files (in case there was a problem) was easy, but rarely done. Usually we talked the customer through emailing us a copy of their config file if there was a problem. This kind of attitude persists. I still find myself hiving off any config into a separate part of the code base, with the knowledge that at some point I'm going to have to deal with that being serialised from a file. Even if it's a single-deploy web server. I think it's a good habit ;)
cle 9y ago
> Express the rules in code to reduce the complexity and make sure that you can redeploy fast and without any fuzz. The maintenance will be so much easier. Not to mention you get source/change control for free. I push back constantly on junior engineers overzealously config-ifying everything for some hypothetical future use case. Yagni. It's a two way door and is easy to move later. (Of course, this doesn't apply in all domains, particularly when you're shipping full applications to clients and code changes are very difficult to deploy.)

by kpil 9y ago

flukus 9y ago

> Today, it's probably not that hard to recompile and redeploy unless it's an embedded application orbiting Mars. For most companies it still is that hard, the idea of clicking a button and deploying is still alien. This causes some rather elaborate workarounds, at my current company we have an sql procedure that looks up which sql procedures to call for instance. To them it's a life saving feature but to us it's an artifact of an awful deployment system.

kpil 9y ago
True. It should not be so hard. The obstacles to a smooth deploy is most often more related to bureaucracy rather than technical implementation. I'd say it's possible to automate almost any application update process, if you spend enough time and effort on it. Our applications also have indirections upon indirections, and the amortised time we have spent on maintaining that mess could easily have funded a one-click deploy and then some...

tannhaeuser 9y ago

While I agree, I think the problem is that coding your little interpreter or grand service framework or what have you is a whole lot more fun than coding business logic. Also, more often than not, business requirements are unclear at the begin of a project, so developers are attempting to anticipate each and everything at the meta-programming level.

kpil 9y ago
Indeed. All developers enjoy converting boring and repeatable task into interesting and complex problems. It's the essence of programming in a way...

smoyer 9y ago

You might be able to recompile quickly but if you're waiting 4 weeks for Apple to put your application in its store, there's still a benefit to having external configuration in sane amounts. As the article says, everything in moderation.

marcus_holmes 9y ago

For web servers, everything you say is true. I spent years writing desktop applications, and the config file was part of the whole application bootstrap process. It couldn't connect to the database until it knew where that was, and that entirely depended on the deployment environment. Using environment variables basically meant that bits of the application's config lived in whatever environment system the OS used. It was possible, but massively more painful than shipping a text file with the application. Creating a new executable for each customer install, with the config values hard-coded, was not an option, regardless of how fast it compiled. Keeping a copy of the text config files (in case there was a problem) was easy, but rarely done. Usually we talked the customer through emailing us a copy of their config file if there was a problem. This kind of attitude persists. I still find myself hiving off any config into a separate part of the code base, with the knowledge that at some point I'm going to have to deal with that being serialised from a file. Even if it's a single-deploy web server. I think it's a good habit ;)

cle 9y ago

> Express the rules in code to reduce the complexity and make sure that you can redeploy fast and without any fuzz. The maintenance will be so much easier. Not to mention you get source/change control for free. I push back constantly on junior engineers overzealously config-ifying everything for some hypothetical future use case. Yagni. It's a two way door and is easy to move later. (Of course, this doesn't apply in all domains, particularly when you're shipping full applications to clients and code changes are very difficult to deploy.)