The Graphing Calculator Story

Uploaded by Google on 23.07.2007


GREG ROBBINS: I'm Greg Robbins.
I work in Google Seattle engineering office as a
software engineer.
In 1992, I was hired as an independent contractor at
Apple computer to write operating system code for a
experimental hardware project.

On that project I met Ron Avitzur.
He was also an independent contractor doing software for
the project.
Ron's here to tell the story of what we did after that
project ended.

RON AVITZUR: Thank you for inviting me.
Let me apologize in advance.
There will be no actual technical content
in this tech talk.

I'm turning 40 next week.
And so I apologize if I become maudlin.
But I'm taking this opportunity to embrace
becoming an old codger by reminiscing publicly about the
adventures of my youth.

I started programming in the '70's back when programs were
stored on punched cards and the VT55 terminal was
I was a faculty brat at Lehigh University.
So I had access to all sorts of toys as a young'un.
When I started college at Stanford in 1984, the
Macintosh was brand new.
And it was an interesting time to be on campus looking at
computer use.
Because when I started college in 1984, there
were Macs on campus.
So I had one.
And Stanford was an earlier adopter.
But largely, nearly all the students still used
And the interesting thing to see was that the original
Macintosh, along with MacWrite 1.0, was so amazingly easy to
use and easy to learn that you could take someone, and I did
this many times, someone who had never touched a computer
before, was completely non-technical, sit them down
in front of the original Mac, and in five minutes of
instruction with MacWrite, they would learn everything
they need to know.
And it would be blindingly obvious to them immediately
that they could get the paper written that they had to have
written that night, they could get the job done quicker using
the computer, even after they took into account
the learning curve.
And so, in terms of ease of use and ease of learning,
that's a very strong statement.
That you could take someone that's a complete novice, and
it's just obvious to them that, yes, this tool does the
job better, even with the time it takes me to learn it.

I was studying physics at the time.
So most of my time was spent doing
mathematical problem sets.
It involved staying up late at night, writing out 10 or 20
pages of algebra for each one.
And it was ironic that I was watching, essentially, that
the last years of the typewriter go away as word
processing was just obviously the right way to do things.
And at the same time, the computer was far more useful
to my colleagues writing English papers than to me
doing math.
For the math I was doing, the computers were
just not at all useful.
It wasn't that the math was difficult.
I had access to systems. I was familiar with the state of the
art in computer algebra at the time, which
was Maxima and REDUCE.
And mathematically, they could do any of the sorts of things
we were doing in our problem sets.
But the time it took to formulate your problem in
their command line interface, struggle with their syntax,
and then interpret the result in a way that's presentable as
a document was far more time than it took to just do
everything out longhand with pencil and paper.
And fundamentally, that's a user interface problem.
So I took some time off from school to develop software to
essentially do for mathematical problem sets with
word processors do for people just writing prose.
This became a Macintosh product around 1987 called
Milo that was billed as a math processor for students doing
problem sets.
It integrated text equations and graphics in a document.
The equations were WYSIWYG.
They appeared in the standard textbook notation as you
entered them.
And you could manipulate them doing the sorts of algebra and
calculus things that students would be doing as

While the original product, Milo, wasn't a commercial
success, it was influential on a number of other products.
And the source code from it I licensed out to a number of
other companies that was later embedded in other products.
Its biggest limitation, just as a tool for students, was
that the word processing in it was extremely minimalist. It
was too weak even to do the simple things
that students needed.
So I went out looking for companies to, essentially,
embed the Milo software in their word processor, and
ended up at Frame Technology.
They were looking for a mathematical typesetting
system for FrameMaker 2.0.
And I worked there for a while embedding the mathematical
typesetting from Milo into FrameMaker.

All of the computation that went into it, all of the
computer algebra system, essentially
came along for free.
And they left it in just to give the sales folks more
buttons to push to make demos.

They didn't quite realize what they had until it had been
shipping for a while, and someone at an Arizona nuclear
plant sent in a bug report of the form, it evaluates this
particular integral incorrectly.
But at that point, they were committed.
So FrameMaker is a beautiful system.
It's still shipping today.
And frame math is still derivative from the original
work I did on Milo.
At the time, I was proud to be responsible for the only page
layout and word processing program that would evaluate
derivatives symbolically and multiply matrices and have
series mathematical underpinning.
But it still wasn't ideal for students.
And again, it was fundamentally a question of
the user interface.
There are a number of problems with user interface in
The most fundamental one is that mathematical notation
evolved for use with pencil and paper.
It involves a much larger character set than you
typically find on a keyboard.
And it's intrinsically two dimensional.
So after working at Frame for a while, I went off on my own
and did what many others have done.
I wrote handwriting recognition system that could
handle a large character set for mathematical symbols and
Greek letters and also parse the two-dimentional structure
of the mathematics as you write it on a tablet.

I took a version of Milo, which embedded the handwriting
recognition so that you could essentially write on a tablet,
as if it were a piece of paper, equations and text and
scribbles and be able to manipulate the equations.
And then started taking that to hardware companies, at the
time when Go and Momenta and pen computing were very
popular, looking for a hardware platform that would
be appropriate.
And this is how I ended up at Apple.
I had what was an impressive demo of pen computing, but
still was a long way from a useful product and needed a
hardware platform that was suitable for it.
And this is where I met Greg.
So after a year working on a secret hardware project at
Apple-- and I won't go into any details on that--

