Wednesday, February 20, 2013

Why Programming Environments Matter, Gaming Edition


As I do some posting on another site, I've been running the BGR live stream of the Sony Playstation 4 launch on my second monitor and I've got something to say.

I'm not a "gamer". I stopped playing games back in 1999 when I found that I had lost yet another weekend to Quake and Tomb Raider. I spent innumerable hours playing Quake, TR, Doom (and many others -- the late 1990s were kind of slow for me, socially speaking) on my Micron Pentium II. Before that, Falcon 3.0 (and Commander Keen and Wolfenstein 3D) on my Northgate 386/33. In medieval times, Ultima on my Mac Plus and Adventure on my Atari 2600 occupied my time. I was never all that good, but the games absorbed my brain in a way that TV never did. I had to stop playing games because I didn't do much else in 1999, besides go to work.
 
Since then, I have watched developments in game hardware and software from the sidelines. I do have some observations about the situation with the forthcoming PS4 and XBOX 720 consoles and I'm interested in how the competition between Sony and Microsoft plays out
 
It's interesting to me that the much-hyped (back then) "Cell" and "Xenon" microprocessors (Sony and Microsoft, respectively) have been dumped in favor of x64. The older consoles both used parts derived from PowerPC architecture. When those consoles were released, there was a lot of gushing over "lifelike" animation and how powerful the chips were. (I'm sure that the stuff shown at Sony's launch today will look awesome. A year from now, what you see today will look weird. Ten years from now, it will look crappy. People's ability to detect animation seems to improve just as fast as the technology improves. Much like nuclear fusion and rocket boots, real-time, life-like animation is always a few years off into the future.) Additionally, it was alleged that both companies minimized piracy threats by using an unusual (meaning not x86) architecture. 
 
PowerPC chips were originally designed to be a scalable family of commodity, general-purpose parts. They were used in Macs, in various industrial situations and as on-board computers in vehicles. PowerPC didn't pan out and it isn't a viable option anymore. It hasn't been an option for serious computing since before Apple did away with them in 2006. Several years later, both high-end console companies are moving to x64. I presume that they have something up their wizardly (crypto) sleeves to clamp down on the pirates. 
 
(I do wonder why they haven't gone with ARM. Is it that 64 bit ARM processors won't be viable until later this year? Is ARM still not "quite there" with computing power? I keep hearing that games are GPU-limited and not CPU-limited, so why would it matter ifthe CPU is a little "light" on power? Is AMD hurting so badly that it needs to sell parts on a long-term contract to help guarantee it's survival? Couldn't Intel just open the gates and flood Sony and Microsoft with underclocked parts having the performance of earlier-generation 32nm i5 parts? Maybe some souped-up Atoms? Surely Intel need to use those fabs for something and it doesn't look like it will be chips for cell phones.)
 
With the switch in processor architectures, the obvious problem is that you won't be playing any of the games you already own on your PS4 (confirmed by Sony during the product launch) or XBOX720 (unless Microsoft comes up with something wizardly before the launch). That means that you will need to keep your old consoles around. Since everyone who wants a gaming console seems to have one, that means a lot of old consoles will be around for a while. Games are going to have to get a lot better before the new consoles start moving in impressive volume.
 
 
Enough meandering -- here's the real rub: 
 
One of Microsoft's superpowers is making things easy on developers. (Arguably, this is their best superpower.) Many of these developers will be coming from other areas of programming that Microsoft already dominates. They will be bringing their understanding of how to program the "Microsoft way" with them. Small learning curve. Easy. Fast-moving projects.
 
I have never heard anyone say that writing software for the PS3 is easy. It was hard to write for the PS3, it will be hard to port PS3 software to the PS4 (and take advantage of the PS4's improved feature set) and I expect that it will be hard to write software for the PS4 from scratch. Big learning curve. Hard. Slow-moving projects.
 
In short, Microsoft and Sony have pressed the reset button. The playing field is back to square zero and they are now in a drag race. Microsoft is much better at building development environments than Sony is.
 
The 6.4 billion dollar question is -- who will have more (and better) software, more quickly?

You know who I'm betting on.

Wednesday, February 13, 2013

Consequences of Casual Development


I did a fair amount of work with Lotus 1-2-3 back in the day, writing spreadsheets for other people. (I was paid and everything. Amazing.)
 
Tracking down errors in those spreadsheets was always a pain in the neck. Time has marched on, mercilessly. 1-2-3, Symphony, Jazz, Improv and even Quattro are just historical footnotes now. I haven't built a serious spreadsheet for anyone since 1991. I do use Excel, more as a "user" and not as a developer. I've never really dug into any of it's debugging features. For my own purposes, I use the relatively anemic Google Spreadsheet because it's good enough 90% of the time and I always have a browser window open.
 
I've often wondered (a nice word for "daydreamed") how people debug complex spreadsheets. Spreadsheet power users, while they can spell SDLC and know their way around a VLOOKUP(), do not strike me as the types who have backgrounds in TDD.
 
Apparently, I am not the only person who wonders and perhaps more people should wonder.
 
Enough of the meandering commentary...
If you are interested in software lifecycles, are following the BYOD/empowered-user movement or have simply wondered "Is it as bad everywhere else as it is here?", I suggest reading this (warning: some economy loonies in the comments) and some additional (#longread) commentary by IT people located here.
One of Microsoft's basic strategies has been to get developer tools into the hands of users and to simplify "programming" so that those users can be effective. They even invented a term for this new class of empowered users -- "power users". Excel is a result of this strategy. In addition to a rich language of functions, there is also a macro facility built on VBA. Word, Excel and Outlook are all automate-able tools for people who aren't professional programmers. Even Microsoft's Access database is more aimed at "power users" than full-fledged coders. (Plenty of people who wouldn't know how to start coding an IIS/SQLServer or LAMP web site are perfectly comfortable in Access. I'll even go out on a limb and say that Access works great for some projects. I've certainly said that before.)
 
Microsoft is continuing this strategy with it's latest "BI" initiatives. BI takes the drudgery of coding reports and puts it squarely in the hands of the users, which actual developers tend to like, while exploiting the power of modern computers. More on-target for this blog entry, it allows people to do even more with Excel. Great -- as long as we realize that this strategy is not without risk. Many users (and their managers) do not grasp why IT departments spend vast sums on QA. Perhaps those users need to lose vast sums before realizing that QA is an investment and not just an expense.