markbetz.net

The latest issue of Dr. Dobb’s Journal arrived today, and contained an interview by Michael Swaine with game design legend Chris Crawford on the subject of his new venture. You can find the piece online at DDJ.com. If games and game design interest you, I advise reading the interview before continuing. I have admired Mr. Crawford since the mid-1980s, around the time of Balance of Power. This is a guy who wrote his first commercial computer game for Atari in 1979. Balance of Power was a certified 250k copy smash when it was released in 1984. Somewhere along the way he veered off from the game business and went in a different direction. His new gig is a company he cofounded called StoryTron. After reading the interview I went to the site and read everything there, including some of the message board content. I think I now better understand where and why he parted ways with the industry he helped to create. I’m not sure that, in the end, it will be a journey with a successful ending, or at least it might not be the kind of success he envisions. But I understand the attraction of what he is trying to do. Continue Reading »

David Brin makes an interesting point in a recent article on Salon.com (apologies for the ‘click the banner’ hoop you have to jump through to get to the story). The author of such popular SF works as Startide Rising and The Postman is also a programmer, and he has a son who shows signs of being a programmer as well. Now various people can argue that we don’t have enough programmers, or that we do, or that the ones we have are too expensive. But I don’t think anyone will consider it a bad thing if a young person who is inclined toward the art finds the right tools to assist in the learning curve. The point Mr. Brin makes that somewhat surprised me is that we used to have the perfect tool, and now largely have it no more. That tool was BASIC.

The word ‘BASIC’ is an acronym that stands for Beginners All-purpose Symbolic Instruction Code. It was designed all the way back in 1963 by John Kemeny and Thomas Kurtz, both of Dartmouth. The point of it then was to provide a fast way for students new to programming to get up to speed on the fundamental concepts: stepwise execution; flow of control; instructions; operators; operands; variables; input/output; etc. It used to be that every IBM-compatible PC had BASIC burned into a ROM on the motherboard, and there were any number of more capable versions of it available on tape or 5.25″ diskette once those became common. Incidentally, two guys by the name of Gates and Allen got their start implementing BASIC for the Altair. Continue Reading »

Lots of people who program computers also play games on them. I’m one of them. I think for us the pleasure of a game is multiplied by an understanding of the intricacy and elegance that is running under the skin. Most people who program computers and play games on them have at some point wanted to create a game of their own. I’m one of those people, too. I actually did write and publish a shareware game called MVP Backgammon back in the early 1990’s, along with my collaborators Marc Ringuette and Justin Boyan. Dave Snyder of MVP Software has recently released an updated version of this game. The original game was fairly popular, and one of the most enjoyable projects I’ve ever done, but it didn’t satisfy my desire to create virtual worlds.

A family and a career got in the way of that, but now that Microsoft has released their XNA toolkit for creating XBox games, I’m tempted to have another go. Unfortunately I don’t own an XBox, and I’m not really into console games. I’m certainly going to take a look at this toolkit, though, and maybe I will have to pick up a console for the second time. My last one was a Nintendo in 1989 or so. Microsoft’s is not the first attempt to enable independent creative types to create computer games. I recall messing around with Mark Welch and David Malmberg’s Adventure Game Toolkit back in the 1980’s, when I was an avid participant on Compuserve’s GAMERS and GAMEDEV forums. Since that time the work of art and audio production has become a huge component of game development, and I wonder how and whether the Microsoft toolkit will make that easier. I’ll post more when I’ve had a look at it.

If you weren’t developing software back in the late 80’s and early 90’s (otherwise known as “the last century”) then you probably can’t understand why the word “turbo” brings back such fond memories for those of us who were. I suspect I am pretty typical of the class. After graduating from various flavors of BASIC my first real programming tool was Borland’s Turbo Pascal. I soon moved on from that to Turbo C++. Borland was also the company that made debugging a joy (or at least, a lot less painful) with their Turbo Debugger. TD, as it was generally known, was the first real “graphical debugger”, despite being implemented pre-Windows in a character mode interface. It provided seperate panes where you could view local variables, the call stack, globals, and any area of memory that you liked. It also took full advantage of the new features of Intel’s processors at the time, the 286 and 386, for breakpoints and single step execution, and let you set flexible watches on the values of variables.