ultimately, the project was canceled.
And while on the one hand the time working at Apple both was
very educational working in systems software, and also
very educational being part of a large company, when the
project was canceled, it was, in one sense, a relief.
Because the hardware project we were a part of was having
problems. And in another sense, it was extremely
frustrating that, essentially, a year of work
was completely wasted.
So at this point I decided that I wanted to stay and
finish it so that it wasn't a waste.
As the hardware project was winding down, one fellow would
visit my office almost daily and tell me that the Power PC
group, which was down the hall, was building some
exciting hardware, and I really had to meet them.
But while working on this other project, I was too busy.
So after the original project was canceled, I went and
visited the folks at Power PC, who were interested in the
work I was doing, but they were too busy with their own
work to be able to hire me.
So this one fellow brought another friend of his into my
office after the project was canceled and just camped out
there for the night.
They decided that they were going to port software I had
been working on to the Power PC hardware.
And they spent till the wee hours of the morning going
through 50,000 lines and getting it to run as a Power
PC native application.
At the time, the only way to build on Power PC was to cross
compile from an IBM RS/6000 workstation.
So it was a difficult piece of porting.
The Power PC wasn't shipping yet.
The software tools for it weren't ready yet.
And there wasn't a lot of expertise in how to build
applications for it.
But after many hours, we got it to compile and link, and
then took it down to the next building where one of them
knew where there was one of the rare Power PC prototypes.
The first time we launched it, the monitor attached to the
prototype caught on fire and started smoking.
I could not make this up.
The fellow just shrugged and unplugged the monitor and
carried it out onto the balcony to avoid setting off
the smoke detectors, plugged in another
monitor and tried again.
And we were very impressed.
On the Power PC machine, it was running 50 times faster
than it had been on the development machine I had been
working on before.
Things that had previously been taking five seconds of
frame were suddenly animating at 10 frames a second.
It was a qualitative difference in what you could
do with the machine.
A qualitative difference in the behavior.
They just looked at it and said, this doesn't suck, which
at Apple, at the time, was high praise.
Typically, people on systems software would struggle to
make small improvements.
And if they're able to improve something a little, they would
praise it by saying, that sucks less.

So at this point, we had an impressive demo.
We had a native Power PC application, almost the only
one in existence.
Because everyone at Apple that's working on the Power PC
at this time--
and this is in August of '93--
is completely focused on just getting the hardware to run,
getting everything to run correctly under emulation.
And no one has spare time to spend working on native
applications, because all the focus is on compatibility.
No one outside the company expects Apple to succeed.
It's been announced publicly, as part of the Apple, IBM,
Motorola alliance, that Apple is switching to Power PC.
But no large company had made such a transition
successfully yet.
And the expectation was that the first release of these
machines would be a disaster because of compatibility
So with all of the internal engineering cycles being
focused on compatibility, this was one of the very few native
Unfortunately, after the last year of struggling with a
failing project, I was completely burnt out.
We'd been working long hours and killing ourselves for
months trying to keep this project from being canceled,
long past the point where it was obvious to everyone on the
outside that it was doomed.
And I was in no shape to do the work needed to take this
demo and turn it into something real.
So at this point I called Greg, who was now in a
different division of the company, and explained that
you've got to come over and see this.
I'd really like to ship it.
But there's an enormous amount of work to do.
And there's no way I can do it alone.
Greg, fortunately, was just finishing up a contract in his
division at the time.
So he talked to his manager and said that he would start
reporting to me.
And she didn't ask who I was.
And she let him keep the office and the badge.
And my old manager hadn't turned off my badge.
So we both still had access to the building.
And we both still had our offices.
But he told people that he was reporting to me.
And I told people that I was reporting to him.
That left no managers in the loop.
So there were no meetings.
And we could be really productive.
It was an amazing change.
I went for months upon months of what seemed like a death
march of struggling to do little things and being
completely unable to accomplish anything just
because of the friction in the process to suddenly having no
meetings and being able to program 12 hours a day, being
able to decide things by going in and chatting for 30 seconds
or five minutes and just asking, what's the
right thing to do?
Let's go do it.
And suddenly, we were making a huge amount of progress.
It was a great relief.
And Greg was starting fresh.
I was burnt out.
But Greg wanted this to succeed.
And he was putting an enormous amount of effort into just
being perfectionist about every detail.
When we started, I figured, I think there's about a month's
worth of work to actually take this and polish it into a
finished product.
Greg probably had a more realistic idea of what that
meant at the time.

So while this was going on, I had no official relationship
with Apple.
I have been a contractor.
But the contract ended when that project was canceled.
I tried to be completely honest with everyone
when this came up.
People would sometimes ask me, do you work here?
And I'd tell them no.
And then, they'd assume, oh, that means you're a
And I'd say, well, actually no.
And then they'd ask, but then, who's paying you?
And I'd say, no one.
And then, they'd ask, but how do you live?
And I'd explain, I live simply.
And then, they'd get a really strange look on their face and
say, what are you doing here?
At that point, I'd pull them into my office
and give them a demo.
And the demo is very flashy.
And I'd explain, well, I had been a contractor, but the
project was cancelled sometime back.
And I decide to stay and finish it anyway.
And all the engineers that I explained this to were
extremely sympathetic.
At this point in Apple's history, just about everyone
had been through one, if not two or three or five or seven,
canceled projects.
It was very, very hard to get things to ship back then.
There were lots of ways projects failed.
And lot more projects got started than finished.
So after seeing what I was doing, they were sympathetic,
and as often as not asked if there's any
way they could help.
There had been something of a history
of skunkworks projects.

