Testing Stories From Developing MacPaint
Creating new platforms like Android and iPhone is incredibly difficult, but it’s rare to hear stories about the challenges of building them unless you’re an insider. There are probably dozens of good tales about developing these platforms that will take years to trickle out from behind closed doors.
So to hear stories like these, we must look back in time at the great development projects of the past. Today the Computer History Museum announced that Apple has donated the source code for the original MacPaint application so that it can be downloaded by anyone. MacPaint was a drawing application included with the first Macintosh that by today’s standards seems very simple, but in 1984 was completely revolutionary. Many of the graphic design tools we take for granted, like the paint bucket and lasso select, were invented in MacPaint.
For developers and testers alike, there’s a lot to learn from the development of MacPaint. Here are a few good stories:
(From Folklore.org)
The last part of finishing MacPaint involved dealing with out of memory problems, since it was really pushing the limits of the 128K Macintosh by using the three, large offscreen buffers. At the worst case, there was only about 100 bytes free in MacPaint’s heap. Most of the bugs we encountered when running MacPaint turned out to be bugs in the underlying system, which were exposed by running so close to the edge of available memory.
(From The Computer History Museum)
In writing MacPaint, [Bill Atkinson] was as concerned with whether human readers would understand the code as he was with what the computer would do with it. He later said about software in general, “It’s an art form, like any other art form… I would spend time rewriting whole sections of code to make them more cleanly organized, more clear. I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing…
(From The Computer History Museum)
When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.
But my favorite story is about The Monkey. MacPaint kept triggering bugs in the Macintosh’s hardware, but reproducing those errors was often impossible. So the engineers borrowed the screen recording tools used to build the Mac’s guided tutorial program and then combined them with a little device that simulated hitting the keyboard and moving the mouse around randomly. It looked like a monkey was playing with the computer. The end result was a cheap and easy automated testing solution that discovered a number of additional Mac bugs.
But The Monkey had one problem: it would sometimes randomly quit the application, cutting testing short. So the developers created a system routine called “MonkeyLives” that would disable calls to quit if The Monkey was in use. For years after that, a mysterious flag existed in the Mac’s system memory called “MonkeyLives” – all in the service of early automated testing.
