Category Archives: Development

Retro Tech: Early Software Creator Culture

Today, I write in appreciation of Bill Budge. Budge got his start writing games for the (then-new) Apple ][. But almost right away, that wasn't enough for him. And that's where things got interesting.

After some initial forays into writing games, he got more interested in one of the key underlying parts of the games themselves -- namely, the graphics routines. The Apple ][ was a pretty revolutionary computer of its time, after all, but the limitations of its graphics processing were huge. So how could you get around them and make things that looked good – and, important for games, rendered quickly?

After working on that for a while, Budge developed another game, and this one (unlike his earlier products) would be a classic: Raster Blaster. This was not just a pinball game – it was a pinball simulation. Budge had found a way to take the amazing work he had done on getting fast, high-resolution graphics out of the Apple ][ and give it the best proof-of-concept ever.

It was no wonder that Raster Blaster became among the best-selling games of 1981. But Budge didn’t even stop there. And even though I loved Raster Blaster when it came out, and played it a LOT, it’s this next step that put him in the innovator’s pantheon.

The next year, he released a Pinball Construction Set. For the masses of Apple ][ users who didn’t know how to program (or couldn’t program advanced high-res games, at least), it was a revelation.

You fired up this program, and you could make your own game! You just dragged and dropped (a new construct at the time) components onto a pinball board, adjust physics parameters if you wanted, and go. You could tweak all kinds of things along the way, and when you got a game put together that you liked, you could save it independently to a disk and share it with friends.

Pinball Construction Set was the first (as far as I can tell) “builder” kind of game/app. All of the Sim games and other simulations that came later — they have Bill Budge to thank. (In fact, Will Wright, creator of many of those great simulations, has cited Pinball Construction Set as an inspiration!)

So it seems only right on this Retro Friday to offer our thanks to Mr. Budge as well. Not only for helping us misspend much time in our youth, but for sparking a bit of the creator culture and vibe that has become a cornerstone of development today. It all started with some bumpers and flippers.

The Power of Breaking Down Barriers

We all work in silos to one degree or another. Even with the integration of technology, very few of us are working with different people every day, solving problems with new coworkers each time. In fact, technology — while it helps to break down some of those barriers of time and space — also plays a key role in erecting new ones.

Think about a little thing like formats, for example. One canonical instance was the old videotape format of Beta vs VHS, where people who standardized on one type couldn’t meaningfully exchange video information with people standardized on the other. It still happens today with software and file formats, although the differences are lessening.

Or think about corporate competitors – if you’re standardized on Oracle financials, for example, it’s in Oracle’s best interest to make it difficult for you to migrate to a different manufacturer. One easy way to throw up roadblocks on that process is to establish proprietary formats that are difficult to match. (This happens in the CMS world all the time — Concrete5 is a perfectly-adequate CMS, but exporting all of its contents to migrate to someplace else is a royal pain!)

So it’s notable to me whenever an industry agrees on enough of a standard to be able to exchange meaningful data back and forth. And one industry that has done it — multiple times! — is the eLearning field.

Now they have been pushed along by large customers like the US military, but they still keep advancing the standards. Recently, a new API and standard called, alternatively, the Experience API or the Tin Can API, took the standards to a whole new level. Now, under this model, any bit of software can keep track of whether a user is learning or practicing a skill.

The implications are pretty big, if this gets ubiquitous. Right now, tracking your ability to learn a new Word skill, for instance, is limited to training programs that cover Word. What if Microsoft Word itself could track your progress? You’re doing an online course about how to mail merge, for example, and then you switch over to Word to practice — and the program feeds that information back to the online course, where you can get customized tips. Suddenly, everything can be about learning and professional development.

Pretty neat stuff – and it only happens when the barriers start breaking down. There are examples from other fields, too (especially through the power of XML), but those are for another day. If you’re so inclined, you should check out the Tin Can API. It’s got real potential!

Getting Better (Or: We Used To Be Worse)

I’m a bit of a pack rat. Somewhere, I have encomia that goes back decades. And in the digital world, this is true as well.

So when I got a new computing device recently and needed to migrate a bunch of data, I had an opportunity to look back at projects we’ve done over the years, and that I had done for at least a decade before. What I found wasn’t all that surprising, but it was instructive.

Starting with my early work, it was, well, fair. I mean, it worked and all (in fact, one web application I wrote a decade ago is still in production use on a public website – think about how much on the web has changed in that time!). But it wasn’t coded all that well, and the emphasis was on getting it done quickly and briefly. (In other words, the code was hard to read and not well documented.)

Then I look at a project from five years later, and it’s all different: sure, sure, it works – that much is the same. But under the hood, the code isn’t just quick, it’s efficient. And there are actual comments throughout. The front-end design and the ‘look’ of the work is leagues better (by that time, I didn’t do it myself, and we had a team with expertise in that area). It’s a professional product.

Then I turn to a project we finished last year, and it’s more advanced yet. The amount of growth isn’t as dramatic, but it’s still there. Development patterns are being used effectively and both programmatic and business logic is easily intuited from the code (and its documentation), and the separation of functions allows for easy manipulation of pieces and parts. It’s a great result.

This progression is hardly unique, I think – every person and every firm, if they’re stretching themselves and striving for self-improvement, has something similar. But we don’t talk about it much, because we worry that clients (or, more specifically, prospective clients) think “we get better all the time” means the same as “we aren’t really ready for prime time yet.”

But that’s pretty shortsighted thinking. Even the best sports pros are always working on their game. We can always improve – after all, that’s the whole point of professional development, right?

It was heartening to see that transformation over the last couple of decades. Who knows what the next project will bring?

Aspects of Love

Programming languages come and go at a frightening clip. Less often but still with some regularity, frameworks appear and disappear as well.

But it’s more infrequent that entire approaches to coding come along. Functional programming has been around forever. Object-oriented programming has been around nearly as long. But it’s only been a little more than a decade that the idea of <em>aspect-oriented programming</em>, or AOP, has been on the scene.

If you’re not familiar with AOP, some background might be helpful. A key idea behind AOP is that there are functions that your code needs to do which go across (or cross-cut) the entire application. In other paradigms, you then need to code bits of those functions all over the place. But in AOP, you do it only once.

One prototypical example is logging. If you’re writing an application that does anything significant, you probably write out to some kind of log when it happens. In a user-based application, for instance, you probably want to log every time you add a new user or delete a user.

Under other approaches, you need to call some kind of logging hook in your addUser and deleteUser functions (or methods). But with AOP, you can define a separate logging function, and tell it to attach to the deleteUser and addUser functions. The parts of the code that actually do the work with users aren’t touched at all.

Why is this helpful? Well, suppose you want to change how logging works or how you call the logging piece. You’d need to touch every place it’s called. With AOP, you just change the logging piece once, and you’re done.

Or suppose you decide well after the design stage that you want to add a layer of security to every user routine to make sure the person trying to make a change has permissions to do so. You could go find all of the functions and add calls to them, or you could just create a security-check routine and attach it to the relevant functions.

Compiled languages like Java and C++ have had this idea for a while now, but it has been slow to come to interpreted languages. With the Flow framework, for instance, PHP now has AOP capabilities. There’s still some roughness around the edges, but it’s a big step toward widespread adoption of this approach.

Watch this space…