There had been many times in the past where engineers took
their cancelled projects and worked on it after hours on
their own time trying to revive it.
And sometimes we're successful.
There was one project at the time, appropriately enough
code named Specter, which had been canceled and revived five
times at the time I was there.
I don't know if it's shipped since then.

Mostly, because we didn't report to anyone, we weren't
anyone's responsibility, we were just under the radar.
No one worried about us because everyone was focused
about worrying about what they were responsible for.
And we've both been working there for over a year.
So we were familiar faces.
And it was assumed we belonged.
Everyone assumed someone knew what we were up to in and was
responsible for us.
And we just relied on the power of corporate apathy.
We just kept showing up.
Because it was so far outside people's expectations that it
just didn't occur to anyone what was going on.
But I did slip up at one point.
Someone from facilities visited me in my office one
day and explained we're moving people into these offices.
Because on my map of the floor,
these offices are empty.
So your manager's going to have to find you new space.
And that sort of thing happened all the time.
Engineers changed from one group to the other, and didn't
feel like schlepping all their stuff.
So they stayed in their old office until someone else
needed to space.
And she just figured that my new manager
would find me space.
But I've been so used to telling the story, just as I'm
telling you here now, I told her the truth.
She was not amused.
She called security and have them cancel our badges and
told us in no uncertain terms that we had to leave.
Now, right about this time Apple went through the great
layoffs of 1993 where they laid off about 10% or 15% of
their global workforce.
During the layoffs, we were safe.
Because we weren't on the books, we didn't officially
exist. After the layoffs, there were
plenty of empty offices.
So we moved our stuff.
And I made an effort to avoid this one facilities person who
actually knew we didn't belong there.
And our badges no longer worked.
But we have them physically.
So we just wore them as decoys and made sure they didn't get
anywhere near a door detector.
And I'd show up in the morning and I'd park my car and look
around the parking lot for a familiar face.
And then time my walk to the door to arrive
right behind them.
They'd open the door for me and say, good morning, Ron.
I'd say, good morning, and trail in after them.
Or if Greg got their first, I'd call Greg and he'd let me
in or vice versa.
And we were just being so productive.
We started out working 12 hours a day.
And just went up from there because we were
getting a lot done.
That, at this point, the thought of stopping it for the
trivial reason like not having building access just didn't
occurred to us.
Physically, we couldn't do what we were
doing outside the building.
Because the only way to compile on Power PC required
an RS/6000 workstation with custom software that didn't
exist outside of Apple.
And there were no developer notes or developer support,
because no one was building for Power PC.
So we really needed access to engineers to even know what to
do things or be able to do things.
And there were no prototypes to be had outside the company.
We realized what we were doing was ludicrous.
At one point, Greg and I just stopped and looked at each
other and said, OK.
Let me get this straight.
We're literally sneaking into the building, evading
security, to do volunteer work for an $8 billion corporation?
At least this is certainly going to have good
storytelling value.
In Spinal Tap idiom, this one goes to 11.
Now, we were making great progress programming.
But the more we did, the more we realized that there was an
enormous amount to do.
And we couldn't do it alone.
It wasn't just a question of the programming.
There was everything else that goes into making software.
It takes a team effort.
And there were lots of things we just didn't
have the skills for.
At one point, I went out and just hired out of pocket a
graphics designer, a visual design expert, that had
previously been laid off from Apple and just hired her onto
my project.
She didn't know what my situation was.
And I thought it was safer for her not to know, just for her
own benefit.
So I invited her in and showed her what we were doing.
And she did some designs for us that eventually shipped.

Documentation was a problem.
I hired some people to help with the documentation.
Our biggest problem was QA.
Fundamentally, you can't do your own QA.
It's a question of seeing your own blind spots.
And it's expensive to do it well.
And that was something we couldn't afford and needed
people to do.
Unfortunately, at this point, I always kept my
office doors open.
And people liked what we're doing, so they'd come by daily
to see our progress report bugs.
I'd fix them and invite them back in the next day to test
their fix and show them what they'd done.
Then, they got excited that they're having some effect.
And so, a lot of people were going through my office on a
regular basis to see what the latest changes were.
And we'd become something of an underground cause celebre.
People would whisper about us like, have you heard the story
of these two guys?
You've got to see what they're doing.
It's really cool.
And I let it be known that we really needed help because we
needed people to start testing this.
So at one point, these two guys come down from upstairs.
They're doing QA on the Power PC system software.
And they tell me they're really bored.
Because they spent a long time developing
automated test tools.
And now, they're at the point where they push the button,
and the tests will start in the morning, and they see
which API's break, and send out the email.
But basically, it's an automated process.
And they heard we needed some help.
They told us that they had stuff they were supposed to
officially be doing.
But it was boring.
So they wanted to help us out.
But I shouldn't let people know.
So I gave them copies of the software.
And they started reporting lots of bugs.
It was great.
One of them had a PhD in mathematics.
One of them had done shareware math software before.
They were amazing.
I could not have found more qualified people had I looked.

