make began with programmers debugging fixes they had forgotten to compile

The fix was already in the source. The executable hadn’t heard about it. Stu Feldman and Steve Johnson kept losing time to that particular arrangement, in which the programmer does the work and the computer politely runs something else.

In his 1989 oral history, Feldman describes the problem as “debugging a correct program.” The wording is deliciously cruel. You can investigate perfectly good logic for hours if the machine is still executing its older, broken version.

Feldman’s route into it began with a materials-science program. He had volunteered to rewrite an unsatisfactory PL/1 application, then became involved in a larger Ratfor program supporting calibration work. This was practical software with real users, rather than an exercise invented to demonstrate a build tool nobody had yet requested.

As the program grew, changes stopped being easy to keep straight. Feldman would kick off a complete recompilation before driving home. The machine could spend the commute and dinner doing the work. Rebuilding everything provided some reassurance, with the slightly inconvenient requirement that dinner become part of the development schedule.

Johnson then arrived complaining about another morning lost to the same mistake. Feldman had already been bothered by it; somebody else’s frustration provided the final push. They discussed what the tool should look like, and Feldman started making it. No grand rollout ceremony appears in the account (mercifully for everyone).

The problem called for tracking what needed rebuilding. That changes the question a programmer has to remember. Instead of mentally keeping every dependent piece current, the build description makes those relationships something a tool can act on. The human still has to describe them correctly. Automation is quite capable of preserving an incomplete set of instructions.

Feldman says the early program aimed at his own problem and Johnson’s. It attracted other users, acquired additions, and got rewritten after macros entered the picture. He was unsentimental about some design decisions. A useful tool can spread while its author is still discovering which parts he wishes he’d done differently.

One especially recognizable consequence followed adoption. Feldman describes reluctance to disrupt even a small user community. Once other people build their daily work around a tool, changing an awkward convention carries a cost beyond fixing the original code. The shortcut gets coworkers, and suddenly it needs a calendar invitation.

His recollection is loose about the exact origin year, putting it around the mid-1970s. There is no benefit in turning that uncertainty into a precise anniversary. The durable detail is the failure he was trying to remove: edited source and tested output had become two different versions of reality.

That same confusion can turn up wherever an old output survives a changed input. A generated document, cached frontend bundle, or copied configuration can look perfectly plausible while belonging to yesterday’s work. Tracing the output back to its input remains useful even when the build tool is doing its job. The next stale file still needs somebody to notice.