Head Tracking on the Web and Software Longevity

Fun with Head Tracking on the Web

Back in grad school, I was fascinated by a research program at University of Illinois at Chicago on the CAVE VR system. Instead of special glasses, images are projected on the walls of the CAVE and head tracking determines what images should be displayed:

Now everyone has webcams. Wouldn't it be cool if we could use our cameras to track our head use that to properly render 3D on our monitors? Since JavaScript now includes both camera capture and 3D display libraries, a quick demo should be possible right through the web browser! Excited by this idea, I found a JavaScript head tracking library and demo made back in 2014. Of course... it didn't work anymore. So over the winter break I debugged it and got it running on Windows browsers and iOS Safari (check out the demo here).

The head tracking is a bit fragile, but it is a functional proof of concept and I found it fun. (Of course I found that Asus just announced a laptop that uses lenticular lenses for glasses-free 3D and head tracking for real-time position-based rendering. So cool...)

A Lesson in Software Longevity

But why did it break? A clue is given in this line of JavaScript:

navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia;

Back in 2014, the JavaScript function to get access to the camera was rather experimental. Each browser had a slightly different implementation of it with different names, and this line tries to find the function across all the different possible names. Yuck! A couple of years later, the officially adopted version of "getUserMedia" was rewritten to use JavaScript promises instead of callbacks, so this code completely broke.

This made me think of the some pieces of ancient software that I've written that still work, specifically Wineyes in 2002 (Internet Archive link) and AnywhereBoardGames in 2011. What properties do they have that give them longevity?

I claim, without proof, that: The stability of a library is proportional to its userbase (or more accurately, the amount of money invested by its userbase). 

Wineyes is based on Win32 Windows API libraries, and AnywhereBoardGames is based on non-experimental vanilla JavaScript and very simple PHP. Win32, vanilla JavaScript, and simple PHP have such a wide and invested userbase that their modification would break Windows and the Web. As a result, I would be surprised if WinEyes and AnywhereBoardGames fail to work a decade from now.

This rule of stability is demonstrated in the 14 years it took to retire Python 2 and how Amazon and Red Hat created their own fully-supported versions of Java 8 when Oracle changed its Java license approach.

So how do we write software for the ages? Let me steal from Marko Balabanovic's "Four Rules for Software Longevity":

1. Keep it Stupid - Marko suggests keeping software as simple as possible (eschewing unneeded complex design or features).
2. Self-Contained Pieces - Reduce dependency on external libraries or frameworks
3. Safety in Numbers - The more users who use it (specifically hobbyists and members of the maker community) the longer your code will survive
4. Don't Touch - If it's stable, don't modify it for the sake of modification (Marko's example was adding Amazon's Polly API to read out the score for a web application, which clearly breaks the first three rules)

Of course there are tradeoffs. Using frameworks and external libraries allow us to write code faster. Adding features keeps software fresh and new. But now we can be fully aware that these tradeoffs exist.

Thank you for reading this!