While this is going on, the various engineers that are
helping us out want to tell their managers.
They think it's cool.
It demos well.
They think, look, of course, they're going to love what
you're doing.
You have to show it to them.
But I've been putting them off for weeks.
Because it's one thing for engineers to think
something as cool.
And it's another thing to ship something
to millions of customers.
And I know that difference.
When an engineer says, look, I've been working on my own
time, and I've developed this cool thing, the default
assumption is that there's a very high burden of proof that
what you've done actually is worth shipping.
And when we were at a stage where the software would still
crash, I didn't want to show it to anyone in management.
Because if they see something, it crashes, they're just going
to shrug and say, yeah, that's cool.
I don't have time to think about this.
And so, for a long time, I was only showing it to engineers
and telling them, wait a while.
It has to be perfect before you show it to your
And the big thing that was missing was everything we were
doing was in 2-D. This was at a time when there were no
GPU's, and 3-D hardware was the province of SGI.
So we needed to be able to render 3-D
graphics and software.
And it's not an entirely trivial thing to do.
This was before there was a lot of open
source to choose from.
And it looked like something that would take me at least a
month to do that I didn't have.
I talked to a friend of mine, who's at Google now, who was
an expert in these matters.
He took a weekend off from his startup company, and wrote us
a 3-D software renderer.
That was just amazing.
He did in two days what would have taken
me weeks or a month.
And it worked perfectly the first time bug-free.
Once we got that integrated in, things were stable enough
and impressive enough that I was ready to seriously start
thinking about how we could ship this.
And the biggest problem that faced us was a question of how
to get something to ship.
Because I knew lots of official, funded projects on
the books that had been cancelled.
There were a lot of people in the company that had the power
to stop things, for one reason or another.
But it's very difficult to actually get through all the
land mines and convince folks that this really deserves to
be on the machines and to ship.
So at one point, a fellow from the hardware team came to my
office early in the morning--
I think at 2:00 AM one night-- and explained to me how Apple
worked physically.
He said, Apple is a hardware company.
There's a factory out in Cork, Ireland
that produces machines.
And the production ramp is going to start on such and
such a date.
And the night before the factory starts boxing machines
in the warehouse, I FedEx them what's called the Golden
Master hard disk.
And that gets cloned onto all the machines in the factory.
And at this point in Apple's history, there was a huge
attrition rate.
The company wasn't treating engineers well.
The future of the company was seriously in question.
A lot of people were just leaving as-is.
And he told me, so, if you get me the bits the night before
the Golden Master gets FedExed to Cork, they can appear on
the GM disk.
And they will be boxed in 30,000 units in the factory
before anyone knows they're there.
In a very real and pragmatic sense, he said, I decide what
does and does not ship.
So this conversation, needless to say, warmed my heart.
Because that was a problem that I was completely
flummoxed on.
I just tried not to think about it because it was too
And it was obvious if he pulled a stunt like that, he
would lose his job, or worse.
And as soon as anyone realized it was there, the legal
exposure, they would pull it and kill it.
So it wasn't a path we wanted to take.
But it was really very reassuring that
the offer was made.
Now, in retrospect, I don't even know if he was serious.
But this is what he told me.
And it let us move forward with more confidence.
Now, we didn't want him to lose his job.
And we thought that it was our responsibility to at least do
the due diligence and make it a good faith effort to go
through proper channels.
So when we had the 3-D and when I was no longer aware of
any crashing bugs and it had been in the testers' hands for
long enough, I told all the engineers that had been
supporting us, OK, it's time.
You can go tell your managers to come meet me.
And even before this, this was a time when we had access to
amazing resources that we couldn't have had had we
officially existed.
This was a time when I knew folks at IBM that were
IBM was just starting their fab runs on the original 601
Power PC chip.
And it wasn't fully debugged yet.
People at IBM couldn't get the chips because, although they
were going to be using it in their workstations, Apple
would ship 1 million Power PC's the first year, which is
10 or 100 times more than IBM would ship.
So all the initial chip runs went to Apple for testing.
And of that, I think maybe 200 Power PC chips that were in
existence at all, most of them were in hardware being tested.
There was a very small number of coveted machines that the
system software folks who needed it to test to ship on
the initial release had.
And no one else in the company could get them.
I would occasionally have lunch with people that were
fairly high up in projects not related to Power PC who would
complain that, yeah, I'm on the waiting list. And I won't
get a machine for six months.
But at this time, Greg and I actually had some.
An engineer from the hardware group came to my office at
midnight one day and brought a machine in and said, now this
looks like an ordinary 68k Macintosh.
So don't let anyone take the lid off.

