Revolution in the Valley: The Insanely Great Story of How the Mac Was Made (29 page)

Both Larry and I cared more about pleasing Bill than saving every possible byte or cycle, so we changed our fix to use the slower, more conservative, Bill-approved technique. We also added a comment to the instruction in the source code, to remind us why we did it the slower way in this circumstance. The comment said "We're Not Hackers!".

Make a Mess, Clean it Up!

by Donn Denman in September 1983

Defender was Burrell's favorite
video game

Working 90 hours a work week requires frequent, and highly effective, work breaks. In the center of Macintosh work area in Bandley 3 we had a ping pong table, a nice stereo system, and a Defender video game machine. We found that competitive play gave us a jolt of adrenaline, and a refreshed mind-set when we resumed work. We also learned a lot about our coworkers and how they excel during competition. While playing Defender one day I got some great insight into how Burrell accelerates his own learning process.

Andy, Burrell and I had a standing competition playing on the Defender machine. We'd challenge each other, in two or three player competitions, taking turns at the video game machine, and compare techniques and high scores. We were roughly equal in skill level, so as we'd take turns at the controls we could watch how the other player was doing, and have a gauge for who was ahead. This gave us opportunities to refine our skills, learn the other guy's technique, and show off our prowess.

The goal of Defender is to defend your humans from abduction by aliens. The evil green aliens drop down from the top of the screen and randomly pick up your humans, and try to bring them back up to the top of the screen. You control a ship and have to shoot the aliens, either before they grab a human, or during their rise up to the top of the screen. If an alien makes it to the top with a human, they consume him and become a vicious mutant, which attacks very aggressively. You start the game with ten humans, and if the last one dies, all the aliens become mutants, and they swarm in on your ship from all sides.

After a while, surviving the first few game levels was pretty easy, unless you had been up all night programming or something. The Defender machine was probably a pretty good objective measure of current mental capacity. "Gee, I can't even get through level 2! I guess it's time to get some sleep." Better to put in a bad performance on the defender game than mess up the current programming task, or start down the wrong path on some hardware design.

Woz playing Defender in Bandley 3

One day Burrell started doing something radical. Andy came by my cube and said "You've got to come see what Burrell's doing with Defender." "How can you innovate with a video game?" I wondered. I'd seen Burrell and Andy innovate on all kinds of things, but I couldn't image how he could somehow step outside the box of a video game - the machine controlled the flow and dictated the goals. How could you gain some control in that environment?

We started up a new competition, and when Burrell's turn came up, he did something that stunned me. He immediately shot all his humans! This was completely against the goal of the game! He didn't even go after the aliens, and when he shot the last human, they all turned to mutants and attacked him from all sides. He glanced in my direction with a grin on his face and said "Make a mess, clean it up!" and proceeded to dodge the swarm of angry mutants noisily chasing after him. "Burrell's not going to win this competition" I said to myself. "He's not going to last long with a screen full of mutants!"

Often a single mutant is enough to kill you. They move quicker, and with a different pace and pattern than the other aliens, so the normal evasive techniques don't work very well. Mutants move so quickly over small distances that they seem to just jump on top of you. Your ship is faster over the longer term, so you have to outrun them, establishing a gap, and only then do you have enough room to safely turn and fire at them.

When Burrell's next turn came up I was surprised by how long his ship survived. He'd already developed a technique for dealing with a whole mass of mutants. He would circle around them again and again, and that would gather them into a densely clumped swarm. Then, while circling, he'd fire a burst pattern across the whole swarm, not needing to aim at individuals. He was doing really well, cutting through the swarm like the Grim Reaper's scythe. Burrell was no longer attacking individual mutants, instead he was treating the whole swarm as one big target.

Burrell may have lost that game and the next few, but it wasn't too long before he was really mastering the machine. Instead of avoiding the tough situations, he'd immediately create them, and immediately start learning how to handle the worst situation imaginable. Pretty soon he would routinely handle anything the machine could throw at him.

I was beginning to see how Burrell could be so successful with everything he does. Like many high achievers, Burrell likes challenges so much that he actually seeks them out and consciously creates them. In the long run, this approach makes sense. He seems to aggressively set up challenging situations throughout his life. Then, when life throws him a curve ball, he'll swing hard, and knock it out of the park.

Why intentionally "make a mess?" So you can get really good at "cleaning up!"

Price Fight

by Andy Hertzfeld in October 1983

The Macintosh was originally intended to be a very low cost, high volume personal computer. We wanted to keep the price as low as possible, so the Mac would be affordable to ordinary individuals, and Apple could sell them by the millions. The initial target price was $500, less than half the price of an Apple II at the time, but it quickly rose to $1000 after the design team added up the cost of various components.

In early 1981, after switching from the 6809 to the more expensive 68000 microprocessor and doubling our RAM size to 128K bytes, we realized that we'd have to raise the retail price to $1500 in order for Apple to make its standard profit margin. $1500 was approximately the original price of the Apple II, and it seemed like that was about as high as you could go while still being affordable to individuals. We worked hard to keep the price from rising further, and were able to hold it at $1500 for most of the time the product was under development.