TD allowed you to peel the onion and peer deeply into the heart of a program to find out what was going wrong with it. Eventually it was joined by Turbo Profiler, a tool that targeted code execution speed issues at a time when that mattered for the average program. All these tools eventually made their way into Borland C++ (except for TP, which morphed into Delphi), which I used for years before switching to Microsoft’s product line. And that, ultimately, is why my excitement about the return of the Turbo product line is mostly driven by nostalgia. Microsoft’s tools firmly occupy this niche for modern Windows development, and MS already offers free versions for students and hobbyists, as Borland has stated it will do. Nevertheless, I ‘ll always have a fond regard for Phillipe Borland, his company jazz band, and his vision for the kinds of tools programmers needed back in the dark days of DOS.

Andrew Stellman and Jennifer Greene have an article in the June 30th Dr. Dobb’s Journal on a topic they call “Quick-kill” project management. This is a technique they have distilled for managing projects on impossible schedules. I think “distilled” is the right word here, since the three components of the process, vision/scope definition, work structure breakdown, and code reviews are certainly not new. The authors of O’Reilly’s “Applied Software Management” are well-qualified to advise on the topic of managing to ridiculous timelines, but I do have one or two quibbles with their recommendations.

My biggest issue stems from the tactical nature of their approach to handling high-pressure development scenarios. I don’t have any problem with the constraints on their artificial example, i.e. finish the project to management’s timeline or lose your job. We can agree that a higher level strategic approach of trying to educate management falls outside the traditional boundaries of “project management” and is something that should occur at stakeholder level earlier in the game. However, let’s put this whole thing in proper perspective. We can start by throwing out the latter two steps of their process. Work structure breakdown (what I would have called functional decomposition and module design) and code reviews are entirely tactical efforts. The authors are right that, in the presence of relatively decent requirements, decomposition can be done in a few hours. Code reviews are also a good thing. Neither, though, have much to do with the basic problem. Continue Reading »

Back in the early 1990’s I blew a job interview at Papyrus Studios in Cambridge, Massachussetts. If you’re a gamer, and into racing games, then you surely know the automotive simulation powerhouse that Papyrus became. Their Nascar Racing series was the definitive racing game for nearly ten years, noted for its realistic graphics, and impressive simulation of the physics of 3000 pound cars hurtling around an oval track. If you ever got bored with actually competing, you could always turn the car around and drive the wrong way at 160 miles per hour, and then enjoy the resulting chaos when you smacked into the lead cars of the pack on the back straight. Smoke, flames, cars spinning off the track, chunks of debris flying every which way. It was a blast. Unfortunately, while I loved playing the game, I didn’t get to work at Papyrus, which closed its doors for good in May of 2004. I’m sure those things are not related.

But I would have made a pretty good employee. When I interviewed with founder David Kaemmer in 1992 the company was still very much in startup mode, though they had been in business since 1988. Located in a loft not far from MIT, the company gave off exactly the intellectual, creative vibe I was looking for. It would have been my first real programming job. I had been working in technical sales since the late 80’s, and had been programming since 1975, when I started writing BASIC programs on a time-shared teletype terminal attached to an HP3000 mainframe. By 1989 I had become a C++ and OO freak, and was both writing software, and writing about writing software, in journals such as Computer Language, Software Development, Dr. Dobbs, and Jeff Dunteman’s PC Techniques. I met most of the editors of these journals on the Computer Language forum of Compuserve. Another forum I hung out on was the Gamers Forum, and that’s where I met Chris Lampton. Continue Reading »

