Floating Point Errors

There’s a silly saying that we use in the IndieZen community: ¬†When you’re trying to swim with a bag of hammers, it’s called a “floating point error”.

(ba dum bum)… and the crowd groans….

Ok, a slightly less corny saying that you’ve probably heard: “When the only tool you use is a hammer, every problem looks like a nail.”

This saying holds true of many developers, experienced and newbies alike. Typically a developer will learn one or more languages and eventually settle on their preferred language / platform as their “hammer”.

Some developers, no matter the number of tools in their tool chest, end up making up their minds that “this one tool” is the best, the ultimate, the last tool to rule them all. Once they’ve reached this point, it’s nearly impossible to get them to go back and re-evaluate the decision.

During the course of our collective careers, we’ve all let our prejudices get in the way of good decision making at one time or another. I’ve seen many examples of this during my career, but I’ll share a couple of stories where this really stands out.

One, the inspiration for my “A Fool Follows a Parrot” article, hated Sun and the (then Sun) license agreement for Java, and thus would never consider Java as a viable language, even in situations where it was actually more appropriate than his preferred language (which just happens to be Python). I wonder about his thoughts about Java now that it’s open source and we have multiple VM choices (and no more Sun, less restrictive licenses).

I worked with this particular developer on a web application. This was prior to Zope, Apache’s mod_python was in early beta stages, but Java for web apps was quite mature. Oh, the agony… luckily the web app was only a very small portion of the project.

Beyond prejudice, another reason developers always reach for their “hammer” is because they consider it a sacred cow.

A sacred cow is any sort of “default” answer used when you’re going through a list of decisions that should be made when solving a problem.

When you approach a problem with a preconceived notion of potential solutions before fully evaluating the problem, you’re likely to come up with a wrong or at least sub-optimal answer.

This problem is terribly difficult to avoid, especially once you’re stuck in a pattern of crunching through a whole lot of projects where each project requires (or at least benefits from) the use of code you’ve previously written. In this case, generally the same language and platform you had been using is the correct choice.

But, do you always consider that it may or may not be the correct choice?

If it’s a sacred cow, you don’t even consider it. If you’re a great developer, one without sacred cows, you think about it first, even if you know the answer is likely to be the same as your initial “default”.

The difference, and path to being great, is the fact that you think about every question without taking the default answer.

We had a great debate about this on LinkedIn. The original poster (OP) of the debate asked “Why doesn’t every game developer use C# to make games?”

He couldn’t understand why someone would want to use C++. As the debate continued, the OP dropped the conversation and another poster continued to argue that he would never use any language other than C# for game development.

He insisted that C# could do everything C++ could do.

It’s actually not a far stretch of the truth. Within a certain context and with certain projects, C# can pretty much do whatever most game developers want, especially if the target platform is a Microsoft platform.

Of course, I know a few other people that would claim Flash can do pretty much anything a game developer needs… especially casual game developers.

The problem with this is that all of these people are correct if you look at it from their viewpoint and if you’re tackling the problems they’re tackling, but if you’re looking at it from a “one size fits all” standpoint, there’s no single language or platform that provides the perfect solution.

There are reasons to use C# and .NET, there are reasons to use ActionScript and Flash, there are reasons to use C++ and the IndieZen frameworks, there are reasons to use Java and GWT.

Each of these languages and platforms have their strengths and weaknesses.

A great developer knows the strengths and weaknesses of many tools, languages, libraries, and platforms. He knows how to wield these tools professionally, accurately, and with skill. He will always choose the right tool for the job. Above all he avoids personal prejudices and sacred cows.

While having a hammer at your disposal is a great thing, not having a wrench, screwdriver, and some duct tape in your toolbox is a “floating point error”. Even if you do have a handful of tools, always reaching for the same sacred cow ultimately nets out to the same error.

Great developers have a variety of tools with which they are experienced using, and they always think carefully about the problem they’re tackling and choose the right one (or two or three… but I’ll save that discussion for another blog).

Leave a Reply

Your email address will not be published. Required fields are marked *