The programmer who was paid for writing negative code
In 1982, Apple programmer Bill Atkinson was tasked with optimizing the QuickDraw graphics engine for the Lisa computer. He rewrote the software, making it run six times faster while stripping out redundant code. When Apple management required employees to fill out a weekly progress card listing the number of 'lines of code generated,' Atkinson humorously wrote '-2000'. His managers quickly realized that fewer lines often meant cleaner, more efficient software.
The Illusion of Measuring Code by the Line
In the early days of personal computing, corporate management frequently struggled to evaluate the productivity of software developers. Unlike manufacturing lines where output can be tallied in physical units, programming operates on abstract logic. In an effort to standardize oversight, technology companies frequently turned to a straightforward, quantifiable metric: the number of lines of source code an engineer authored over a given period.
This metric rested on a flawed assumption that more code inherently translated to more progress. In reality, programming does not scale like physical assembly. A software engineer can write hundreds of bloated, inefficient, and bug-ridden lines to accomplish a task that a more skilled engineer could resolve with a dozen well-crafted statements. Measuring volume encouraged verbosity over clarity, penalizing those who took the time to simplify complex architectures.
Atkinson and the Lisa Project
Bill Atkinson was one of the central figures behind Apple's graphical user interface development in the late 1970s and early 1980s. Working on the Apple Lisa—and subsequently the original Macintosh—Atkinson was tasked with creating the foundational 2D graphics engine that would render every window, menu, icon, and character onto the screen in real time.
This graphics engine, named QuickDraw (initially developed under names like LisaGraf), faced severe technical hurdles. The Motorola 68000 processor powering these machines had strict memory and computational limitations. For a graphical interface to feel responsive to human interaction, visual elements had to update almost instantaneously, demanding extraordinarily lean and highly optimized software routines.