What is it with the every programmer ‘s obsession with providing additional configuration options?

Make a god damned decision please!

Throw one away!

Totally agree with this.

Everything is configuration. then configuration becomes a programming language with no syntax check or any support that catches typos

Would never do that. Probability have to write tests for it

Care to explain more OP?

Make a decision and hard code it. Your software does not need to support every fucking scenario ever devised. Plus now you have multiple paths to test. If it works then stick with that option. Passing shit in from outside just invites everyone to fuck it up. There I said it.

Comes from being "beaten up" when someone sees a 'hard-coded' value and screams to non-technical mgmt that you are purposely making the application/feature impossible to change.

Part 1:

A few moons ago, I 'hard-coded' our cache server name in a C# class (forgot to set up+read from a config file), but it was a CName, so even if Networking swapped physical servers, the code would still work.

One Friday (and my code had been deployed for over a year and networking already swapped physical servers at least once, never an issue), a network admin swapped a server and decided to change the CName, didn't tell anyone, and went home. TL;DR, you can guess what happened.

Nothing really bad happened except slower service response times and errors logged from trying to access the old cache server name. The "Papertrail hard-coded the server name, its all his fault!!!" emails went all the way to the CEOs office.

@PaperTrail

Part 2:

Monday, I was in a meeting room with the monday-morning-quarterbacks all shaming me for 'hard-coding' the value. Another dev, John, was on call, updated the app, deployed, and all fixed within an hour after discovering the issue

Mgr1: "Can't believe you did this! Hard-coding a server name, you know better!"

John: "I would have written the application correctly and read the server name from the config file. That way, a problem like this would never occur"

<smiles and nods>

Me: "You're right, I should have put the value in a config file, but in my defense, Aaron changed the server CName, late on a Friday, and didn't tell anyone. We would have had the same problem if the value was in a config file."

Mgr2: "Aaron is allowed to do that! Its your job to not hard-code values that can change, like server names!"

John: "Exactly, that's why I updated the application and put the server name in a config file. Nothing is hard-coded"

<smiles and nods around the room>

@PaperTrail

Part 3:

Mgr3: "Wait...the problem would have occurred on Friday, right? What would you have done differently to fix the problem?"

John: "Easy, I would update the config file, and re-deployed the application using our deployment pipeline."

<more smiles and nods around the room>

Mgr3: "So the value is hard-coded in a config file instead of a .cs file? You're executing a deployment either way. I don't see a difference."

Mgr1: "We wouldn't have fucking re-deployed the entire application, just the config file!"

Me: "The deployment pipeline deploys everything, you can't pick individual files to deploy. Too risky to guess what files should be deployed. Mgr3 is right."

Mgr1: "No more fucking hard-coding anything! That is the standard from now on! If anyone has a problem, there is the fucking door!!"

<non-tech mgrs all smile as if to say "ha ha..you show em'">

@PaperTrail

Part 4:

John and others spent months..MONTHS going thru code and vilifying any 'hard-coded' strings that could be read from a config file. Devs were so scared of 'hard-coding' values, they ended up adding complex XML data to the config file and/or reading benign values from the database to avoid the wrath of 'hard-coded' strings.

wow. I really don't like that John character in the story

@iceb > "wow. I really don't like that John character in the story"

John is/was a master politician (he's since been fired). He defended his actions to the other devs by saying things like "I'm really sorry, I don't want to do this, I'm only following orders"

Then in the 'remove hard-coded strings' project meetings (yes, they had meetings to go over the hard-coding offenders), John was more-than-happy to throw devs under the bus for minuscule "offenses".

Configuration for different environments is fine. Configuration for different functionality is bullshit.

Just remove the stupidity and no one can tell there used to be more than one way to do it and now you have half the code to maintain.

Everybody wants to grow code and no one wants to make the hard decisions to just get rid of some shit.

Code grows like a fungus until it is completely unmanageable.

I see I have hit a nerve. That is what I am shooting for.

Why would you remove potential users when you've already put in 99.9% of the work required to support their use case, over some insignificant nonsense such as logging too much or in the wrong place, or a timeout slightly longer than what you expect, or following (or not following) symlinks

IMO config options are tradeoffs between the number and value of potential users and the added cost of maintaining both code paths. In a good config option the code paths should mostly overlap, i.e. supporting symlinks is a matter of a single flag in most languages. They are good by default only possibly too expensive.

John in this case had the good idea but the terrible execution.

The point of a config file is only needing at most a restart to change a config, not a redeploy.

And any sysadmin worth their fucking salt can do that not in an hour. In fucking seconds.

Not to mention having that shit in the source code is as bad as checking in your .env secrets...

@CoreFusionX > "John in this case had the good idea but the terrible execution."

The eye-opening event was once John figured out what was going on, instead of updating the code, deploy, and tell everyone "Fixed. Will update everyone on Monday", he wrote about a page "Why you should not 'hard-code' server names in C# files " and cc'd his boss, department mgr, department VP, and eCommerce mgrs (which they forwarded to the CEO).

Yes, I screwed up, but we would have had the same problem even if the value was in config. He would have had to figure out what was going on, update the value, and execute the CI pipeline anyway.

Me: "Wow, they even got CEO-Chuck in the email thread commenting. You couldn't have said the issue is fixed and moved without telling the whole company I screwed up?"

J: "They had to know. It's OK, everyone makes mistakes."

It was then I knew, situation was more about "LOOK AT ME! I FIXED IT! ME! ME! ME! HA HA! PAPERTRAIL SCREWED UP!!"

@PaperTrail I just remembered we hired someone like this at my last job. luckily he left after about a month 😃

Being senior at a new place of course he wants to bring his stuff in to new work.

We had unit test running fine but he wanted his special brand with NUnit. Couldn't figure out how to do it so I helped him set it up.

Five minutes later. an email was sent from my "John" to the entire team including the boss: "Hey guys. I figured out how to use nunit on this project. Here's what you do:..."

At that point i started panicking. There was no way I'd like yo work with this guy.

@iceb > "There was no way I'd like yo work with this guy."

And how would you look if you replied back to everyone ..

"Correction, John didn't do jack. I figured it out and told him. Have a great day."

I've typed that variation many times, paused, took a deep breath, and deleted the email.

In that kind of toxic environment your best strategy is to do nothing.

If you aren’t making mistakes you are not doing anything. Sad consequence of being a human being in a machine world.

I love super customizations. As long as they come with good defaults.