Joel Aelwyn

There has, for quite some time, been the concept of “drag-and-drop” programming, where you can pull components out of a toolbox and hook them together in a GUI, and the tools you're using just generate all the necessary code “under the hood” to make things go together.

I realised a few moments ago that the more apt description of how this tends to actually be used is “poop-and-fling” programming: code monkeys throwing shit at a wall until enough of it sticks.

Unfortunately getting the full effect requires having a login, but take a look at the e-incode site. Now, imagine that there are now half a dozen drop-down menus across the top instead of two, and that the left sidebar is filled past the bottom of the screen with navigation links (both presented reasonable sanely, mind you). Last of all, imagine that the content seen on the login page is all still there, but there is enough additional content above it to push the images to the bottom of the page.

Now try to find the training site link.

Fail #1 (minor/arguable): having both top bar and side bar navigation is usually confusing to the user. There are ways to make it work, but this site doesn't really do them properly.

Fail #2 (significant): neither the top bar nor the side bar have a link to the training site, despite the fact that it is a fairly major destination for folks coming to this page, *and* the fact that many folks looking for it will be coming to this page *for the first time*.

Fail #3 (significant, but compounded with #2 becomes FAIL): making the training link a graphic that is the same size, shape, *and* position on the screen (for normal-size screens) as a banner ad, *and* occurs below a "demo" graphic of the same type that *says* "demo" near the left-hand side (thus making it look even more like a banner ad).

It literally took me ten minutes to find the stupid thing, because I have (like so many others on the 'Net today) a strong mental filter / "blind spot" to catch banner ads. I literally *did not see it*. Yes, the photons went from the screen to my eyes, and I'm fairly sure my optic nerve continued to work, but the "front end" pattern recognition in my brain that turns a visual signal into meaning information -- the act of "seeing" -- filtered it out of my perception. Entirely. To the point that when I finished hunting every obvious place on the page I *still* didn't see it.

I had to go check the email a couple of times, and be sure I was in the right spot, and think about the unlikelyhood of them not having *some* training link on the front page, before I went back and started looking at the page in a very deliberate "item by item" search. Even then I almost skipped over it.

So this recent bug with the older ("Phat") PS3 units not being able to connect to PSN, sometimes crashing, sometimes resetting dates to Jan 1, 2000 or Dec 31, 1999, is all over the news. My psychic predictions:

1. It will prove to have been a leap-year related bug. Why? Things started "just working" again with a *no update* "fix" that happened to start working... pretty much exactly as the day rolled over in the UTC timezone.
2. My bet is on buggy handling of a 30-year offset from the standard "Unix epoch" calendar (0 = the start of Jan 1, 1970 in UTC). Why? Because while 2010 is not a leap year, a 30 year offset would be 1980, which *was* one.
3. My bet on how it got there?
   1. Developer Alice uses one of the umpteen standard implementations of the Unix epoch calculation to represent the system time internally, because it is simple, readily available, consistent, and has no licensing issues.
   2. Designer Bob sees the default time when nothing else is available is 1970, and says "Hey, 1970 is silly, it should be 2000".
   3. Developer Clarissa says "Okay, no problem, we'll just add 30 to the year value" (mistake 1).
   4. QA gal Denise does some basic testing of the calendar, for example "the first leap year that the unit will be in production" (2008), and files a bug when he observes that 2008 is not being handled as a leap year.
   5. Developer Eustance, who has the most unfortunate name in this entire narrative, gets stuck with the bug and goes hunting. He realizes that the problem is because with a 30 year offset, leap years aren't lining up correctly, so he implements a quick hack to calculate the leap year "properly" (any bets on whether this hack handles the 100-year/400-year rules correctly? I thought not...) and hands it back. All is well... or so it seems.
   6. QA gal Denise, under time pressure for the release, checks that 2008 works now, and it does. Unfortunately, since she *doesn't* know the internal workings of the code, there is no obvious reason to test for the alternative corner case: times that happen during a "leap day" which have no equivalent in their "partner" year at the 30-year offset, leading to an illegal calculation and much *boom*.
   7. PS3s ship with horked code
   8. PROFIT!!!
4. And why this is happening only on the older "Phat" PS3s? Because at some point someone looked at the code mentioned above, saw the bug, and fixed it (I can only pray to $deity that they fixed it by MAKING THE BLOODY DEFAULT DATE AN OFFSET FROM 0 AND USING THE CALENDAR LIKE IT WAS INTENDED DAMMIT). However, since different generations of PS3 actually run on different hardware internally, they almost certainly have multiple builds, and when (if) this was merged back, it was *not* merged to whatever build the Phat PS3s run on. Oopsie.

The "best" part of this? Sony's blog said that they "hoped to have a fix within the next 24 hours". If by "fix" you mean "do nothing because the units cannot log onto PSN to download an update, but it will fix itself 24 hours after it started", sure. And hey, if we're lucky, they *might* even bother to merge the fix back to the correct build and release an update someday.

On the other hand, if this is the bug the next time it will bite is in 2014, and who's going to still be running a PS3 in another four years, right? And it's only one day every four years, for the oldest console generation, they'll just wear out by then, surely...

Sadly, unless someone intimately familiar with the software involved comes out and discusses it in ways that would probably cost them their job (at the very least put it at serious risk), we'll probably never know for certain.

Okay, time for me to vent for a few. I'm not going to (fully) name names, and it seems relatively unlikely that any of the people involved will ever bother reading this journal even if they found out it existed, but frankly, even if they do? This is my ranting. If you're here, you think it is about you, and you care about my opinion, then do something to fix the cause.