Wednesday, April 8, 2009

Fundamental Differences

So at work we had a difference of opinion on how things should work. I have been working on a PHP framework and backend stuff that interfaces with our database. There is a function named getCoordinatesForCity which simply takes $city, $state for parameters, and returns the lat, long of the city and state.

This function is used a few times. The boss wanted to change it to add fuzzy lookups.

It already does "check database 1 if failure check database 2", he wanted to add "if failure after database2 do a fuzzy lookup"

I mentioned that he should just create a new function for this action like getFuzzyCoordinatesForCity (or whatever) simply because the contract the function spells out is "I will get whatever you ask for from the database or return a failed state to you" and is used in that context quite often. where as his change would turn it into a "I will get whatever you ask for, or the closest possible answer, or a failure"
. My attitude is, it might work, but I can't guarantee the operation would be proper in existing implementations. Odds are about 99% likely it will work without issue, but still this is production code, going live later today.. seriously make it so you won't break it.

I said, sure just implement a new function and in his opinion we are increasing the features for existing implementations, and I said no, you are presenting new opportunities for bugs. If we need the new features in the existing implementation we can add your function later, why break stuff now?

I keep getting into fundamental arguments with the boss over stuff like this, trying to make the design work is becomming arduous simply because he would prefer everything to return a result no matter what input you get, in his mind this reduces the number of errors, in my mind this just makes the errors crop up in places you wouldn't expect.

It's like the dutch boy and the dyke, sure he's got ten fingers and as long as the wholes pop up in relatively close proximity, you can plug them, but when it pops 700ft away, or it starts backing up and flooding houses, would you know where the bug came from and why?

What's everyones opinion on this? I mean I get so weary of these silly arguments when implementing a new function is not an arduous task, and it increases the options you have later, when you want fuzzy searching, you can use it, if you don't want fuzzy searching you don't have to use it.

1 comment:

Dank Underlord of the Nuggs said...

[Wishy washy opinion alert]

Returning something/not is one of the many petty programming holy wars.

My personal tack is that, if it's clearly advertised that the function returns nothing in circumstance XYZ, then who cares?

My wishy-washy devil's advocate mentions that sometimes it's just easier if everyone agrees on certain coding standards ahead of time. I prefer the method of gigantic banners that lay down the law/commandment type of things.