Back in the mid-nineties I was involved with an effort to create a back-end for a financial account management website. It was one of the first such efforts on the web, and ultimately was very successful, running more than 160 websites for small, primarily community-sized, banks and credit unions. As the main architect of the back-end I chose an implementation of the Common Object Request Broker Architecture (CORBA) by Iona Technologies, a small Dublin, Ireland company that was on the leading edge of the distributed object trend. Since then the company has moved on to Service Oriented Architectures, which is fitting, since so have the rest of us.

CORBA worked, and we were able to get our back-end operating and doing its job at acceptable levels of performance and reliability, but not without a lot of workarounds and more time and effort than should have been necessary. So it was with some interest that I read Michi Henning’s article in this month’s issue of ACM Queue, chronicling the rise and fall of CORBA, what was wrong with it, and why it didn’t make it very far out of the starting gate. My own experience dovetails almost exactly with what Michi reports: CORBA was a promising technology that in the end was hurt by overly complex standards issuing forth from a consensus-driven process in which competing vendor and user communities struggled to get everything they wanted into the platform. Come to think of it, I would say more or less the same thing happened to C++, which is why I use C# almost exclusively these days. Anyway, it’s a worthwhile read, especially if you’re participating in a standards process, or an open source software project.

I’ve written here in the past about the nature of software, and how to visualize it. An article I read this morning while browsing Slashdot (one of my favorite ways to get the day rolling) directed my thoughts toward the notion of what software is, and what quality it is that allows a particular person to be better or worse at conceptualizing and producing good software. The record of my past accomplishments does not make me a natural candidate to opine on the topic. I’ve written some moderately complex software, that has been used fairly widely. How’s that for adroit use of qualifiers? The best example is probably MVP Backgammon, a game I wrote back in 1991 that has been downloaded and used a hundred thousand times or so in the last fifteen years. Incredibly it is still selling.

Maybe the worst example is CardSite, a platform for web-based credit card account management that I helped develop in 1998, and which was ultimately used by a few million credit card account holders. Whereas with backgammon I did a deep dive on the subject and concepts for over a year, CardSite was developed while I was trying to get a technology business off the ground, and taking on simultaneous duties of design, development, sales, administration, finance, etc. Ultimately we did get the company off the ground, but CardSite was a pain in the ass from day one.

The article that got me thinking along these lines appears in Scientific American, and was written by Daniel Jackson, one of the creators of Alloy, an automated tool for checking the correctness of software designs.

That in itself is an interesting objective, and leads to a subject too deep to cover in what I intended to be a quick blurb here. It’s worth reading the article if you have an interest in this kind of thing. Suffice it to say that asserting the correctness of a software system requires iterating through all of its possible states and validating that no undersireable outcomes proceed from them. This is generally recognized as an NP-complete problem, i.e. one for which the only solution is to patiently apply every possible set of variables to see what works. In more concrete terms, to solve an NP-complete problem requires interating through the whole solution space looking for acceptable solutions - an analog is the classic “Travelling Salesman” problem that has been taught in CompSci classes for years.

But I digress. There were two statements in the article that got me going. The first occurs on page 4: “Bad abstraction choices lie at the root of many unnecessarily complicated or unreliable systems.” I think most experienced developers intuitively recognize the truth of that statement. You can teach somebody the syntax of a programming language, and perhaps even imbue or awaken in them some appreciation of the process of implementation. But how do you teach them to visualize a problem space and then decompose it into component parts in a way that produces a cohesive, complete, logically consistent model of the system? Is this art or skill or both? It seems to me that this is a weakness of tools like Alloy. The search technology is impressive, but to achieve correct results you need substantial skills in design, modelling, and expression. You could argue that every developer should have these skills, but I have met many who do not.

