Bill Atkinson got two weeks to prove Apple needed Pascal. Lisa used the result.
The programmer’s own recollection connects a disputed Apple II tool project with the assumptions later built into Lisa.
Apple BASIC didn’t even have local variables, and Bill Atkinson wanted reusable software modules. His manager said no to bringing UCSD Pascal to the Apple II. So Atkinson went to Steve Jobs, who also needed convincing.
Jobs gave him two weeks. Atkinson describes boarding a plane to San Diego within hours and returning with a working port. In his first-person account, the system Apple shipped later helped bootstrap Lisa development. Pascal had cleared the BASIC objection. Yes, the language joke was sitting right there.
This is Atkinson’s recollection of his own work, which matters when reading it. It establishes the time limit and the result he reports. It doesn’t supply a timesheet, a complete porting history or proof that every disputed tool deserves an emergency flight.
His stated requirement was software built “in a cumulative fashion with libraries of reusable modules.” That is a more useful description than calling one language better. Someone maintaining the fifth program has a different problem from someone demonstrating the first one: changes need a place to live where another program can use them.
A two-week demonstration also asks a decision-maker to judge something concrete. Can the system run? Can it support the work being proposed? Those questions have a different finish line from an argument about which language developers should love. Passion gets a meeting; a running tool gives the meeting something to look at (a welcome development).
Atkinson’s account follows the port into a second decision about what software could assume. He argued that Lisa should include a mouse, because optional Apple II paddles couldn’t be counted on. An interface designed around a pointing device needs that device in the box. Otherwise somebody still has to make the graphics editor work with cursor keys. The accessory aisle starts writing the interface.
The connection is useful to anyone choosing what belongs in a product’s default setup. A capability available as an optional part carries a support question: does this particular person have it? Making the mouse standard answered that question before each application had to ask it again.
Future tools face the same practical negotiation whenever a promised capability depends on an optional service or separate purchase. A product team can test that dependency directly: give the proposed setup to someone who lacks the extra and watch what task stops. The resulting decision concerns a real missing part, rather than a feature list with a cheerful footnote.
That doesn’t turn a successful gamble into a universal management method. Atkinson reports a particular exception granted to a particular person. A useful prototype makes the uncertainty smaller; a deadline alone supplies no missing engineering. The account leaves the amount of unfinished work behind the working demonstration unquantified.
Lisa got a head start.