Officially, this machine doesn't exist. If anyone asks,
I don't know you.
And whatever you do, it must not leave the building.
So we had a Power PC to work on at this point.
Still, we're sneaking into the building, and still no
managers know about us.
But the project's far enough along that we
can give it to people.
It doesn't crash.
It looks impressive.
And so, I tell everyone, OK.
Bring your managers in.
We'll make a good faith effort to actually convince them that
this needs to ship.
And so, they all went to their managers in various different
groups and said, there's these two guys you have to meet.
We can't explain why.
Just really, it's worth your time.
Be in this office 2:00 in the afternoon, and
it'll be worth it.
Trust us.
So the afternoon comes around, and these 15 people are packed
into my office.
But I haven't met, introductions all around.
And I give them the demo that I'd been giving to all the
engineers that have been coming through.
And I explain how this is really
useful in a math classroom.
That it's something that high school teachers can use,
essentially as an animated blackboard to explain abstract
concepts visually.
And for Apple, it's also a demonstration that the Power
PC fundamentally changes the rules.
Because previously, software designers would design their
software around the limitations of an eight
megahertz, 68k machine, the bottom of the line.
Because they wanted to sell to the most computers possible,
to the largest installed base.
And so, they had to assume that they were writing their
software for people with the slowest machines.
And that affects a lot of user interface design decisions.
And what the Power PC let Apple do is it let Apple say,
this is the new lowest common denominator.
When you're designing software, think of this as the
new slowest machine.
And it's 20,000 times faster then the original Macintosh
from 10 years previously.
And that lets people, as a software designer, think of
things very differently.
Things that have previously been batch-oriented can become
Things that previously used to take a long time, you could do
in an interactive way, which lets you simplify the
interface in a lot of ways that now, 12 years later, have
become natural.
We take for granted, but at the time were new.
So I gave a demonstration to all the managers, mostly
focusing on the user interface implications.
That this is a demonstration for developers on how they can
improve their user interface using the speed of the machine
to do things in a new way.
And the managers all looked at this and said, that's awesome.
That's the story we've been telling people all along.
But because we haven't had any native apps because we've been
so focused on compatibility, we've had to talk about it.
We haven't been able to show them.
But this really illustrates what we've been trying to do.
And no one else at Apple was working on
educational math software.
So this didn't step on any toes.
The managers looked at that this and said, that's great.
Why has it been such a secret?
Who's your manager?
Why didn't they tell us about this before?
So at this point, I tell them the story, much as I'm telling
you here now up this point.
And I explained, no, the project was canceled several
months ago.
This badge was canceled.
If I get it anywhere near a door, security will appear
immediately and escort me outside.
And they laugh until they realize I'm serious.
And then they quiet and think about it for a bit.
And then, they just look at me and say, OK.
We really want to ship this.
We'll figure out a way to do it.
Whatever you do, don't repeat this story.

So now, we're adopted by the people in charge of the Power
PC project on whom the company's future depends,
which, in some sense, makes this official.
But we're still sneaking into the building.
So at this point, things get really weird.
Because they're assigning people to work on it.
And I'm in the middle of this whirlwind of activity with all
of these employees actually assigned to do various things
on it and this project that I'm effectively managing while
I'm sneaking into the building.
So the first thing they do, because it's really easy to do
an impressive demo that is just smoke and mirrors.
So the very first thing they do, naturally, is they have to
get some due diligence.
They have to get some someone to test this and to see
whether it's real, whether it's worth shipping, or
whether it's just smoke and mirrors in the demo.
So that head of QA on the Power PC software is the first
person to take me aside and says, I've got these two guys
working upstairs.
They already have a full time schedule.
They're really overworked.
But I want to introduce you just to see whether they can
squeeze in extra time into doing some QA on your project
'cause we need test this.
And I smile.
And he introduces us.
And we shake hands.
And I meet my testing team.
I didn't tell him that they'd been working on it
for a few weeks now.
So we have official QA now.
The other big thing we need is usability testing.
Because we want this to be actually
useful in the schools.
It's going to go out on every machine.
And it's just going to be there in the classrooms. And
the big question for us is, is this something the
teachers can use?
And it's very different to design software for engineers
than it is to design software that's
useful in the classroom.
In a classroom situation, teachers have no
attention to spare.
Any time spent playing with the software when it doesn't
work is taking away from the curriculum, it's taking away
from students.
Any time something crashes, it's just a
waste of time for everyone.
So Apple assigned people from their HI department to do a
formal usability study.
They assigned people from QA to do testing.
They assigned a whole lot of people to do localizations.
It was, I think, translated into about 15 languages.
Meanwhile, we're sneaking in the building.
Apparently, the people who run the Power PC project, despite
the future of the company depending on it,
can't get us badges.
Because you can't have a badge without a
signed purchase order.
You can't get a purchase order without a signed contract.
And there's no way they could explain our situation to legal
without us being escorted out immediately.

So at one point while all this is going on, this one fellow,
Tim, sees Greg waiting in front of the building looking
for someone to let him in, and just accosts Greg and says,
I'm sick and tired of you guys loitering in front of the
building every day.
I'm going to get you badges.
So he comes to my office and tells us he's
going to get us badges.
I tried to explain that, no, they've tried.
They couldn't.
We can't get badges without a PO.
We can't get a PO without a contract.
And he just drags me down to his office and sits on the
phone with the badge folks.
And he goes around with them in circles for 20 minutes.
And I'm just listening to his side of the conversation.
I'm sure it's going to the same way it always has, and
he'll fail.
They say, well, if they're employees, they get their
badges after they go through the employee orientation.
And he explains, they're not employees.
We have no intention of hiring them.
And they say, well, if they're contractors, to get the badge,
you need to get the signed contract.
And then, he stops and says, no, they're not contractors.
We're not actually paying them.
Then he says, well if they're employees--
And they just go in a circle.
They're not contractors.
They're not employees.
We're not paying them.
Yes, they need badges.
But he wore them down.