The second statement occurs in the last paragraph of the article: “At some point, there may come a time when software becomes so essential to our day-to-day infrastructure that society will no longer tolerate bad software.” We’re very close to that point now, I think, and the tools we have for producing software are evolving much less rapidly than is our dependence on what they produce. In areas of critical software development (military and engineering systems, for example) where lives are at risk, correctness is ensured by strict management of the implementation team and exhaustive testing, with the support of a few tools that largely automate tactical areas of the problem.

It will be interesting to see where all this goes, but in at least one sense it has already affected the way I manage the team of developers that work for me, in that it has changed the nature of the questions I ask candidates. Too many interview processes for technical positions rely on demonstrating memory of rote knowlege, like how an API works. There is too much of this stuff for any developer to remember these days. If you focus on this you either miss good thinkers who have general knowlege, or you get highly-specialized people who have immersed themselves in one specific technology. Things change much too rapidly for the latter to be a good investment, so I have refocused on questions about the thought processes that will hopefully produce more of the former sort of person.

I wrote here last month about fooling around with Konfabulator, and I have been having a lot of fun with it. It really does remind me of working in BASIC all those years ago, with little programs that do cool stuff, and nary an MSDN browser session in sight. Working with Konfabulator reminds me of those days in other ways as well. Debugging facilities are pretty much limited to print statements, log messages, and alert boxes. You don’t have to be a programmer to enjoy Konfabulator. It is a compact program, trivial to install and set up, and comes with a bunch of cool widgets. Many more are available on the online gallery. But if you are a programmer then you can hardly use it for very long without making widgets of your own. True to form I couldn’t do a simple “Hello World” thing. Nope. I have a new computer built on AMD’s dual core Athlon XP processor, and I wanted a widget that monitored CPU loads for both cores. Why would you want to monitor CPU loads? Just because. I called my widget CPUSpy, and it looks like this:

If you have Konfabulator you can click on the image above and then click ‘download’ on the file page to grab the widget. Once it is downloaded just double click the file to install it. You’ll need Windows XP, Server 2003, or Vista, for reasons I will detail below. Creating this widget turned out to be an interesting and sometimes frustrating exercise, for a couple of different reasons. Continue Reading »

It’s a constant theme in software engineering: systems are too complicated, requirements too ephemeral, projects too risky. For the last twenty years we have been pouring intellectual fuel into the problem of large-scale software engineering, software quality, and overall implementation risk, and depending on who you talk to, we have either made a little progress or none at all. Recently so-called Agile Development methods have been getting a lot of press. A story in eWeek.com Friday highlighted the extent to which Microsoft is beginning to reply on agile methods, and in particular a variant called Scrum, to make shipping product easier, and faster.

Scrum, its name taken from the world of Rugby, and meant to evoke players huddling together to exchange strategy before heading out to play their roles, was developed by Ken Schwaber and Jeff Sutherland back in the mid-nineties. It actually predated much of what came to be known as Extreme Programming. The reason I like these approaches is that they take advantage of the essential mutability of software. The one thing that makes software engineering different from other forms of engineering and construction is the ease with which changes can be made.

I have made the point in this space previously that software development is like all other complex engineering tasks: it involves the assembly of myriad parts into a complex whole that achieves specific goals, or requirements. But the ease with which software can be changed ultimately lowers the risk of getting the requirements wrong. This may be surprising to those who have participated in the archetypical project flameout driven by just this sort of misunderstanding, but I think even they will admit that the flameout cost less than it would have on, say, a suspension bridge project.

Getting requirements right is hard. It involves iterations of analysis and design, and rests on the ability of specialists to derive the subtleties of a problem from ordinary users and other experts. When you’re building a bridge, or a hotel, you must invest the time and money needed to fully explore the problem space, because the costs of error are high. In software, unless the system is intended to run the nation’s air traffic control system, or something of similar criticality, most implementing organizations won’t or can’t commit those kinds of resources. In such an environment the attractions of agile methods are easy to understand, and may in fact offer a path to “getting it right” that the typical business can afford.