2008-02-12 Software Development

I was born and raised to believe that one should work hard to create the best piece of software that one is capable of. Bugs are not an option. The most efficient algorithm should be chosen, implemented in the most appropriate language and tested thoroughly.

So much for the theory. Obviously, I have a very academical background. BUT: There's a whole new world of opinions about software development out there!

"If it ain't broken, don't fix it." Sure, makes sense. But what if it's broken, only the customers haven't noticed it yet? Every fiber of my being shouts "fix the damn thing!". It's a program. It's broken. You're a programmer. Do something! But there's are a bunch of arguments that imply that fixing that kind of bug is not the best thing to do:
- The customers might have noticed it and found a workaround. Fixing it would change their work flow. It's giving them (and billing them for) something they haven't asked for.
- You might break something else while fixing this. Face it, if you were such a genius, the bug wouldn't be there in the first place.
- There's always something else to do. Something the customers are willing to pay for. Features=win, bugs=loss.
- Sending out patches that contain fixes instead of features is like admitting defeat. Bad for the reputation. Silly, I know, but that's the way most people think.

It takes a while to get used to that philosophy. But to be fair, it keeps bread on the table. Or fish and chips, in this case. I'm not so sure if the academical approach would do the same trick.

***

"There's never enough time to do it right. There's always enough time to do it over."
[Jim Blinn]