Pricing a brand new computer is tricky, because costs are highly dependent on volume: the more units of a component that you were willing to order, the lower the price per unit. But how can you predict how well a new type of computer will sell? It's literally a confidence game, and we had no shortage of that. Steve Jobs
knew
that we were going to sell Macintoshes by the millions, and he was good at convincing our suppliers to share some of the risk with us via lower initial prices, to be rewarded as volumes soared in the years ahead. For example, Steve was able to get Motorola to commit to a price of $9.00 for the 68000 microprocessor, less than a quarter of what they were currently quoting at the time.

By the summer of 1983, it was becoming clear that the disk division's Twiggy floppy disk drive wasn't going to make it, and if we weren't careful, it could drag down the Macintosh with it. We had to scurry (see
quick, hide in this closet!
), but we were able to replace Twiggy with the Sony 3.5 inch drive without slipping the schedule, which was better in every way except one: it cost us an extra $50 or so. When combined with a few other recent splurges, it pushed us over the top, so we grudgingly accepted that the Macintosh would have to debut for $1995.

Meanwhile, Apple hired a new CEO, John Sculley, in April 1983. John was the former CEO of Pepsi, and a world-class marketing whiz, having invented the concept of the "Pepsi Generation" and other successful promotions. He was hired by Apple mainly to apply his marketing skills to the personal computer market, and the Macintosh in particular. But big time marketing costs big time money.

In October 1983, as plans for the Macintosh launch were being finalized, and we were frantically trying to finish the software, Steve Jobs strode into the software area one evening, looking angry. "You're not going to like this," he told us, "but Sculley is insisting that we charge $2495 for the Mac instead of $1995, and use the extra money for a bigger marketing budget. He figures that the early adopters will buy it no matter what the price. He also wants more of a cushion to protect Apple II sales. But don't worry, I'm not going to let him get away with it!"

The design team was horrified. One of the main reasons that we were so passionate about the Macintosh was that we thought we were working on something that we would use ourselves, along with our friends and relatives. It was crucial that it be affordable to ordinary people. $2500 felt like a betrayal of everything that we were trying to accomplish. We worked very hard to keep the price down in every aspect of the design, and now it was being artificially inflated for reasons that didn't make sense to us. But we thought that Steve would prevail, and be able to convince John that we'd do better at the lower price.

But finally, much to our surprise and dismay, after a week or so of wrangling, Steve was the one who gave in, and the Mac was priced at $2495 at launch. Even though it sold quickly at first, soon sales bogged down, partially due to the lack of available software, but also because of the price. Even after sales picked up in 1986, with the Mac Plus and the proliferation of desktop publishing, Apple continued to overcharge for the Macintosh, preferring huge profit margins to growing their market share, which eventually led to big problems when it caught up with them in the nineties.

Monkey Lives

by Andy Hertzfeld in October 1983

The original Macintosh only had 128K bytes of RAM (that's one eighth of a megabyte), so dealing with memory management was usually the hardest part of writing both the system and applications. We allocated around 16K bytes for system use, and another 22K bytes for the 512 by 342 black and white screen, so applications were left with only 90K bytes or so. The bigger ones like MacWrite or MacPaint seemed to be bursting at the seams.

By the fall of 1983, MacWrite and MacPaint were pretty much feature complete but still needed a lot of testing, especially in low memory conditions. MacPaint needed to allocate three off-screen buffers, with each the size of the entire screen, so it was always skirting the edge of running out of memory, especially when you brought up a desk accesory, but the specific sequences that led to crashes were difficult to reproduce.

Steve Capps had been working on a "journaling" feature for the "Guided Tour" tutorial disc, where the Macintosh could demo itself by replaying back events that were recorded in a prior session. He realized that the so-called "journaling hooks" that were used to feed pre-recorded events to the system could also be the basis of a testing tool he called "The Monkey".

The Monkey was a small desk accessory that used the journaling hooks to feed random events to the current application, so the Macintosh seemed to be operated by an incredibly fast, somewhat angry monkey, banging away at the mouse and keyboard, generating clicks and drags at random positions with wild abandon. It had great potential as a testing tool, so Capps refined it to generate more semantically rich events, with a certain percentage of the events as menu commands, a certain percentage as window drags, etc.

The Monkey proved to be an excellent testing tool, and a great amusement, as well. Its manic activity was sort of hypnotic, and it was interesting to see what kind of MacPaint pictures the Monkey could draw, or if it would ever produce something intelligible in MacWrite. At first it could crash the system fairly easily, but soon we fixed the more obvious bugs. We thought it would be a good test for an application to see if it could run the Monkey all night, but usually it didn't run for more than 20 minutes, even if it didn't crash, because the Monkey would invariably select the quit command.