Eventually, they said OK.
You take the badge form.
Where it says contractors, you cross that out and
you write in vendor.
And where it says contract number, you write in the magic
words, no dollar contract.
He got us badges the next day.
It amazed everyone.
It amazed the people running the project.
Apparently, Apple, as most companies, has a
strict caste system.
You can tell the distance by the background color on
people's badges, where they are relative to you in the
caste hierarchy.
The white badges are employees.
They're very hard to fire, and they get lots of perks.
I think it was the yellow badges were summer interns.
They're treated as employees, but they're really just
college students.
And the green badges are contractors.
And because of various IRS rules, you can't give them any
perks and have to treat them very shabbily.
But we had orange badges.
And no one had seen these before.

But what amazed me is they exactly described us.
As vendors, what it meant is that we didn't work for Apple.
They didn't pay us.
But my company has us on loan to Apple to work on site.
So we were the few, the proud, the vendors.
The people that water the plants, worked in the
cafeteria, and fixed the Xerox machine are the vendors.
They don't actually work here.
But we get building access.
So we didn't have to sneak in anymore.
That was good.

Usability testing was a very eye-opening experience for me.
I had been working on various forms of this software for 10
years, entirely focused on the usability.
We were designing it entirely in the mind of this is going
to go into classrooms without any training, with very little
documentation, with no support.
And we want it to be useful to teachers and students.
And we spent a long time agonizing over small details
in the user interface thinking, what would make its
simplest, easiest to learn, easiest to use, most useful in
the classroom situation?
And Apple did a fabulous job on the usability testing.
They went out, and they got a group of teachers.
And in the first day of the testing, the teachers all sat
around in groups of two.
They were given the software and said to make problems for
the students to work during the rest of the week.
Because they were working in groups of two, they would talk
aloud through everything.
And the person running the test just sat them at the
software and said, this is going to go on
machines in the classroom.
It's not coming with anything.
So we want to see what you can do with it to try and set some
problems for your students.
And then, he just sat with folded hands for the next two
hours watching them, not saying anything while they
tried to use it, while I was behind a two-way mirror
pounding on the glass.
It's a very eye-opening experience.
I think anyone who designs user interface, all engineers
should be forced to go through this, watching real users
actually try to use their software.
The questions we agonized over were so far beyond the actual
issues that stopped them several steps
before they got there.
And the sorts of things that they have trouble with were
things that never even occurred to
us could be a problem.
And watching that eight hours a day for five days, as group
after group went in and ran into problems, it forced us
both to go back and rethink a lot of things from scratch,
and enormously improved the interface, and enormously
improved how it was useful in the classroom.

So being publicly known the company helped in a lot of
ways with all of the resources that we
suddenly had at our disposal.
Usability testing was amazing.
It also made things more complicated.
Because suddenly, being public, the software was being
demoed to outside companies as well.
And as soon as that happened, two different groups called
in, one of them claiming that the software infringed upon
his patent causing a fire drill, because Apple has deep
pockets and they don't want to ship something that gives them
any exposure.
It took me a while to demonstrate that the patent
that he was referring to actually referred to me
as the prior art.
So they really didn't have to worry about this case.
And another company that did mathematical software simply
called and said, you shouldn't ship this, just because they
want to be the only people that are known to ship
mathematical software.
And Apple very politely declined, which impressed me.
Because a week before we were still
sneaking into the building.
And the next week, Apple is rising to our defense.

So at this point, we're working long hours, 14, 16
hours a day.
It's kind of a blur.
We just show up, run through the tests, check out the bugs,
fix things.
We were very fortunate in one respect.
When we started the project, the original ship date for the
Power PC hardware was much sooner.
And because they had to ramp up the factory, the drop-dead
date for the software to start the production was several
months before the actual release date.
And so, when we started, we thought we actually only had a
little more than six weeks or eight weeks to finish the
entire project before it had to go to the
Golden Master disk.
And it was a very tight schedule.
We designed everything around that schedule, because they
weren't going to delay the hardware for us.
We weren't on any official plans.
If we were late, they just wouldn't ship it.
That was simple.
And no one else would care.

