But the Water Has Already Fallen

I think the thing I like most about writing software is that it's never done. There are varying levels of completion, sure, but there's always more you can do. I like to write code assuming I'm wrong. I unit test because I assume I've made mistakes or will in the future, but I assume whatever concepts I'm laying down are just wrong and will need to be replaced altogether in the future.

Because of this philosophy, I get confused when someone uses the current state of something or the history of a decision to justify its existence. I know it exists, but it's still wrong.

So this guy from a couple of days ago was still determined to convince people that his three parameters were better than my one parameter. Today he claims much of his code will have to change so he can split the URL up into the three parameters his application wants. This seems a little strange, so I ask why his code needs to do more with this URL than use it to access the data via rsync.

His response: The code is already written that way.

That's wrong on multiple levels. Number one, this is a simple thing sent to a shell. He seriously messed up if this code looks like anything but this:

  rsync $rsync_ops --port-$rsync_port \
      $rsync_user@$rsync_host::$rsync_module \
      $destination

I don't know what language it's in, so maybe it's an snprintf instead. Whatever, same thing. With my recommendation, it'd look like this:

  rsync $rsync_ops $rsync_url $destination

More importantly, though, how is The code is already written that way. remotely relevant to the conversation? No customer has seen it. It's not even shipping to QA as far as I know. I mean, we're still trying to decide how to communicate the details of it. Why are you so blinded by code that hasn't been proven outside of your own environment?

For the next hour or two, I'm getting all of these examples of how much more flexible his way of doing things is. Most of them involve being able to do really poor things like testing connectivity before doing the rsync (it seems that asking for rsync's exit status is too limiting of a diagnostic although most of the examples of things he'd do are invalid in the actual scenarios where he'd do them).

So please, don't be blinded by what's there. The code you wrote today is wrong. Accept that when you save it, when your tests like it, when it's committed and other people build on it. We can't learn if we think we're always right.