Friday, January 16, 2015

Accuracy Versus Precision

In a recent elevator conversation with the team, we stumbled on a side conversation about the difference between accuracy and precision. I've always used them defined this way:

  • Accuracy - The nearness of a value to the "real" value
  • Precision - The resolution of a measurement

It turns out this is not entirely correct and these definitions, while technically accurate in certain fields, are not universally held to be true. In fact, the above definition of precision is almost completely wrong for most other engineering and scientific disciplines. A more accurate (see what I did there?) set of definitions would be something like:

  • Accuracy - The nearness of a value to the "real" value
  • Precision - The probability of repeated measurement yielding the same result
  • Measurement Resolution - The resolution of a measurement
Source: Wikipedia

Thursday, January 15, 2015

Trail of tears architecture anti-pattern

I'm currently struggling with another project suffering from what I dub the "Trail of Tears" architecture pattern. This is a situation where the architecture is littered with the remains of legacy code that never seems to get removed. This leads to mounting maintenance costs, and a fragile architecture that becomes increasingly difficult to manage. It also has the side effect of creating a "broken window" problem where there is no clear "correct" way to do things and the necessary rigor around adhering to standards and best practices (I HATE that term...but oh well) rapidly falls apart.

Historically, the only way I've seen to combat this is to rigorously support opportunistic refactoring other wise known as following the "Boy Scout Rule". While this has it's own problems (folks breaking seemingly unrelated things trying to clean things up and inflated scope for features being too key ones) it has proven to be the only way to combat this problem.

The rub in solving this problem is that it necessarily forces a tempo drop when changing directions as we must now account for refactoring "things that work" so that they meet the new standards and patterns as they evolve. This is unfortunate, but trust me...it's absolutely necessary if you want a maintainable and healthy system running for years to come. My advice...don't walk the trail of tears.

Monday, January 5, 2015

Minecraft is the new Doom

I just read Coelacanth: Lessons from Doom and I just realized that Minecraft is the new Doom. If you don't believe me, find a teenager that has a computer (or smartphone, or tablet) that hasn't played Minecraft.

Doom revolutionized gaming, not by making the FPS technologically possible (thought this is a big deal), but because it spawned a multitude of user generated mods and made it relatively easy and open to do this. This, in turn, incited myriads of hacker youth to build their own mods, edit levels, even (in my case) buy books on graphics programming and learn about BSPs, GPUs, ASM coding, optimizing C code, and other esoteria that I would have ignored.

Frankly, the almost the entire gaming industry owes a debt of gratitude for inspiring the current flock (actually, we're probably on the second or third generation now) of hackers who saw success building their own games with toolkits provided by the makers of Doom. This seems to have been largely ignored up until quite recently by the business side of the gaming industry until quite recently. Some games, such as Mod Nation Racers, the Tony Hawk series, and Little Big Planet, have tapped into the idea of enabling level editing (it's pretty standard fare at this point), but there's still a gap between that and truly modding the game. In these games you generally can't affect fundamental parts of the game and the editors are, in fact, quite oversimplified (not entirely a bad thing BTW).

Minecraft and Doom, on the other hand, are built to enable hackers to expand what is possible within the game via Mods. This enables players who are aspiring developers to actually enhance the capabilities of the game beyond what the original developers had imagined. The idea of making things modifiable isn't new, but actually endorsing a tinker/hacker culture and finding ways to still make money on the product is commendable.