On the other hand, because no one was expecting the software
there was no pressure on features.
There was no design document.
There's no one saying, it has to do this, this, and this.
So we just cut down the feature sets to what we
basically already had and what we knew we could ship
reliably, and then focused entirely on usability and on
making this offer stable.
We wanted to make sure that something shipping on millions
of machines would never crash.
And then, the hardware schedule slipped three months,
for reasons that had nothing to do with us, obviously.
And so, at this point, we have the code essentially frozen,
the feature set completely frozen.
And we have an extra three months during which we did
nothing but testing and a line-by-line code review.
It was a unique opportunity.
And it was more testing than I'd ever had any project
before or since.
Because we were the only native Power PC application,
everyone who had a prototype--
and, as time went on, this was more and more people--
immediately went to our software to play with.
Because it was the most interesting to play with.
Other than our software and one or two other tiny demos,
it wasn't obvious outside the box that this was nothing but
a typical Macintosh.
Compatibility was really good.
But running things under emulation, they ran about as
fast as they used to on the last generation of machines.
It was only when you ran a native application that,
suddenly, it was doing things you could not possibly do on
the previous generation machines.
And it was obvious that, under the hood, this was something
completely different.
And so, for many months, as the only native application,
everyone who had the hardware was playing with our software
and coming by my office and saying, this doesn't work.
This is confusing.
It crashed here.
And so, for many months, we had no features.
We did a line-by-line code review.
And we did nothing but testing and no code changes that
weren't bug fixes.
As a result, it was the most stable application I have ever
shipped before or since.
And I like to brag that we reached what--
Apple for many years after that point, when people would
bring their hardware in complaining of random crashes,
one of the things they would recommended, and one of the
first things they would do when they had a piece of
hardware is they would run the self-running demo that the
graphing calculator shipped and let it run overnight.
And if the demo crashed, they would classify that as a
hardware failure.

I like to think of that as the theoretical
limit of software stability.

Now, to be fair, later versions of the software
beyond 1.0 were not that crash proof.
But that original version I'm very proud of in that respect.

So to make a long story short, eventually, yes,
they shipped it.
It's still shipping in the Mac OS 9 ghetto to this day.
But it's been shipping now for 12 years and has been on, oh,
20 or 30 or 40 million machines.
It's in use in high school classrooms around the world.
Only recently, with Tiger, did they replace it with a native
program called Grapher that's completely unrelated to this.
But it's still shipping as part of the Mac OS 9
partition, if you install Classic.
Now, as the project was ending, I hired a few people
out of pocket and was able to pay them.
But Greg had been working 12, 14, 16 hour days for six
months now as a favor to me on something that I initially
said, oh, it'll take about a month.
And there's no way he could explain to his parents what
he'd been doing.
They don't use computers.
They're not technical.
So one day, I was looking at the New York Times, and I saw
the picture of a friend of mine on the business section.
And I knew the guy that the article's about.
So I showed it to Greg and said, hey, I know this fellow.
How'd you like to have your picture in the New York Times
so your parents know what you've been up to?
And he looked at me and made the only possible response.
He said, yeah, right.
So I made a bet on the spot for dinner at this really nice
And to be honest, OK, I was expecting to lose the bet.
But I knew the fellow that had written this other article.
And I called him up and said, I've been working
on this cool software.
I'd like to show it to you.
Now, I don't work for Apple.
And I can't represent Apple.
But the software is something I've been
working on for 10 years.
And it's my software.
So I can talk about the software.
I can talk about user interface.
And I invited him over.
And I gave the same spiel I was giving other people.
I didn't talk about Apple at all, except to say that we
developed this new software to run and new faster machines.
And the Apple, IBM, Motorola alliance was public.
So he knew about that.
And he was writing an article principally about the alliance
between Apple, IBM, and Motorola.
But they're big companies.
And just to put a friendly face, a human face on the main
article, he talked a little about the new generation of
software and had a photo of the three of us who had
principally wrote the software on the front time of the New
York business section, so Greg's parents could see what
he had been up to.
Now, I called someone I knew in Apple's public relations
department and said, I'm giving an
interview to the Times.
Would you like to send someone over to represent Apple?
And they gave me the standard response, engineers are not
allowed to talk with the press.

But I didn't work there.
So that was--
The next time I saw that PR person, she
was absolutely livid.
Presumably because there was really nothing she
could do about it.
We couldn't be fired.
But it was good press for Apple.
And our parents were pleased.

That's basically the story.
I'm still working on the software.
This is last year's version.
I'm working on the next release that will be out in
six months or so.
I've been working on it now for 20 years every day, as an
exercise in software archaeology.

AUDIENCE: Where can we get it?
RON AVITZUR: Email either me or Greg.

The official plug.
The website is, or just
Google graphing calculator.
AUDIENCE: So how did you guys pay for your apartments and
food and stuff like that?
RON AVITZUR: Well, we were working 12,
14, 16 hours a day.
So our expenses were very low.
And I live simply.
And we were both contractors at Apple prior to this.
Apple paid very well as contractors.
In some sense, my attitude was Apple paid me very well as a
contractor for things that didn't ship.
I felt duty bound to actually finish it and ship it.

AUDIENCE: Were you retroactively paid at all or
compensated in any way once it shipped?
And also, did Jobs ever comment on [INAUDIBLE]
RON AVITZUR: All of this occurred after
Steve Jobs had left.
And before he returned.
So it was not during his tenure.
I haven't heard anything from him about it.
We wanted the software to keep shipping.
We didn't want Apple to have any reason to have to pull it.
So yes, after all of the events of the story,
everything was made retroactively kosher.
The software was licensed to Apple so that they could ship
it comfortably for as long as they liked.
AUDIENCE: Could you repeat the questions for the video--
RON AVITZUR: Oh, I'm sorry.
The question was were we eventually paid?
And did Steve Jobs ever comment on it?
And we did eventually license it to Apple for a nominal fee.
But no, there's was never any comment from Steve.
AUDIENCE: So how long did you go between paychecks?
RON AVITZUR: The question was, so how long did
I go between paychecks?
I don't actually recall.
Because I'd been working for a contractor my entire career,
it was typical for me to go two or three
years between paychecks.
So it wasn't out of the ordinary in my case.
I often worked for a company, worked on my own for several
years, and then licensed the work.
And so, this felt quite natural.
AUDIENCE: It's not a question, but I, when I first bought the
Power PC, I was delighted with the hardware and [INAUDIBLE]
was just the coolest thing on the system.
And I absolutely loved the software then.
This is fantastic hearing the story now.
RON AVITZUR: Thank you very much.
AUDIENCE: Thank you very much for sharing it with us.
RON AVITZUR: Our pleasure.
[? Valdemar. ?]
AUDIENCE: What do you do now?
What do I do now?
AUDIENCE: Are you still working on this full time?
RON AVITZUR: I'm still working on what is essentially the
first C program I started writing in 1985.
I'm still working on it full time.
You know what software's like.
It's still not done.

Teachers have been using it in this form for
over 12 years now.
I have a very long collected list of requests that they
have. I'm continuing to run down the feature list,
continuing to find ways to improve it without making the
interface more complex.
It's a constant tension between keeping the interface
simple, easy to use, and easy to learn while also being able
to do more interesting and more powerful things.
The fundamental design that I'm trying to reach is one
where, if you open up a typical textbook for some
subject, you'll often see an equation and a picture.
And I want to be able to type that equation as you see it in
the textbook and generate an appropriate picture as a
visualization for that.
And that's a very broad space of problem.
AUDIENCE: So you made this 12 years ago.
Since then, computers have advanced a lot.
And you mentioned that this was the activation that
basically illustrated how powerful the Power PC was.
And has it changed a lot in the past 12 years?
Have you taken advantage of the many generations of
hardware improvements that have come since then?
RON AVITZUR: The question is that the original graphing
calculator, 1.0, was now 12 years ago.
And hardware has improved enormously in the last 12
years, just as it did in the 10 years between the original
Macintosh and the Power PC.
And have you taken advantages of the improvements in the
hardware since then?
That's part of why I'm continuing to work on it.
Each new speed bump in available hardware enables new
kinds of visualization.
And I'm absolutely in love with the modern
generation of GPU's.
You often have far more horsepower sitting on your
graphics card, which is useful in a completely general
mathematical way as a general SIMD computer, single
instruction, multiple data, to do vast amount of
computations quickly.
One of the features I'm particularly proud of in this
release from a couple of years ago, it will take equations
you type, and on the fly compile them into GPU
programs. So that, as well as using the CPU to render the
3-D image, it will use the GPU to texture that, based on the
explicit equations that you'ved typed, compiling it on
the fly for the GPU.
With each new generation of hardware and each new
improvement, it enables new kinds of visualization and
enables new things in the classroom.
So yes, absolutely.
AUDIENCE: I have a couple questions.
The first one is do you know why Apple stopped using your
program and they made the switch to a different one?
RON AVITZUR: The first question is, do I know why
Apple stopped including our graphing calculator and
acquired Grapher from a Swiss company.
I can't speak on behalf of Apple.
I could only speculate.
And I wouldn't want to speculate.
I expect part of the reason, certainly, it took us a very
long time before our Mac OS 10 ten
native release was available.
It was actually available before they released Tiger.
But that was at least part of the issue.
I don't know fully what was going on back there.
I'm actually very much out of touch with Apple.
I don't know what goes on behind closed doors there.
AUDIENCE: My second question is, I'm just curious, what do
you think the coolest feature of your
graphing calculator is?
RON AVITZUR: What do I think the coolest feature is?
There's two parts to that.
Fundamentally, I still think the coolest thing is the very
boring thing.
Just the entirely useful and 2-D work that you could do 20
years ago on old hardware.
That you can just type sin x and immediately get a useful
picture without a lot of dialogues, without a command
line, without a lot of interface in your way.
That you can just focus on the math and say,
what's going on here?
And that's not flashy or whizzy and could have been
done a long time ago and worked fine on 68k machines.
But in terms of being actually useful in the classroom, what
I think is most cool about it is that teachers can bring
this up on an overhead, and, without preparation, type
something in, get a pretty picture, and then move on with
the rest of the lecture, having spent 30 seconds on it,
without having to focus all of their attention on OK, I'm
going to use the computer now.
Wait while I get things set up perfectly.
And let's hope it actually works.
Being able to do something that a teacher can use in a
hectic classroom with their attention split and without
having time to prepare everything advance, in my
mind, that's what's most interesting.
Now, as a technical person, though, the other side of
things is, as a programmer, there's a lot going on under
the hood to make things fast. Because the fundamental
question I keep looking at is, given whatever today's state
of the art in computer hardware speed is, what can I
do with that speed in a fluid way?
What can I do that speed that happens
with immediate feedback?
And that keeps changing.
And most recently, all of the evolution of the GPU towards
putting all of this amazing floating point computing power
and parallel hardware on your video card lets you do really
nice things.

And so, again, if anyone here would like to play with it,
just email Greg or I.