Kent Beck on Trust, Stupid Ideas, and Why Nobody Knows the Playbook Yet
The Pragmatic Engineer
Kent Beck created Extreme Programming, pioneered test-driven development, co-created JUnit, and signed the Agile Manifesto. In this long conversation on the Pragmatic Engineer podcast, recorded in person in Budapest just before Craft Conference 2026, he walks through his whole career for the first time in one sitting. The thread running through it is a claim he opens with: software engineering was never mainly about typing code. It is about building understanding and trust, between people and in the program. His position on AI follows from that. Coding agents change some of the activities, but nobody yet knows how engineers should work with them, and that is exactly the kind of moment he enjoys.
"We're accumulating code faster than we're accumulating trust"
The host opened with a viral post by Dario claiming that coding would go away first, then all of software engineering. Beck's response was blunt: that is "a statement by someone who doesn't understand software engineering." Coding is only a small part of the job, even if it takes a lot of time. While coding, he said, you are building confidence, building connections with other people, and building your own understanding. Programming is also a good way to cement understanding: the more you program, the better you understand the domain.
He built on a phrase he had recently come across: we are accumulating code faster than we are accumulating trust. In his account, trust comes from struggling with a domain concept, representing it in code, and writing tests that show you really understood it. Then you trust the program. Programming together builds trust between the people involved. Going back and forth with an eventual user, asking what problem they are really solving behind "I want a button that does this," builds human trust too. None of that can be automated, he argued, and none of it happens when you prompt an AI and "the genie" answers that it's all finished. His reply to that is: "finished what?"
The host pointed out that when Beck described software engineering he mentioned trust, connection, and understanding, but not languages, technologies, or even refactoring. Beck called this "the biggest cosmic practical joke ever." As a young person who didn't understand humans well, he felt promised that if he completely understood the computer, he'd be fine. So he spent the first part of his career trying to become the best programmer he could. Then he found that his ability to change things in the world depended on communicating, empathizing, convincing, and soothing other people. Those were the skills he thought he didn't need, and he had to learn them starting ten years behind. Empathy, he said, is "not my natural strong suit."
A childhood with Nixie tubes and instruction manuals
Beck's father was an electrical engineer. He had been a Navy radio operator in the Korean War and later worked in aerospace. The family lived in Sunnyvale when there were still cherry orchards along El Camino. When Beck was in sixth grade, his father brought home a programmable calculator that weighed around 65 or 70 pounds and displayed numbers with Nixie tubes, incandescent bulbs with ten filaments shaped like digits and stacked one in front of another. Beck's first program was a loop that counted up and down so he could watch the digits move back and forth, which he did for hours.
Before that he had obsessively read books his father brought home, including the Burroughs B6700 instruction set manual. He found a copy again recently during a move. It fascinated him because the machine was stack-based rather than register-based. He admits he understood nothing of it at the time. Getting his hands on a real machine he could program in something like assembly language is what hooked him. If he understood the mechanism, he could turn an idea in his head into something real, which would spark the next idea. That loop of creative impulse plus knowledge of the machine has always felt great to him, he said.
He described the progression that followed. Handheld calculators arrived, like an HP-35 his father bought for $400 that forced you to keep the operand stack in your head. Then the programmable HP-45. Then microprocessors like the Z80, 8080, and 6800. He and his father soldered together a 6800-based machine and programmed it in assembly, and later BASIC.
Oregon, music, and a reluctant master's degree
Beck went to the University of Oregon, he says, because none of the other places he applied to accepted him. His first year was computer science. He found the classes easy but wasn't yet a great programmer, and he got bored. Before his sophomore year he saw audition flyers in the music building, and since he'd played guitar obsessively since age eight, he soon became a music student. He alternated between music and programming, finished a senior recital, and then went back for a master's in computer science.
His thesis was on a novel query language. He struggled to finish it, partly because he "did not get along with the authority figures," which he called a theme of his career. By then he was making a good living as a programmer and saw the requirements as hoop-jumping. People told him he'd regret not finishing. He did finish, though he says the degree never helped him "one bit as far as I can tell." He still thinks finishing things matters, even for someone like him. He quoted Jesse Jackson: "I'm a tree shaker, not a jelly maker."
Tektronix and the Smalltalk ethos
His first programming job came when a team from Tektronix's industrial research lab visited Oregon to present their programming-environment research. Beck asked questions they couldn't answer, which led to dinner, an interview, and a job. Tektronix had invested early in Smalltalk, and he quickly left the research project he'd been hired for and dove into Smalltalk.
He pointed to Dan Ingalls's paper "Design Principles Behind Smalltalk," which opens by describing Smalltalk as computer support for the creative spirit in everyone. It had two sides. One was the programming language. The other was a language of interaction: overlapping windows, mice as pointing devices, panes, scroll bars. What Beck found beautiful was how few primitives the language had. By his count there are three: sending a message, assigning a variable, and returning a value. Everything is an object, including numbers. Addition is a + message sent to an integer. Even conditionals live in the library rather than the language: you send ifTrue: with a closure to the true object, which evaluates it, while false ignores it. That means you sometimes need to be clever to understand things, but when it's time to build abstractions, special cases don't get in your way. On reserved words in other languages, he joked: "how rude."
Smalltalk also carried an ethos of ownership. There was no compile-and-link step. You could interrupt a running program, drop into a debugger, walk down the stack, fix the code, and continue. If the debugger lacked a feature, you added it. Pop-up menus deliberately showed every available option to teach users what else was possible. Beck acknowledged the downside: with a hundred people on one program, everyone can't be changing everything in incompatible ways. For a personal computer that you understand and command, though, it worked well.
Why Smalltalk's rise stalled, and a familiar promise
Beck said the full story of Smalltalk's decline includes business decisions he wasn't part of. But he described the hype around objects in terms the host immediately recognized from today. Objects would make programmers so productive that fewer would be needed, and ordinary people could write their own programs. To a degree this came true. Tektronix sold a workstation bundled with Smalltalk, and chemical, structural, and hydraulic engineers would proudly show off systems they had built. On the surface they looked fantastic. Underneath, Beck said, the code was "a horrible unmaintainable mess." Even so, he saw it as a real step forward compared with the alternative of writing a thousand-page requirements document and waiting eight years not to get what you wanted.
The host compared this directly to people outside software building programs with AI today, where corner cases go uncovered and code is hard to evolve. As for Smalltalk, Beck said alternatives were easier to approach. Its keyword syntax was unusual. C++, originally "C with objects," looked familiar and had a compiler people were used to, even though its design philosophy was the opposite of Smalltalk's: many complicated mechanisms rather than a few general ones.
Pairing with Ward Cunningham, HotDraw, and naming things
At Tektronix Beck met Ward Cunningham, who later created the first wiki. They taught a Smalltalk class together, and Beck began sitting next to Cunningham while he programmed. He described himself as a "24 year old punk with attitude." Cunningham was the better low-level programmer and at first didn't let him touch the keyboard. Beck started by pointing out unbalanced parentheses. Over time he absorbed the low-level patterns and began suggesting ideas Cunningham didn't immediately grasp. Then he would take the keyboard to show what he meant and hand it back. Over a few months they developed a style of passing the keyboard back and forth and talking at several levels at once: why isn't this code working, should we be working on this at all, what tools would make it easy, what should the design be, and should we be doing this philosophically.
They settled into a weekly rhythm. Monday coffee to pick a thing they wished existed, Tuesday and Wednesday building, Thursday demos and refinement, Friday a tech report. Even failed weeks produced an understanding of what would be needed to make the idea easy later, and that went "into the hopper" for the next Monday.
One result was HotDraw, a framework for graphical editors. The name came from a moment when they drew overlapping rectangles, selected every other one, and dragged them with smooth animation at about 10 hertz. They found it "so hot." Before that, smooth animation had been bespoke work. With HotDraw you subclassed a figure and got behavior in a two-and-a-half-D world. Figures, handles, and connections were meant to carry domain meaning, like a handle that raises temperature. Beck said the vocabulary of figure, handle, and drawing was Cunningham's; his own names had been "pedestrian." They kept a physical thesaurus to find the right words, and Beck admitted they were at the far end of the obsessive scale. He tied this to a larger point: part of a program's purpose is to communicate intent to other humans, and now to models too. He thinks we understand the human side much better, whether or not we apply it, while "we don't understand at all how to communicate effectively to models."
Patterns from architecture
Beck had discovered the architect Christopher Alexander in college. He couldn't afford The Timeless Way of Building, so he read it standing up in a bookstore over several visits. Later he found Notes on the Synthesis of Form at Powell's in Portland. Cunningham had also encountered Alexander. As Beck described it, Alexander believed buildings would have a certain spirit if the people who lived in them made the design decisions within constraints, rather than an architect delivering a finished solution. The patterns are those constraints: each decision limits the next.
Their first application was a struggling Tektronix project where programmers were writing software for semiconductor test engineers. Cunningham drafted a handful of patterns for designing user interfaces: break the process into windows with panes, one window per task, and panes limited to lists, text, or waveforms, which were things the team knew it could implement. Beck compared this to the history of musical notation, where some of the most complicated music was written right after notation was invented because nobody knew the limits yet. Graphical interfaces were at the same stage. The test engineers designed an interface that was easy to implement and that they felt they owned.
Beck said people get fussed about this transfer of responsibility because designers want to deliver the solution and be thanked. But your understanding of someone else's problem is bounded when you don't have skin in the game. The host brought up the "flyby architect," and Beck offered his own name for it: the seagull, who flies in, makes a lot of noise, craps on everything, and flies off.
Apple, getting fired, and CRC cards
Around 1987 Beck felt he had outgrown Tektronix. He described a gap between how an organization sees you, how you see yourself, and how you really are, somewhere in between. When those gaps get too wide, you have to move. He joined Apple's Smalltalk effort, which went nowhere in his account because what Apple and its developers needed were C and Pascal compilers, not Smalltalk. Many former Xerox people were at Apple then, including Larry Tesler, whom Beck called his "friend," meaning a bitter enemy he respected a lot, plus Dan Ingalls and Alan Kay. Beck moved to Kay's Playground project, a programming language for children that he described as reactive: objects couldn't send messages, only raise conditions others waited on, something like pub-sub as the only control mechanism.
He said he was "horribly ineffective" there and was eventually fired. He was still in punk mode, rejecting other people's ideas in favor of his own, which works alone but not on a team. The final straw was 1989, when he was program chair of OOPSLA, then the hottest conference in the field, and spent a month reading papers instead of working on Playground. His second child was then late in being born, so he missed the conference itself.
CRC cards (class, responsibility, collaborator) came out of a question of that era: flowcharts represented imperative control flow, but with polymorphic messages you don't know what code will run, so how do you visualize an object program? Beck mentioned that he has kinesthetic synesthesia and feels in his body where code "wants to go." Cunningham proposed writing the talk-with-your-hands conversations down on index cards. The central design move, Beck said, is dividing responsibilities by moving computation to where the data lives. When the host phrased it the other way around, Beck corrected it. His example was a rectangle computing its own area, so the rest of the system doesn't care whether it stores two corners or a corner plus width and height. That keeps coupling loose. He thinks the lesson "got lost in the noise," and that much criticism of object-oriented languages isn't really criticism of object-oriented design.
From SUnit to JUnit
Beck's interest in testing started at Tektronix. At the time testing was a status divide: students who got A's and B's became programmers, and those with C's became testers. There was also a tool divide, with testing tools having their own languages. He said he's an anxious person, and the more complex his programs and the more kinds of bugs he knew about, the more anxious he got. He wanted a way to quell that "without pills."
After MasPar, a venture-funded startup building a SIMD machine with up to 16,000 processing elements in a toroidal grid (which he said looks a lot like today's Nvidia architecture, only too early), he became an independent consultant. Needing a way for a Chicago client to write tests the next day, he synthesized several earlier experiments into three classes and about a dozen methods: test case, test suite, and test result. It ran tests in isolation, fully automatically, and summarized the results. That became SUnit, written in Smalltalk.
He believes no one did this earlier because of the adversarial divide between programmers and testers, which encouraged testing tools to be separate worlds. Writing tests in the same language as the code was natural for him because in Smalltalk you represent everything as objects. He admitted the framework "bastardizes" the language a little: methods starting with "test" are treated as magic and run with setup and teardown. Later, on a flight from Vienna to Washington Dulles, he and Erich Gamma wrote JUnit, testing itself with itself, with about two and a half hours of laptop battery and no seat power. After landing they gave it to Martin Fowler at OOPSLA, and the next day people were asking for copies. They handed out 3.5-inch floppy disks as fast as they could.
Chrysler C3 and the birth of Extreme Programming
Methodology for objects had been the "million-dollar question" since the first OOPSLA in 1986. By the mid-1990s answers were emerging, including what became the Rational Unified Process from Grady Booch, Ivar Jacobson, and James Rumbaugh, and Cunningham's pattern language called Episodes, which Beck borrowed from heavily. Beck met Martin Fowler at a methodology workshop in Snowbird, where Fowler introduced himself by saying, "I am the only person here I've never heard of."
At Chrysler, a payroll project important for Y2K was at risk. Beck was brought in as a Smalltalk performance consultant, since the system used GemStone. He asked where the tests were that would keep him from breaking things. When told it wasn't computing the right answers yet, he said, "Well, then I can make it go really fast," which the team didn't appreciate. After an exhausting week of change, he told them to send everyone away for two weeks, throw away the code, and restart. The new process ran on a three-week cadence with test cases specified by the payroll expert. Beck described his approach as taking everything he knew to be useful, "cranking it up to 11," and discarding everything he couldn't prove they needed. He noted that there turned out to be several notches beyond 11.
Once it was going well and he got tired of saying "this new style of working we're doing at Chrysler," he went back to the thesaurus. He wanted a name unattractive enough that Grady Booch, now a good friend, would never claim to be doing it. "Extreme" was a thumb of the nose at the establishment, but he also liked the extreme sports analogy. You don't hop on a snowboard at the top of an avalanche the first time. You need supreme preparation, and then things that seem impossible become possible. "Programming" was deliberate too. Methodologies of the time treated coding as a clerical step between diagrams, but for Beck the moment at the keyboard is where you can no longer fool yourself: either you compute the correct value or you don't. He also called it XP to escape the baggage of both words. He joked about alternate universes in which he sued Microsoft over Windows XP and either won or bankrupted himself.
He credits XP's success to "exquisite timing." As the internet boom took off, companies could see that analysis-then-design-then-code-then-test would never keep up, and that cowboy coding, with pizza slid under the door, wouldn't work either. XP sat in between, with discipline, iteration, transparency, ways to steer and tune, tests, and frequent alignment between business and technical people. After his first talk on it, people were literally tugging at his shirt.
TDD: a stupid idea that worked, then a moral cudgel
TDD grew from something he'd read as a child: to write a tape-to-tape batch program, you first type out the output tape you expect for a real input tape. After SUnit proved useful (Hal Hildebrand, one of the smartest programmers he knew, loved it), Beck remembered that idea and realized it meant writing the test before the code. He laughed out loud because it seemed so stupid. Why write a test you know will fail? He tried it anyway on a stack: push and pop, two pushes in order, dup, top, isEmpty. When he couldn't imagine another failing test, his anxiety was gone, and he felt finished and was finished.
His lesson: always try stupid ideas if you can do it cheaply and reversibly. Ninety-nine out of a hundred fail, but when one works you have no competition, because nobody else was stupid enough to try it. He credits his "punk attitude" with letting him try many such ideas, most of which nobody sees.
On why TDD fell out of fashion in the 2010s, Beck gave two reasons. First, he tends to move on to the next thing. That happened with patterns, JUnit, TDD, and XP. Second, some people used TDD "as a moral cudgel," claiming that if you don't use it you're not professional. He rejects that. People write very good software with many workflows. TDD's sweet spot is rapid alternation between doing and learning, when you know roughly where you're going and know the first step but not the whole path. "It's not a moral decision. It's a practical decision." With agents, he said, TDD costs tokens in the short run but can save them in the long run, because a classic genie mistake is claiming something works when it doesn't.
The Agile Manifesto and the problem with "agile"
Beck described the Rational Unified Process as the "adult" approach of the day. He calls it "neither rational nor unified nor a process," mostly to tweak noses. He conceded that Booch, Jacobson, or Rumbaugh might personally work much as he did, but what mattered was what readers did with their writing, which was waterfall followed by "disaster over and over." Several lightweight approaches, including Scrum and feature-driven development, started getting attacked by vendors selling expensive tools, and their advocates realized they needed to come together. A first meeting in 1999 on a ferry trip down the Norwegian coast to Bergen showed there was common ground but also friction among "people with some healthy egos," Beck not the smallest among them.
Jim Highsmith and Alistair Cockburn then convened the Snowbird meeting. Beck had a bad sinus infection, was on heavy medication, and remembers little, except that it wasn't going well because everyone wanted their own ideas included. During a break, Martin Fowler and Jim Highsmith stayed behind. When the others returned, the format ("we value these things, but we value these things more") and the four value pairs were in place. Beck says he had nothing to do with that "magic moment." His only contribution to the principles is the word "daily" in the line about daily interaction with users. He's listed first only because the names were alphabetical.
The impact was instant, he said, because people were desperate for ways to build software quickly and reliably while keeping options open. Letting the public sign the manifesto made people feel invested. He objected to the word "agile" at the time and still does, because it isn't defensible: nobody claims to prefer rigid or inflexible development, so everyone calls themselves agile. "Extreme" doesn't have that problem, since you won't call yourself an extreme programmer unless you've invested in pairing, incremental design, thorough testing, and building tools. Today, he said, the word agile "not only doesn't mean anything anymore, it means something negative."
He had feared commercialization from the start. The manifesto is only the intersection of the attendees' ideas, and without technical foundations, such as writing reliable software in small pieces, designing incrementally, and preserving optionality, promises of replanning and reordering features are empty. He went back to his snowboard image: falling down the mountain and breaking your body shows "a certain kind of agility," but not the kind they meant. Some people sold the idea that anyone could get "twice the work in half the time." Beck said that's achievable only through hard-won skills that aren't taught in computer science programs or often modeled by first employers, and calling it easy is "just a lie." He sees the genie world replaying this: everyone can be a programmer, but not the same programmer.
The dot-com bust and a lost decade
Beck was living in rural southern Oregon, finishing building a house, when 9/11 hit. He had eight months of consulting booked at rates higher than he can charge today, even adjusted for inflation, and every client canceled the next day just as big bills for the house came due. He burned out and fell into severe depression.
He also described a lesson about boundaries. He had received messages saying JUnit saved someone's life or that he was a genius. Then came messages saying XP had ruined someone's life: they lost their job, their marriage, their home. He came to see that people send out-of-proportion praise or blame because they need a hero or a villain, and that need has nothing to do with him. If it weren't him, they'd write to someone else. Recalibrating his self-image after being told he was more awesome than he thought was a serious reset. For a time he couldn't program at all. He rebuilt by doing Sudoku on easy, then medium, then crosswords, until one day he nailed a programming problem in the then-new Eclipse and realized it was still fun. He calls roughly 2002 to 2011 his lost decade and frames it as a midlife crisis, the moment he realized the masks that seemed to work had never really worked.
Facebook: scale, growth, and innovation without his playbook
In 2011, at around 50, Beck joined Facebook, which had about 2,000 employees and 700 engineers. He thinks he was one of the first remote engineers. He needed the money, with five kids and overlapping college tuitions, and consulting demand had dried up. He was also curious. Facebook used almost none of the practices in his books yet ran a stable site at unprecedented scale while growing and innovating. He had rarely seen two of those at once, never all three. "This is a bumblebee. It can't fly according to my theories."
At his first hackathon he offered a TDD class. The Argentine tango class before it filled up, and so did the advanced Excel class after it. Nobody signed up for his. So he decided to forget what he thought he knew, copy what he saw people doing, and see whether he could relearn software engineering fast enough not to get fired. He stayed seven years.
What made it work, in his analysis, was layered feedback: a Swiss cheese model in which holes don't line up. Engineers could run the whole site on their dev machines and see PHP changes in seconds. There was code review. Frequent internal rollouts meant employees used new features immediately. Phased rollouts limited the blast radius to a few million people. Chuck Rossi's release team secretly rated engineers with stars, and one-star engineers had trouble getting code pushed. Observability showed results after deployment. Beck wrote unit tests for his first feature and still caused a site incident through coupled code he hadn't found. At weekly incident reviews with senior leaders, engineers who presented a timeline, lessons, and prevention steps were fine. Those who blamed others could literally be walked out. Over his time there Facebook became more like a utility. One named incident became notable as the first time people called 911 because Facebook was down.
The culture had little planning and no real deadlines. Beck recalled Zuckerberg asking for photos with four times the resolution. When engineers explained why it couldn't be done, he said he understood but still wanted better photos, and people worked on it for as long as it took, or switched to something else. A former Microsoft colleague told Beck that at Microsoft you defend a good problem because there aren't enough to go around, while at Facebook you move on because there's always another fire. It was opportunity-rich then; Beck says it is opportunity-starved now. During boot camp he printed the entire photos code, an 18-page PHP file for the world's largest photo site at the time, noticed the fetches could be parallelized, and made the change. A week later the photos manager told him ops could recommission enough servers to save $5 million a year. "I was just farting around," he said. It felt like gold nuggets lying on the ground.
He also described pre-IPO incentives. Middle managers with large unvested options optimized globally, sometimes steering engineers to other teams where they'd help the stock more. There were "50/50 goals" in six-month reviews: achieving half your goals earned an A+, achieving all meant you were sandbagging, achieving none meant you were out. That created anxiety but also meant you didn't have to protect yourself from slackers. Of the mission to make the world more open and connected, he said it turns out the world "can be too open and connected."
Good to Great: coaching as productive discomfort
About a year in, struggling on C++ infrastructure for Messenger and not a strong C++ programmer, Beck took a friend's advice to turn the coaching he'd done during his lost decade into his job. Facebook let engineers do whatever they believed in and take the consequences. He started with three students and daily one-hour sessions, which proved far too much. Two did well and one was fired. Word spread, and the effort became a program called Good to Great, aimed at good engineers who had plateaued and needed a kick.
He coached six people at a time, paired senior engineers with juniors as coaches, and ran "coaching the coaches" sessions. His administrator worked with HR on an analysis that found his students were twice as likely to be promoted in the following year as a comparable uncoached cohort. He says he handled the politics poorly, since this was learning and development outside the L&D organization, so the program had both fans and detractors. He estimates he coached about 200 people individually, while thousands went through classes he wrote and others taught. At an offsite for Facebook's top 1% of engineers, about 10 of the roughly 100 attendees were his former students. He described his coaching as uncompromising, not head-patting: coaches exist "to identify and induce productive discomfort." He tied this back to his time with Cunningham, saying that way of learning can't be duplicated. That is why he thinks claims about eliminating software engineering misunderstand what engineers do. Some activities will be transformed, he agreed, and he's "having a blast," but the idea of engineers as code monkeys taking in requirements and Jolt Cola and producing code is wrong. He said he didn't consider Dario's statement disrespectful, just ignorant.
Why engineers keep being targeted for replacement, and learnable soft skills
Asked why people keep wanting to replace developers, Beck said engineers can be off-putting. Speaking as someone on the autism spectrum from a family of engineers, he said people like him often lack emotional regulation and natural empathy, and are more direct than others can handle. He plays poker partly to get feedback on his empathy. "I was just asking a question" is among the most hideous things he says, because he was being a jerk in how he asked. He doesn't expect the world to adapt to him. Reading body language and tone are skills, not natural gifts, and they can be learned well enough to be "not horrible," even if he'll never match his partner, whom he calls a social genius.
His example: when he estimates four weeks and someone insists on two, the options aren't only shrinking or telling them off. He can treat it as an invitation to understand their needs. He described a mental menu of responses, like the Terminator's heads-up display, as better than alienating someone and ending the conversation too early. That is why he draws analogies from finance, sports, and history, in "a desperate attempt" to understand others and be understood.
The genie accelerates development, but not business
On AI, Beck first objected to the host's framing that the understanding and communication in coding are shrinking: "That's a choice." His main observation is that development has accelerated but the pace of business hasn't, and the mismatch will become more visible. At one client, someone vibe-coded a replacement for a SaaS add-on that cost $2 million a year, and the replacement suited them better. Two years ago the vendor would have had three to five years to respond. Now it might have a month, while its chain from customer service through marketing, sales, business development, and product is designed to take years. That isn't AI's fault, he said. His personal definition of agile is "responds in time," and many companies aren't prepared for the new pace. He compared it to being moved from a tractor to a Ferrari on a winding mountain road. He expects some companies to fail, much as newspapers lost classified ads, the revenue that had paid for reporting. Businesses that relied on switching costs will see those costs drop to zero, and he expects their profits to follow.
The flip side is naive replacement. People vibe-code the visible tip of an iceberg. Drawing on his three years at Gusto, the small-business payroll company, which he acknowledged was talking his own book, he described someone claiming they no longer needed Gusto because Claude could compute their paycheck. Beck's answer: run your own payroll for a quarter and then figure out all the filings across tax agencies and states where you live, work, and are incorporated. Correct, compliant payroll involves far more than gross and net pay.
Explore, expand, extract: why nobody knows
When the host asked what engineers should do as tools take over much of the craft, Beck's "inspirational motto" was: nobody knows. Asked how TDD applies to augmented coding, he says it isn't just that he doesn't know. Nobody knows.
He explained with the 3X model he worked out around 2015–16 to understand how Facebook could be large, growing, and innovative at once. It did this by running projects in different phases in completely different styles. In explore, you can't predict, so it's a numbers game: run as many cheap, uncorrelated experiments as you can. In expand, something takes off, and you focus intensely on it, discard everything else, and overcome obstacle after obstacle. This can be unsustainable, but it doesn't last long. In extract, growth is predictable, economies of scale apply, small tweaks matter, and you have a playbook, like rolling out to a sixth country after five. How you code, manage, hire, and organize differs completely across the three.
For about 20 years, in Beck's view, the industry has lived in extract, with a known playbook for things like too many production bugs or scaling backends, and being senior meant knowing it. That playbook has been wiped clean, and people whose identity is "I know the playbook" are terrified. Writing a playbook is a different skill from applying one, he said, and it's what he and his peers did during the object era. There is no secret playbook for genie-based development available for a million dollars. The glimpses people get change weekly because small input changes produce large output changes. So when someone asks whether writing many tests at once instead of one at a time would work, his answer is: nobody knows, try it and report back. A playbook emerges when many people try things and compare notes, for example one person finding a markdown file helped and another finding it made things worse, and then working out what differed.
He noted that the first OOPSLA was in 1986 and the Agile Manifesto in 2001, fifteen years of daily use of a technology before anyone could state its consequences simply. When he sees AI manifestos now, his reaction is "too soon." Not a bad idea, he said, just not manifesto time yet.
What excites him now
Beck called this moment "home base": writing the playbook, shaking the tree. He's working on many projects. Arlo is an object-oriented database. He's also building fundamental data structures, partly to see whether he could write library-quality code in a language he didn't know. He built a B+ tree that he reports is faster than Rust's B-tree for some operations, while noting he's no Rust expert and wondering what one could do with the same tools, and why they hadn't. He's also exploring an adaptive radix tree, planning a new Smalltalk from scratch because that is now "within reach for anybody," building small apps, using the genie for business planning around his newsletter, and doing a lot of reflective writing.
If there's a secret sauce, he said, it's not being afraid to start over. His GitHub is full of "project," "project two," "new project three," and so on. He pushes an attempt until the genie runs out of options and can't make further progress, then wipes it and restarts with a different implementation order, a markdown file, or a commit hook, rather than tweaking. Some stupid-sounding ideas will work out great and some will be disastrous, but if you're willing to start over, you aren't risking much.
What has returned for him is the creative impulse from his childhood: imagine something, like a B+ tree in Go, sit down with the genie, and end up with an artifact that didn't exist before. He had grown fed up with the minutiae of programming, like version upgrades that break something else, and getting emotionally invested in an idea only to be blocked "for no good reason." That blockage doesn't happen to him now. He has "40 years worth of ideas" that had been too big, all back in play, and he says he's having so much fun making things that are real.
The human part is the hardest part in software engineering.
This is the biggest cosmic practical joke ever. We were promised here's this computer and if you completely understand this computer, you'll be fine. That's all you need to do.
When did TDD come along?
I was just kind of farting around and I would write the test before I wrote the code. And I can remember laughing out loud cuz it was such a stupid idea. Why would you write a test that you know is going to fail? TDD is a good example where it almost went out of style completely. The big part of it is I work on something for a while and then I switch to something else. I moved on to the next thing. TDD is out there and then there were people who used it as a moral cudgel, like if you're not using TDD you're not professional.
Extreme Programming was born. I didn't want Grady Booch to ever say that he was doing this thing. So I had to pick a moniker that was unattractive enough that somebody wouldn't try and steal it. A little bit of thumb the nose at the establishment. Extreme sports were there. I like the analogy with extreme sports. 17 people rolled, but you're the first one listed. The Agile Manifesto.
Things weren't going very well because there's all these people and I want my stuff in. No, I want my stuff in and that contradicts your stuff. And we took a break. We walked out and Martin and Jim Highsmith stayed behind. When we came in from the break, there was the basics of the manifesto.
For a couple of years, we've had AI alums. So, one of the things is that the pace of development is definitely accelerated. One thing I wonder
Kent Beck is one of the living legends of the industry. He's greatly shaped the software engineering profession and keeps impacting it even today. But there's not been a podcast episode covering his whole career from start to present until today. In this conversation, we cover how Kent grew up with computers in the 70s and how he fell in love with Smalltalk. The origin stories behind TDD, Extreme Programming, and the Agile Manifesto and why Agile, the word, was a mistake. Lesser-known stories like how he got fired from Apple, Kent's lost decade in the 2000s, and why he thinks TDD has failed, how he thinks about and uses AI and what still excites him with coding after 40 plus years and many more. If you'd like to understand how a true legend was shaped by the industry and shaped software engineering himself, this episode is for you. This episode is longer than most of my podcast episodes, and I do hope that you'll find that it's worth the time to listen to Kent longer than he's ever told his story in one setting before.
This episode is presented by Antithesis. If you work with agents, your job is no longer just writing code. It's specifying and testing it. And Antithesis is the most effective method of verifying agentic code today.
This episode is brought to you by turbopuffer. A fun fact about turbopuffer is how they become the search engine for AI agents. It seems like every week they add a new use case from one of the leading AI companies. RAM, Lorra, Harvey, Granola, they're all on turbopuffer. Or as the team likes to say it, they're all puffing. turbopuffer offers a full set of search tools: vector search, full-text search, attribute filtering, regex, and more in one API. It's built on object storage as a sole stateful dependency. So, it's extremely scalable, reliable, and cheap. But it's also very fast thanks to its intelligent caching layer. One cool thing about turbopuffer is you can have unlimited search indexes. So, it's perfect for multi-tenant AI applications. Build an index per tenant, data is isolated by default, and you can scale without thinking about it. Here's the best part. turbopuffer just announced last week that they've dropped their base price from $64 per month to $16 per month. So, there has never been a better time to test it out. Head to turbopuffer.com/pragmatic.
And it's so good to have you in person on the podcast.
Guy, it's great to talk to you again.
Yeah, I wanted to kick off with something really timely. There was this tweet going viral by Dario where he said, I quote, "Coding is going away first, then all of software engineering." You had some things to say about it.
Yeah. My response is that that's a statement by someone who doesn't understand software engineering. Coding is part of what you're doing, but it's only a small part of what you're doing. Even if it takes up a fair amount of time, you're building confidence, you're building connections with other people, you're building your own understanding. All those things are happening while you're coding. And coding's actually a great way to cement understanding. The more you program, the more you understand the domain that you're working in. So to say, well, we're just going to pass all that off to a machine. Well, that's not all there is to it.
Interesting, because one thing that is so obvious with LLMs is they just code really quickly, right? It used to take us a lot of time to both type it out and also think it out, but you're saying that there was thinking involved and understanding involved as well in that process.
Right. So a couple of days ago I saw a phrase and it really hit me that we're accumulating code faster than we're accumulating trust. And that sense of trust comes from me struggling to understand some domain concept. I get it. I represent it in the code. I write tests that demonstrate that I really did understand it. And now I trust my program. But if we're programming together, that act of programming together means that we trust each other more. If we talk to someone, an eventual user, and we demonstrate that we understand their needs and, you know, they tell us, "Well, I want a button that does this." We're like, well, what problem are you really solving? And we go back and forth and back and forth. That builds human trust as well. None of that can be automated. None of that occurs if we prompt the... we get the finger guns, you know, the genie goes, "Yeah, it's all finished, boss." And it's like, "Well, hang on. Finish. What's finished?"
As we're talking about software engineering, you mentioned trust, connection, understanding. You didn't mention technologies, you didn't mention programming languages, you didn't even mention refactoring. This is really interesting. You've been doing this for what, 50 plus years now. Do I understand that the human part is the hardest or most important part in software engineering?
This is the biggest cosmic practical joke ever. As young people, some of whom, like I, don't understand humans very well, we were promised, okay, here's this computer and if you completely understand this computer, you'll be fine. That's all you need to do. So I set out the first part of my career just to become the best programmer that I could be because that's what it would take to be successful. And then, woo, sorry, there's this whole human side, and your ability to effect change in the world is gated by your ability to communicate with, empathize with... empathy, not my natural strong suit... to convince, to communicate with, to soothe, to understand other human beings. And those are exactly the skills that I thought I didn't need to learn. So I was promised just understand the computer, and then just kidding, understand people, from a position where I was already 10 years behind.
So I'd like to go back to right there, to the very beginning, cuz so many people know you from your books, from a lot of the techniques that you've co-created or made a lot more popular: XP, TDD, a bunch of other just small refactorings and so on. But going back, how did it all start? How did you have your first contact with computers? I know your father was an electrical engineer.
Yeah. So, my father started out as an electrical engineer. He was in the Navy in the Korean War as a radio operator. Came out of that, went to school, got an electrical engineering degree, started working in aerospace as an electrical engineer, and then we moved to Sunnyvale, Silicon Valley before it was Silicon Valley. This is before the invention of Silicon.
Oh, this was before.
Yes. Before there was... this is when there were still cherry orchards on El Camino. And I was born there about the time... So I was in sixth grade. He brought home a programmable calculator which was, not as big as this table, maybe half the size of this table.
Probably weighed
65 or 70 lb. Yeah.
65 lbs.
And it had Nixie tubes. A Nixie tube is, this is before seven-segment LEDs cuz LEDs hadn't been invented. You'd have an incandescent light bulb with 10 filaments in the shape of the numbers. And my first program was a loop that would just count up and down and up and down because the filaments were set one in front of the other. 0 1 2 3 4 5 6 7 8 9. So, I just wrote a program that would count up and down cuz I loved watching this go back and forth and back and forth and back for hours. I could just...
Mesmerizing. Oh,
absolutely. That was the first time I had my hands on any real hardware. Although I did find my dad would bring home books, and I was a kind of obsessive, spectrumy kind of kid. I would obsessively read these books, and I found one of them lately during a move, the Burroughs B6700 instruction set manual. And this was a really interesting machine to imprint on early because it has a hardware stack. It wasn't register based, it was stack based. How they did that with discrete transistors, I will never know. But it's just a really interesting architecture. And that book, I would just read the pages over and over and I understood nothing, but I was just fascinated with this mechanism. So when I got an actual machine and I could play with it, and something that resembled assembly language, and I could get it to do stuff, I could have an idea in my head, and if I understood this mechanism, I could get it to do the stuff in my head, which would spark the next idea.
That's what really hooked me, is that creative impulse coupled with knowledge of the machine. Together I could create things in the world that I wanted to see.
And this was very early '70s, right?
'72, maybe.
So Microsoft wasn't even founded; it was founded in '75.
What was it like in terms of how common or uncommon were these machines, how much or little did you even think that they would go anywhere, or was it just a fun thing that had just been invented?
Probably the first wave of miniaturization was the programmable calculator.
So the one that your dad brought home.
So no, the handheld calculators. Okay. So the big tabletop calculators was one thing, but then there were these little calculators. I remember my dad buying an HP-35 for $400, which I have no idea how much that would be today, but a lot of money just for this little thing.
It'll probably $2,000 location.
Yeah. So you had to keep the stack in your head of what order do I want to put the operands in, and make sure that I stack everything, and then you go plus, and that would pop stuff off the stack. And then the HP-45 came along and it had its own little programming language in it, and that was just like, okay, this is really, really cool. And then microprocessors started to come out and we had the Z80 and the 8080 and the 6800, and my dad and I soldered together our first 6800-based machine. Then we were programming in assembly language. Then out came BASIC, then
This was mid-'70s.
Yeah. So that was really... I was spending a lot of time working on that machine. Again, I wouldn't say I understood it at an elite level, but I was fascinated. Everything I could learn about it made me that much more effective at that creative impulse: imagination of a thing in the world, execution, there's a thing in the world. And that just has always felt great for me.
And then when it came to college, you chose University of Oregon, right?
Well, University of Oregon kind of chose me because none of the other places I applied accepted me.
No way.
Yep.
And what did you study there? How did your college years go?
Well, the first year was computer science. And
So they already had computer science.
Yes. Yes. We had invented computer science by then. The first year was CS, and I enjoyed it, but I still wasn't a great programmer, but classes I breezed through. So, I was a little bit bored. So, before the start of my sophomore year, it was really hot and I was walking through the music building and there were some flyers for signing up for auditions. I thought, "Oh, I play guitar. Let me see what I can do." Next thing I knew, I was a music student.
Wow.
So, I'd been playing... I started playing guitar when I was eight, kind of the end of the folk boom. Mrs. Card at a summer school class, and there was a guitar laying around at our house. And so I went and, again, just obsessed. She'd show us something and I'd go home and I'd play it until my fingers bled and come in the next day, and everybody else was kind of where they were before, but I would have mastered some picking pattern, some strumming pattern, because I just played it for three, four hours. So, I was very into music, and in high school I was in the choir, which was the big deal. We didn't have a lot of sports at our high school, but we certainly had music. It was kind of natural that I would study music. At the end of a year of music, I missed programming, so I went back to programming. Then I went back to music so I could do my senior recital. Then I went back to programming for a master's degree in another year and finished that. And so, as I say, I just ended on the wrong year.
Yeah. Because I checked, I think it was eight years in total that you spent at Oregon, at University of Oregon.
5 years full-time and then I had a hard time finishing my master's thesis.
Why did you have a hard time? What was your master's thesis on?
It was a novel query language. Not surprisingly, I did not get along with the authority figures, which is a theme of my career. Yeah. Just had a hard time checking off all the boxes and getting the whole thing finished. People said, "Oh, you're gonna be sorry if you..." I was just ready to quit. Just like, "Yeah, you know, this is all hoop jumping and has nothing to do with programming," and I was making a good living as a programmer by then. So, "Oh, but you're going to regret it if you don't get your degree. If you don't finish, you're so close." And it's never helped me one bit as far as I can tell.
So, but you completed it.
I did complete it. It is important to complete things. In that process from vision of thing in the world, to careful activity, to the thing in the world, there has to be some finishing, even if I'm, as the Reverend Jesse Jackson said, a tree shaker, not a jelly maker. And that's definitely me.
Yes, it's true for your work as well, also for software.
Well, I keep switching topics. That's something that'll probably come up as we go through the various things that I've worked on.
What was your first job? It was while you were still finishing your degree, the last few years. You started to work as a programmer, right?
Correct. So during that graduate student year, a team from Tektronix came down to give a presentation about the programming environment work they were doing. Tektronix started out as an electronic test equipment company in Portland. Did well in their little niche, but they opened up an industrial lab, as lots of companies at that point did, to do basic research, and part of that basic research was on programming environments. They came and gave a presentation. I asked them questions they couldn't answer, and so they invited me out to dinner, which led to an interview, which led to a job.
Tektronix was an interesting one because this is where you met Ward Cunningham, right?
Yeah. So, Tektronix had invested
early in this crazy object-oriented programming language called Smalltalk and was trying to make a commercial go of it. And I got there and looked at the research that had been presented down at Oregon and it kind of played itself out. But this Smalltalk thing, wow, that's cool. So I dove right into that.
For those of us who have not touched Smalltalk, might have heard of it. What made Smalltalk such a hit? What pulled you in? What is the language like?
There's a beautiful paper called the Design Principles Behind Smalltalk by Dan Ingalls and the opening line is "Smalltalk is computer support for the creative spirit in everyone," which had two big themes. One was a language of programming, the Smalltalk language, and another was a language of interaction: overlapping windows, mice as pointing devices, panes, scroll bars. Those were all things that were pioneered out of the user interface. Those things are kind of ordinary today.
But Smalltalk, the language, was built out of a very small number of primitives. There's really only three primitives in the language: sending a message, assigning a variable, and returning a value. And that's really all that there is. And so, maybe towards the end we can talk about my current projects, one of which is to build a new Smalltalk from scratch, just because now that's within reach for anybody.
But what I found beautiful was that the language pushed its own mechanisms to the absolute limit. So everything is an object in Smalltalk, including numbers. You don't call a function that adds two integers. You send a message plus which is received by an integer and takes another object as a parameter. If that other object happens to be another integer, then you add them together.
This leads to interesting things like there are no control structures defined. So if-then-else is not part of the language. It's part of the library, because you send the message ifTrue with a closure to true and it evaluates the closure. You send the message ifTrue to false with a closure and it does nothing. Just returns null. Everything is built out of the same kind of substrate. There's very few special cases in Smalltalk, which means that sometimes you have to get clever to understand things like how do conditionals work, but also when the time comes for you to build abstractions, you don't have a bunch of special cases getting in your way.
It is a different way to think, especially looking at the modern programming languages where the language comes with so many things built in, even if we're thinking of later languages like Kotlin or Swift or any of them. They have things like control structures and reserved words.
Why would you reserve words? How rude. The programming language should give me as much vocabulary as possible.
But I do notice that with Smalltalk, the people who have used it just get really, really passionate about it and love using it. And I understand, doing my research, that there was a time for a few years where it started to become a lot more popular. Can you tell me why it got more popular and then what happened? It seems to have kind of fizzled out.
Yeah, longer story. Some of which I was not privy to. Some of which comes down to business decisions. Objects were hopping. We'd been programming with the previous generation of languages, COBOL, Fortran, C, Pascal, for a long time and we were used to the constraints that those provided, and along came these objects and objects were going to change everything. People were really, really excited, but, you know, objects were going to make programmers so much more productive that we wouldn't need nearly as many programmers. And in fact,
Really.
Yeah. And you know, it's so much easier to program with objects that ordinary people can write their own programs. They don't have to.
I've heard this recently. [laughter]
Exactly.
But seriously, this was what they were saying, inside of the industry, this was a thing. Use objects or Smalltalk and do more with less programmers, cheaper, the works.
Yeah. And to a degree it was true. People would come in. There weren't workstations. Tektronix built a workstation and started to sell it with Smalltalk bundled in it. And technical people, but in different domains, like chemical engineers or structural engineers or hydraulic engineers, would come in and show us the systems they built with Smalltalk, and on the surface they looked fantastic, and oh, they were so happy, so proud of their baby. You look underneath, though, at the code and it was just a horrible unmaintainable mess.
But the fact that people could program the programs that they wanted was a significant step forward, as opposed to "I'm going to write a thousand-page requirements document and then wait 8 years and not get what I want," which was the alternative that we were offering at the time.
So it's not the first time that we're expanding, because again, if we jump to today, similar things are happening. People in different domains who could never dream of hiring a developer are now building their programs and the same thing is playing out.
Which is, if you put your software engineering hat on and look under the hood of that mess, there's lots of corner cases that aren't covered. It's impossible to modify and evolve.
Yeah. But so far this story with Smalltalk and Tektronix selling machines that come with Smalltalk: make everyone more productive, clearly it pays for itself. That sounds great. But then what happened?
There were alternatives that were easier to understand. So for example, Smalltalk syntax is funky. It's this keyword infix syntax. Along comes C++, which was originally called C with objects. And the syntax looks familiar, even though the design philosophy is entirely the opposite of Smalltalk. There's lots of mechanisms and they're very complicated. But just the fact that it was approachable, there was a compiler, because we were used to having compilers.
In Smalltalk, there'd be some code, you'd edit it and now you're running with the new code. There's no compile and link step. Of course, it's just sitting right there. And you could be editing some text and say, "This doesn't work the way I want," and hit Ctrl-C and you get a debugger and go down the stack and you find the code that's not doing what you want and you fix it and you continue on your way and then you're writing again.
That was that level of "this is intended to be a personal computer." And part of that sense of ownership was that you could see everything and you could change everything. Now it turns out if you have a hundred people working on the same program, you need to put the brakes on. Everybody can't be changing everything in incompatible ways at the same time. That just doesn't work. But in terms of "this is my computer and I feel power because I understand it, I can have more ideas that I can then execute on to create things in the world," it worked great for that.
Now, while at Tektronix you worked with Ward Cunningham, who would later become the developer of the first ever wiki. He had a huge influence, he helped create design patterns, he also helped with Extreme Programming. Can you tell me about what it was like working with him and how you and him started to get into design patterns, which back then didn't exist, right? This was something you would invent later.
We needed to give training classes on Smalltalk and Ward had written some Smalltalk code. We knew each other, there were probably 60 people, 80 people in the labs, so we knew each other by sight. I had learned a bunch about Smalltalk working on my own projects. I was working on a programming language for Prolog, because logic programming was also a big deal at that time. So I implemented, I think, three different virtual machines for Prolog, including some nice animations showing how Prolog's unification mechanism worked.
And I guess for those who don't know, Prolog is this declarative language, a very different way of thinking. No variables, I think.
No, it's got variables. No variables is FP, Backus.
Oh, this is FP, sorry, but it does have some funky stuff. I used it a long time ago.
It's fun. Turns out to be difficult to write big programs in, but it's a good exercise because there aren't controls like do this thing, then do this thing, then do this thing. It's more like a theorem prover.
So, I was working on that. Ward had built this example code for the Smalltalk class and he said, "I just want to run you through this code." So I sat down next to him and he showed me the code, called plumbing, and I suggested some improvements. We gave the class together. I met some people who would later become lifelong friends in that class, and then we just kind of fell into a rhythm of "well, I wonder if we can make Smalltalk do this," because the universe of what it meant for a computer to support programming was just exploding. We had this high-resolution screen which nobody had ever had before. We had this dynamic language, including our own implementation of it, so we could tweak it if we needed to, and we just didn't know what was even possible.
So at first, and Ward was always a much better programmer than I was in terms of low-level technique. He also had a gift for design at a higher level and a gift, as you see in the wiki, of picking powerful top-level goals and then making something that does that. But I was this 24-year-old punk with attitude and he didn't let me touch the keyboard for a while. I could watch him, and then eventually I was like, "Those parentheses don't balance, you need a period here," and I was actually being useful to him, and I was absorbing, watching a master programmer at work, but I wasn't really driving stuff.
Eventually, though, I started understanding the low-level patterns and then building up to the next level and the next, and then I would say, "Why is this called this and not that?", pull out a thesaurus and look it up and find just the right word for things and then continue. And eventually I started making suggestions that he wouldn't understand right away. And so I would take the keyboard for a little while, say something like this. "Oh, I get it. I get it." And then he'd take the keyboard back.
Over the course of a few months, we developed a programming style where the keyboard was going back and forth, where we were talking at multiple levels. We'd talk about: here's this code, why isn't it working? Is this the thing we should be working on at all? What programming tools would we need for this to be easy? What should the design be so this whole thing works well? Should we even be doing this at all, philosophically? We would bounce between all those levels in the active programming.
And we had a weekly cadence where Monday morning we'd have a coffee and we'd talk about the list of things, because out of those conversations we'd come up with "I wish we had a thing that did a thing." We would talk about that and then we'd say, okay, well, let's go down and see how far we can get. And over and over, Tuesday, Wednesday, we would make a bunch of progress on what we were working on. Thursday, we'd be giving demos and refining it. And Friday, we'd write a tech report. So, there's this whole string of tech reports that we wrote over the course of maybe 6 or 12 months of really working together intensely.
Even if one of those weeks failed, we'd have our coffee Monday, Tuesday, Wednesday, ah, this didn't work. We would know why it didn't work and what it was that we needed in order for that thing to be easy in the future. And that goes into the hopper for the next Monday's coffee.
So, we developed a wide range of programming tools and applications, some foundational stuff. So, we had a graphics editor called HotDraw, because we had this graphical interface and everybody had been used to text interfaces for so long, but now we had high-speed graphics. Oh my goodness. What can we do with this? So, we kept making graphical interfaces, but it was hard to make graphical interfaces.
Yeah. I have a photo of early HotDraw.
Yes, absolutely. And this reminds me, when I look at HotDraw, these boxes and arrows, they do remind me of later things like UML, not the exact ideas, but visualizing. And of course these days I think people don't use UML, but you still just go to the whiteboard and you draw out boxes and arrows and how they connect. Sounds like you did this back in '87 or something like that.
Correct. And because we had high-performance, for the time, graphics primitives, the magic moment out of HotDraw was we drew a series of rectangles kind of on top of each other. We selected every other one. We clicked on it and we started to move it back and forth, and because we could do maybe 10 hertz animation, it was smooth and you could just see half of the rectangles kind of moving behind the other half and it was just, this is so hot. We were just really excited about it.
Oh, that's why you called it HotDraw.
That was the name, because that was the reaction to being able to see this smooth animation. And before that, writing that kind of smooth animation was a bespoke thing and took a lot of work. And with this, you subclass Figure and now you have something that works in this 2½D world and away you go.
Those figures, though, were meant to represent something in the interface. It wasn't just a rectangle. It was a processor, it was a generator, or it was a whatever. And then you click on it and you get these handles on the figure, each of which represents some way to manipulate the state, not just of the graphic thing, but again, there was intended to be meaning behind it. So you'd have a handle that would raise and lower the temperature and another handle that would change the pressure, or whatever domain you were working in. And then it was a boxes-and-arrows model. So you'd have connections between things, and the connections again were intended to be semantic but would follow the figures around.
And actually the words figure, handle, drawing, Ward came up with those. Mine were something pedestrian: drawing object, drawing handle. I didn't have good words for it. And this was where the thesaurus came in. Ward would think about, okay, this is like figures in a book. We had an analogy there, there was a metaphor to what we were doing. But in the computer world, you can have figures and figures and figures.
And do I understand that you actually had a physical thesaurus, like a book?
Yeah. An actual book with words in it.
You would actually, as a programmer, reach for this book with words and open it up to find better words.
All the time.
Was this just you doing it, or did programmers in general, people that you knew, also have a thesaurus?
We were on the far end of the obsessive scale for this. There were other people certainly who were fighting for the right words.
But this just reminds me of how programming is just more than writing code, how you need the skills of, for example, if you are well read, you can probably write more expressive programs, or if you're not well read, having a thesaurus. Of course you could do it online, but I assume that by opening up the book and reading a lot of other words, your vocabulary will start to grow, therefore making you a better programmer, or someone who can write a lot more understandable or maintainable
Part of the goal of programs is to communicate intent to other human beings, and now to models as well, which is a much more open-ended problem. We understand a lot more about how to communicate to other human beings, whether we apply that understanding or not. We don't
understand at all how to communicate effectively to models and people are trying out all kinds of things, which is — that's great. That's what you do.
Yeah. And then later Ward went on and he got very much involved with design patterns. I can now see with HotDraw how, you know, the design patterns in the Gang of Four — later you see boxes and arrows — how I see some resemblance on being able to visualize objects on a monitor.
Yes, all of the pieces were working together for us. The patterns work — I had become interested in Christopher Alexander at the University of Oregon. I couldn't afford The Timeless Way of Building, so I read it standing up in the bookstore over the course of several visits, and Ward had also been exposed to Christopher Alexander and patterns.
Alexander wanted buildings with a certain spirit to them. He talks about it in kind of mystical terms, but that's okay. And he hypothesized that if people made their own decisions about the design of buildings, this spirit would exist in a way that it didn't when the architect would say, "Oh, well, you know, tell me what you need in a building and then I will program myself to dream of your perfect space and then I'll bring to you the solution." The way he wanted to work was to empower people to make decisions within constraints. Like me designing a house, I'm going to have roofs that fall down and walls that don't match and whatever, 'cause I don't know. So I need constraints, but I know more about my life. So I should be the one making the decisions about, oh, family dinners are really important.
Oh, so this is in the domain of architecture, like strictly physical buildings?
Yes.
Wow. So you got a lot of inspiration from this domain even though software is very much virtual — it's in our head, right, or in the computer.
So the patterns are the constraints. You can't just make any decision. You make particular decisions at particular times based on the constraints that come from the decisions you've already made, and that creates constraints for the next decisions that you make. We wanted that for the users of programs, taking this Smalltalk personal computer ethos to the next level.
And so we were consulting on a project that wasn't going well at Tektronix. Some programmers were writing software for some test engineers and it just wasn't going well. So Ward came up with the initial set of patterns that we would use for designing a user interface. Again, graphical interfaces were brand new. Nobody knew what to do. There were all kinds of crazy things coming out.
In music school, we learned about the evolution of musical notation. And when musical notation first came out — before then it was entirely an oral tradition, then musical notation was invented. And some of the most complicated music ever written was written in like 1200 or 1300, right after musical notation had been invented, because nobody knew what the limits were. And then they settled down. It's like, okay, a four-part motet, that's fine, and we don't need to have 60 different instruments doing 60 different things all at the same time just 'cause we can. Well, it was the same kind of way with these user interfaces. Nobody knew how to organize them.
So we gave this initial set of patterns that Ward had come up with, and we'd talked about Christopher Alexander and patterns, and I ran across a copy of Notes on the Synthesis of Form at Powell's Books in Portland and devoured that, which is kind of the theoretical underpinning of patterns. We handed the patterns to the test engineers and said, okay, we're just going to start over. Use these patterns to break your process down into windows with panes. And we were careful to only allow them to do things that we knew that we could implement. So they couldn't come up with just anything. The panes had to be lists or text or waveforms. The waveforms were special, but that's okay. We could do that. Each task that you had to do in this testing process would have its own window, and so there were, you know, four or five different patterns, and they came up with an interface that was eminently implementable, and they felt like they owned it. And then the Smalltalk programmers would look at that and go, okay, well, how do I implement this, how do I implement that. So that was our first foray into patterns.
People get really fussed about this transfer of responsibility. They want to think, I am the designer of interfaces and I worked hard at this and I want to ask you a bunch of questions and then I want to cogitate on that and then I'm going to bring you the solution and then you'll thank me and pat me on the head. Of course, that doesn't happen. Your understanding of somebody else's problem is bounded because you're not in the middle of it. You don't have the same skin in the game. If you're not a semiconductor test engineer, you don't have as much skin in the game as somebody who is, because they're going to have to be using this interface for a long time after you're gone.
Yeah. There's also this concept of the flyby architect on teams, where, you know, this very senior person has built a lot of stuff and the team is struggling. They call him or her in. This person comes, makes some suggestions and kind of flies off.
This is a seagull.
The seagull. The seagull. Because it should—
You fly in, you make a bunch of noise, you crap all over everything, and then you fly out. Yeah.
Yeah. And you drop skin in the game. Yeah. And it's interesting because anyone who's worked in teams of a certain size or certain tenure, you see it happen. And it doesn't really matter how highly skilled that person is. There might be a few exceptions, but generally if you don't have skin in the game, you just make different decisions. And then after Tektronix, you worked at Apple. I only realized this about you. How did you get into Apple? This was in 1987. It's a very exciting time, from my research. How did you get in there? What did you do there?
So, Smalltalk was going up like a rocket at that time. Xerox had developed Smalltalk. It handed it to, I think, four companies to see: can you also implement it, or is this something special? So HP, Apple, Tektronix, and — blanking on the fourth one. HP really didn't do anything with it, but Apple and Tektronix ran with it. So Apple had its own implementation of Smalltalk, and they wanted to not commercialize it in the sense of selling it, but commercialize it in the sense of having something that — this was right after the Mac had come out — something that you could use on a Mac. And so I knew about that project. I was getting too big for my britches at Tektronix. I learned a lot.
You know, there's this kind of compression that happens when you're growing faster than the organization can recognize that you're growing, but also you're not growing as fast as you think you're growing. And eventually that gap between how people see you and how you see yourself — and then somewhere in between is how you really are — if those gaps get too wide, you just have to move. So I was ready to move on.
So I contacted Apple and I worked for about a year on the Smalltalk project, which ended up going nowhere 'cause it really didn't make sense. Smalltalk could work in quite a small memory footprint, but the only developer tools Apple really needed were a C compiler, a Pascal compiler—
Because that's what they built their software on, mostly C.
That's what they built their software on. That's what everybody else did. There was a thriving third-party market for other developer tools. But Smalltalk wasn't going to really do anything for anybody. Maybe school kids or something, but it wasn't driving Apple sales.
People who bought Apple computers typically didn't want to do Smalltalk, right?
Correct.
Correct. So we talked about the decline of Smalltalk. I'm sensing around this time, if, you know, as personal computers started spreading, it seems like it just remained a niche, right?
No, it was quite strong at that time. It was growing fast. Lots of people, relative to the previous year, were using it. A company had spun out of Xerox called ParcPlace, which was selling Smalltalk as a big-ticket item for developers, and this is before there was open source out there. So the idea that you could charge money for a language implementation — lots of people were doing that kind of thing, and this was running out of that same kind of playbook.
Okay. So it was still doing it. It just didn't make sense for Apple's customer base.
Correct.
And their hardware.
Yeah. Also, though, at the same time a bunch of the ex-Xerox people had come to Apple. So my friend Larry Tesler was there — and by friend I mean bitter enemy who I respected a lot. Sometimes, you know, there are people who just raise the hair on the back of your neck, and Larry Tesler was one of those to me, and I don't know if the feeling was even reciprocated. He passed a few years ago, so I never got a chance to talk to him — but I talked to him, you know, we would check in afterwards. Anyway, he was the head of the Advanced Technology Group at Apple at that time. Alan Kay had moved to Apple and was working on a programming language for kids, another programming language for kids, called Playground. Dan Ingalls was there. So a lot of the Xerox folks were at Apple, and I heard about Alan Kay's project and thought that was a dream of mine. Byte magazine had an article on Smalltalk. I read about the development of Smalltalk. The project started in like '71 and it was 1980 before they released anything at all publicly. And just imagining working in that environment just seemed like heaven to me. So I moved to Alan Kay's Playground project. Now, I was horribly ineffective. Ended up getting fired from that job.
No way.
Yeah. Oh, sure.
As a programmer, you being inefficient? What happened?
I wanted to do my own thing. And this was still, you know, I'm still in this punk mode where I'd listen to somebody else's ideas and I'd go, "Nah, I don't think so. I have a better idea." And if you're working by yourself, that's okay. But if you're working in a team, that's not okay. So it came to a head. I was the program chair for the OOPSLA conference, which we probably should have mentioned earlier. There was this conference and it was the hottest conference, and everybody who was ever anybody was there, and it was growing fast, and I was involved in it — kind of stumbled into it — but in '89 I was the program chair for OOPSLA, and I spent a month just reading papers while ignoring my duties to the Playground project, and that was kind of the final straw: okay, you're not helping us, so you need to move on. And then the conference happened and my second child was busy not being born. So I didn't even get to attend the conference.
But I had heard about the Playground project. So I moved to the Playground project and did a little bit to help build this programming language for kids. That was the next thing beyond object-oriented programming. Today you'd call it reactive programming. So you couldn't send a message. You could only raise some condition that some other object would be waiting on. So it's like pub-sub, but that was the only control mechanism.
And then I wanted to ask you about this — this was around this time — CRC cards. What are CRC cards? I know they stand for class-responsibility-collaborator cards, but what were they and how did you come up with them?
You have these imperative programs and you have a flowchart which represents accurately, if kind of verbosely, the control flow in an imperative program. Now we have these objects and you send messages which are polymorphic. So you don't know exactly what code's going to be invoked when you send a message. And people were like, well, how do you even visualize, internalize? For me, I have kinesthetic synesthesia. So I can feel in my body — if I'm looking at some code, I can feel in my body it wants to go this way. It's—
Yeah. Which is, you know, I don't know if I've met anybody else who describes their experience of programming in the same kind of way, but there we go. How do you get a sense of — however you internalize this — of what's going on in this program, where you can't just say we execute this line and then we execute that line, because as soon as we send a message, we don't know what's going to happen?
So Ward came up with the idea to write down on cards, index cards, here's what's going on. Because we would talk this way all the time. So, you know, we have a rectangle and it asks the renderer to do the thing, and then that goes into the pipeline, which dah. So we would talk with our hands a lot. So he said, "Well, why don't we write these things down on cards?"
So a big challenge in object-oriented programming is dividing the responsibilities, because you're moving the computation to where the data is. Saying, well, this object does this and that object does that, is a really critical decision, because you want the computation near to the data so that there's less coupling between them. Which is a lesson that I think kind of got lost in the noise. That's the fundamental design move in designing object-oriented programs, and I think I stand behind that.
So have the data be close to where it's used, where the computation will happen—
Backwards.
Backwards.
Have the computation move to where the data already lives.
Have the computation move to where the data is.
So, like, if you have a rich object with lots of data inside of it, for example, you want the computations to move there. So you want the objects to invoke and just get the data and do whatever computation they need to.
If I'm going to operate on stuff that's on the inside of a rectangle, like area.
Yeah. Do I have height times width scattered all over the universe, or do I have an area inside the rectangle that does height and width? At the limit, now I don't care that the rectangle has height and width. That's hidden from the rest of the world. Like, I can represent the rectangle with two corners—
Or I can represent the rectangle as a top left, a height and a width.
To the rest of the world, it doesn't matter as long as they both respond to area. So now I can come up with another representation and another representation, and the rest of the world doesn't have to care if I've moved the computation where the data lives.
Yes. And that means you can have looser coupling.
Correct. Understood. It's a good lesson.
Yeah.
And even today, 'cause everything that we do, under the hood — almost everything we do is object — a lot of it is object-oriented. And I don't think we think about these.
Yeah, I see a lot of criticism of programs written in object-oriented languages that aren't criticisms of object-oriented programming or design.
So after Apple, you moved to a company called MasPar. And the thing that I notice here is unit testing. This was the place where, as I understand, you came up with something called SUnit.
While I was at Tektronix, I got interested in testing. At that point, testing was a sociological divide. If you got A's and B's in computer science school, you got to program. And if you got C's, you had to be a tester. So it really was like a status thing. I'm not going to test. I'm one of these guys, not one of those. But I got interested in how would you automatically test programs? How would you get a sense of confidence in what you were doing? So I tend to be an anxious person, and the more complicated my programs were, the more I had to be anxious about. The more experience I had with what kind of bugs could possibly exist, the more anxious I got. And I thought there was just some way to kind of quell this without pills. That would be great. I tried out a bunch of different approaches to writing automated tests. At that point, in addition to this status divide, there was a tool divide. You had testing
tools which would have their own kind of language and some way to connect with the program that was under test. So I tried this and that and the other thing. It was actually after MasPar that — I think is all ancient history, so we'd have to go, you know, dig through the archaeological layers. I started consulting and I was going to tell a client that they should write tests. I was going to fly out to Chicago the next day, but I didn't have any way for them to write tests. So, out of these five or six experiments that I'd done, I synthesized test case, test suite, and test result. It was like three classes and 12 methods. But it was a framework where you could write tests that would execute isolated from each other, fully automatic, and give you a rollup of the results of it.
So this was pretty much a unit testing framework for Smalltalk.
Yeah, the first version was written in Smalltalk. So, MasPar was a Silicon Valley startup, venture-funded, intended to build an entire new architecture, which was SIMD, single instruction multiple data. So we would have a torus of processing elements, up to 16,000. So you have 16,000 and they're connected in a toroidal grid, so you could talk to the processing elements to your left, right, up, down, and diagonally. And it looks very much like the Nvidia architecture now, but this was way back when, and it was just too early. So three years of that, building programming environments for high-performance computing. The intention was to get the kind of performance you'd get out of a Cray at that time, but for a tenth the cost, and they needed a programming environment. So we built a programming environment in Smalltalk that did some really cool stuff. You could single-step a Fortran program and build a performance profile at the same time.
No way. So you built a runtime that allowed you to, in Smalltalk, interpret, for example, programs and run them.
No, we had a standard compiler, an optimizing compiler, but because we controlled the operating system, we could build really low-level probes to collect performance profiling data. So we could get line-level profiles for these Fortran programs running on 16,000 processors, and great gobs of data.
That's awesome. Like, you're going to lower level, you know, building infrastructure that runs programs. But I want to go back to SUnit. So the concept of SUnit, these concepts you put together: a test case. What was it? The test case,
test suite, and test result.
This really became sticky, because then there was JUnit, which you later created with Erich Gamma, and there's a whole suite: NUnit, I think that was for .NET, xUnit.net. All of them took over some of these ideas, and a lot of modern unit testing frameworks are built on some of these ideas. Why do you think it was so sticky, and why do you think it wasn't created beforehand?
So beforehand, because of this social divide between programmers and testers. There was a lot of incentive for the testers to have their own language. This is my tool. I know how to run it. I'm going to run it. And it was very adversarial at that time too, and kind of patronizing, like: you're a programmer, you can't be trusted to test, you know, you'll just say it works fine. I'm going to be the adult supervision, you know. And sometimes the programmers really did act that way, so, you know, hard to argue with. But I think that encouraged this idea that a testing tool is its own world.
The inspired decision to use the same language to test as you're testing — it was a natural decision because I was in Smalltalk, and you should be able to represent anything in Smalltalk. And I was just used to: how do I represent this as objects?
So, sounds like Smalltalk as a language has been early to a lot of things. I sense a lot of innovation coming from Smalltalk, because it was one of the first languages that did have objects, but it was a very simple language. So you needed to build a lot of things, which then led to representing a lot of things, to talking about them, design patterns, and now also, you know, being able to write your test environment, or being forced to do so if you wanted to do it.
Well, there was an ethos that went along with Smalltalk. So if you didn't like the tools — if you're running the debugger and the debugger doesn't have some feature that you really need right now — you just hop on the stack, implement the feature that you want, and then get back to whatever it was you were doing. That was just a natural thing because there was never this huge gap. You know, imagine today I'm using a C compiler and I realize, oh, I wish C had this new feature. We're embarking on a multi-year project, like the huge barrier to entry to go to the next level. And in Smalltalk, by design, for example, you have pop-up menus and you can see all of the options right there. That's a deliberate pedagogical choice. It says, "Okay, well, you know about cut and paste, but you don't know the other things that you can do right here." So the menu doesn't just give you cut and paste. It gives you all the things that you can do, as a way to encourage you to learn about them, because eventually you're going to see this format item here and, well, what does that do? So that was very much part of the Smalltalk ethos, that the system would teach you as you kept using it.
So yeah, it was very natural to build the testing tool in the language. And of course you have to kind of bastardize the language a bit here. Here I've got this class for some test case, and I have a method which is one of the test cases, and it starts with 'test' — that's kind of magic, you know, this is getting squidgy. And then when you execute it, you create one of these objects, you send it setUp, because you may have to build some stuff, and then you send it the test-something-or-other, and it executes that one thing, and then, assuming — well, then regardless — you run the tearDown from that. So it looks like the syntax is the same as the language. The representation of the tests, you kind of borrow from the representation of just any kind of code, and then you interpret it yourself. So it's in the language, but it's not really in the language at the same time. But people don't think about that. They just think: I subclass this, I give a method with the annotation of test, or that starts with 'test', and then it just starts working, and that's fine.
I want to jump to a few years later, to 1996. You started to work on a project at Chrysler, and this is where you met Martin Fowler. What was this project?
I'd actually met Martin Fowler a little bit before that. So as early as the first OOPSLA conferences, the question was: how do we manage projects with objects differently than we manage projects with the previous generation of tools? The previous generation of tools definitely gave you many fewer options for change. You'd still have to change code, but it was just a lot harder compared to working with object-oriented programs. So what is the methodology? We had structured analysis, structured design. What is the methodology for objects, and how should it be different? That was the million-dollar question at the original '86 OOPSLA. By the time '94, '95 rolled around, we were starting to get a clue what that would look like. There were, I think, the Rational Unified Process, or the things that would go into the Rational Unified Process, already existed by that time, which was
Grady Booch was involved in that.
Grady Booch, James Rumbaugh, Ivar Jacobson. So people were coming up with some kinds of answers. Ward had come up with his own answer called Episodes, written as a pattern language, because we were like, you know, I don't have a big bag of tricks, I have to keep using them over and over again, and the same is true, turns out, of everybody. So you can find that Episodes on Ward's C2 site. It's really interesting to compare that, because I borrowed heavily from that. I borrowed from everything else that I had seen and experienced. But at that point — when did I leave MasPar? '92 — so I had been an independent consultant for four years at that point. And there were a couple of workshops held in Snowbird — I don't know why we picked Snowbird, but somebody else did — about this methodology question. And I met Martin at the first one of those that I attended. And his introduction was just the classic Martin introduction. He said, "I am the only person here I've never heard of." And he was already doing some great work on analysis patterns at the time, which I knew about. So I was excited to meet him.
Get to this Chrysler project. The project's important for Y2K, but it's not clear that it's going to be finished in time. Martin was already there as a consultant. I had met Ron Jeffries doing Smalltalky stuff. I don't remember exactly how we met, but long story short, I came in as, I don't know, lead consultant or something, restarting that project in a very different development style. And for that style, I took everything that I knew that was useful and cranked it up to 11, and discarded all the stuff that I couldn't prove we needed.
So that was the value system behind this new style of development. Martin and I would visit there periodically. Ron was there full-time. I was originally brought in as a performance consultant because I knew a lot about Smalltalk performance, and they were using a database called GemStone, which was Smalltalk objects, Smalltalk semantics, but coupled with persistence, transactions, indexes, all that database good stuff. But it wasn't going fast enough. So I said, well, where's the test case that makes sure that I don't break something if I make some changes? And they said, well, actually, it's not computing the right answers yet. And I said, "Well, then I can make it go really fast." And they didn't like that answer very much. Anyway, most change I've ever seen over the course of one week, at the end of which everybody was exhausted. They'd been working very long hours. I said, "Send everybody away for 2 weeks. Tell them to get some rest. We'll come back. We'll throw away all the code that we've written so far, and we'll restart." And we restarted on this 3-week cadence. Every three weeks we would have more test cases specified by Marie, the payroll expert, that would be working, and then we'd start another 3-week segment, and another, and another.
Now, it turns out those 11s that we turned everything to, there were several notches beyond that, but that was the most intensely we could imagine replanning, integration, deployment, refactoring, and so on. The ideas that went into that were this synthesis of all these experiences that I'd had.
And then, so this is from Ward, when the two of you started to pair and pass the keyboard and decide on all the different things that you're going to do; your experience with tests as a concept, that it doesn't need to be the testing team that does it, but you can do it yourself in your own language, which was just new. And so all of these ideas just all came together.
Yeah.
And then when did you give it a name?
It started going well. At first I was excited. I was scared. I was excited. Then it started going really well.
So, like, the project started to go visibly well.
Yeah. Yeah. After, like, six weeks. And then I was happy to be telling my friends about it: this new style of working that we're doing here at Chrysler. This new style of working we're doing here at Chrysler. This new style. That got kind of old to say over and over again. So now I'm back with the thesaurus trying to figure out what are the words.
Called us.
I thought we were really on to something that was going to be big. So I wanted to protect it. Apologies to Grady, who's a good friend now, but I didn't want Grady Booch to ever say that he was doing this thing. So I had to pick a moniker that was unattractive enough that somebody would try and steal it. And this is about the point at which
You're now this punk again.
Yeah. Well, yeah. I still am, but I'm just an older punk now. Yeah. Yeah. But a little bit of thumb the nose at the establishment. Extreme sports were there. I kind of like the analogy with extreme sports, because you don't just hop on a snowboard at the top of some avalanche the first time. No, you have to be supremely prepared. You have to have done all of your research, and then if you have these outstanding skills, then you accomplish things
Yeah. And training and all that.
Right — that seem impossible, and are impossible if you haven't done all the prep. So it's accurate, it's edgy, it's that word extreme, and hence Extreme Programming was born.
So that's the extreme part.
Extreme — I knew that a bunch of people wouldn't like it, but that's okay. I started out calling it development, which I still kind of like, because there's more to delivering value with software than programming. But the methodologies extant at that time treated programming as this clerical task. We'll draw these diagrams and these diagrams and build this thing and the 14 ways to visualize this, and then there's some programming, and then we'll draw some more diagrams. And I thought programming — sitting, fingers on keyboard, staring at code — that's where I do my learning, because that's where you can no longer fool yourself that you actually understand. Either you compute the correct value or you don't compute the correct value. So I wanted to elevate that moment of reality meets program, and that's where the programming comes from. Now, from very early days I also called it XP, as a way of separating from the downsides of both of those words, extreme and programming. So we can just call it XP, and it's more of a generic thing. Not long after that, Microsoft releases Windows XP, and there's an alternate universe in which I sued them and succeeded. And there's another alternate universe in which I sued them and failed and bankrupted myself and my children all starved to death. So,
Right. Right. 'Cause this was right around the late '90s, and XP came out soon after, I think 2000 or 2001, something like that. When did XP — Extreme Programming — start to become big? Was it as you gave it a name and you started telling people, or then there was your book, which came out in the year 2000?
I remember the first talk about XP I gave. I had some flyers to hand out. So I think it was at an OOPSLA on a panel or something like that. I talked some about XP, and afterwards people were like, give me a copy. The reaction to it was just tugging on my shirt, wanting a piece of this thing.
And I think XP had exquisite timing, in that the upside — not the bomb, but the upside — of the dot-com was just starting to hit. They looked at other methodologies that would say, you know, very carefully prepare, do this analysis document, do this design document, then a bunch of coding, then a bunch of testing. They could tell that's never going to work in a world that's changing as fast as the internet wave starting to crest, starting to come into this super hyper growth. On the other hand, we know that this cowboy style — you have the Jolt Cola, rest in peace, Jolt Cola — cowboy, you have a bunch of programmers, they do incomprehensible stuff, they don't talk to anybody, you just slide pizza under the door, and then you get the code out. That's not going to work either. Here's this thing that looks like it's kind of in between the two. There's discipline to it. There's iteration to it. There's transparency to it. You have ways of steering what goes on. You have ways of tuning the process. You have all these tests to make sure that stuff actually works. You have frequent alignment between people, whether it's business people and technology people, or technology people with each other. Okay, I can see how this could work. And so they could see the internet is exploding
and I can use XP to take advantage of that opportunity in a way that I can't, I don't, there wasn't really another alternative to it.
Basically XP was giving you a way to move pretty fast and nimble but also have a sense of stability, not just going wild. Tests there. You had the iterations, the planning, the learning. And then when did TDD come along? Because there was a book that you wrote that came out, I think two years later, Test-Driven Development: By Example. And how did it relate to XP?
So TDD was an earlier... Test-driven development was an earlier rediscovery for me. Remember, I was a kid. I read all these books. I remember one of the books my dad brought home, and I still haven't found a copy of it. Said, "Here's how you program." This was back in the days of tape to tape. So, you'd have an input tape, you know, like time cards, and then you put it through the payroll program, which would write an output tape, which was like dollars for checks, dollars for withholding, etc., etc.
Yeah. So it was always and then... Really back in the day.
Really back in the day. And you'd have these long strings of this, and it's actually functional programming because you can't change the input tape. But operating payroll or operating accounts payable or operating inventory was a process of: I take these tapes, I feed them into this program, I take the output of that, feed them into this program, and blah blah blah blah blah blah. And then you, really manual, like actually physically pulling a tape off and moving it over.
Yeah. And so it said here's how you write one of these programs: you take an input tape, an actual input tape that you need to process, and you manually type in the output tape you expect that to generate. You say, okay, well, this number of hours should, I should have a record in the output that's like this.
So I see where we're going with this. You're defining the output. You're... Before you start on the program. Yeah. So first you need to know what do I expect? How can I validate it?
Correct. I had read that as a kid, didn't understand diddly squat, but it's back in the back here someplace. I wrote SUnit for the first, started using it. Gave it to Hal Hildebrand, one of the smartest programmers I knew. I didn't figure he would need it. He used it. He loved it. So, I knew I was on to something with this testing framework.
And then I was just kind of farting around and remembered this typing in the output tape first and mapped that onto the testing that I was doing with SUnit. I went, well, if I followed that pattern, I would write the test before I wrote the code. And I can remember laughing out loud because it was such a stupid idea. Why would you write a test that you know is going to fail? You don't even have the classes defined yet. You don't have the methods defined yet. It's going to fail a bunch of different ways before it could possibly succeed. Cool. Let's try it and see what happens.
So, I used stack as my first example. So, I have a stack new and I push something and I pop it. I should get the same thing back. Okay. And then I went to program it and, okay, well, that's easy to satisfy. What's the next one? You know, you push two things and you get them back in the right order. Okay. And this, and dup, pop, top, is empty, and finished. Where's the anxiety? Oh, just gone. Oh, for the first time.
Wow. I can't imagine another test case that wouldn't pass. So, I'm really, I'm finished and I feel great. I feel finished and I am finished.
Wow. Going from this is a stupid idea, let's try it.
Absolutely. I made a comment: always try your stupid ideas if you can do it cheaply and reversibly. Jumping off a bridge is not a reversible decision. Not talking about that. I'm talking about stuff like this where you're just like, "Here's a stupid idea." 99 times out of a 100 it'll fail. But that one time you won't have any competition, because nobody else is stupid enough to try this idea. Part of this punk attitude, I don't care what you think about this, has enabled me to just try lots and lots of stupid ideas. And most of them you don't see, but there had been a string of them which worked out way better than they would have expected to work out.
Well, and then a bunch of other people tried these ideas as well. You know, I think TDD is a good example where there was a time, shortly after you wrote the book about it as well, it was a super popular book. I still remember, I think I had a copy as well, back in the late 2000s, people were doing, you know, group exercises, developers were developing accordingly. Over time it probably dropped, I would say in the 2010s I saw fewer and fewer people doing it, and it almost went out of style completely. And now with agents the idea is back, because turns out it might take more time or whatnot, but agents can do that, but it's pretty useful for them to test themselves.
It costs tokens in the short run, but it can save them in the long run, because one of the classic genie mistakes is stuff doesn't work. So, how do you pull in the reins a little bit?
And why did TDD go out of fashion?
I think a big part of it is I work on something for a while and then I switch to something else. That was true of patterns. It was true of JUnit. It's true of TDD. It's true of XP. I just move on to the next thing. So I moved on to the next thing. TDD is out there. And then there were people who used it as a moral cudgel. Like, if you're not using TDD, you're not professional. And that's just such... People can write very good software with a wide variety of workflows.
Now, there's advantages and disadvantages to different workflows. The sweet spot of TDD is this combination of discovery and realization. I kind of know where I want to go. I don't know exactly how I'm going to get there, but I do know the first step. So, I take the first step and that teaches me something, which lets me take the next step, and that teaches me something. If you can just go implement, implement, implement, implement, fine. There's other workflows that are fine. If you just want to sit there and go learn, learn, learn, I don't think that works very well, but you certainly don't need TDD. It's when you have this rapid alternation between I do a thing, I learn a thing, I do a thing, I learn a thing, I do a thing, I learn a thing. That's where TDD is really powerful. But it's not a moral decision. It's a practical decision.
Test-driven development is one of Kent's most lasting contributions to how software is written and shipped. And today with agentic development, it's more important than ever. If you work with agents, your job is no longer writing code. It's specifying and testing it. This is where I need to mention our presenting sponsor, Antithesis. Antithesis is the most effective method of verifying code today. Let me explain how it works. Antithesis runs your whole system in a hostile simulation. By doing so, it finds every bug before your users do. And because the simulation is fully deterministic, Antithesis doesn't only find bugs, it gives you a perfect reproduction of every issue. I know this sounds close to science fiction, but it's actually hardcore engineering under the hood. Jane Street, Fly.io, and the etcd community ship agent-written code with full confidence because they know it's been verified by Antithesis. To see more case studies and details, head to antithesis.com/pragmatic. That's antithesis.com/pragmatic.
Kent has spent his career building the primitives that the rest of us now take for granted: unit testing, design patterns, refactoring. And building on solid primitives is exactly what our seasonal sponsor WorkOS is all about. If you're building any SaaS, especially an AI product, sooner rather than later, you'll need to get around to building enterprise features. Things like auth for apps and agents. WorkOS handles it: SSO, SCIM, fine-grained authorization built for how agents actually operate. The fastest growing AI companies, Anthropic, OpenAI, Cursor, Perplexity, already trust WorkOS to solve these problems. Check out workos.com.
And with this, let's get back to Kent and where the Agile Manifesto came from.
I wanted to talk about the one thing that you're also very, very known for, the thing that 17 people wrote, but you're the first one listed: the Agile Manifesto. Can you take me back to what happened in Snowbird? What was the industry like and what made all of you come together?
There were a bunch of people, remember we were talking about what is the methodology for objects, and you had kind of this dominant Rational Unified Process, which I say is neither rational nor unified nor a process, but that's a separate... mostly I did that to tweak people's noses. But that was the adult way to do development. And there were a bunch of us who... If you talk to Grady, if you talk to Jim, and you talk to Ivar, how they would apply it, it actually looks a lot like the way that I would develop. But it doesn't matter what you would do. What matters is what the people who read the stuff that you write would do. And it was being used in a very waterfall style. Bunch of analysis, bunch of design, bunch of implementation, separate testing, disaster over and over and over again.
So a bunch of us looked at that and, in our own ways, in our own sequence of time, said, "No, we shouldn't do this. We should do something else." And we started making enough noise that we started getting attacked by the Rational Unified Process people. Well, you don't want to do that. You want to do my thing, and here, I'll sell you a tool for millions of dollars to help you do it. I can understand why they would attack. But we started realizing, okay, if we're all going in these similar kinds of directions, Scrum, feature-driven development, we had to come together.
We had a meeting in Norway where we got together, gave a presentation. This is towards the end of the time I was living in Europe. I lived in Switzerland for two years, '97 and '99. So in '99 we flew up to the tip of Norway and took the Hurtigruten, which I practiced saying, and I'm sure I still butchered it. Took this ferry down to Bergen, and it was light all day, or all night. Bucket list item. Definitely take this if you ever get a chance, because the scenery is just absolutely spectacular.
But we were meeting and talking about, do we have enough in common that we could actually do stuff together? The sense of that meeting was yes, we should do something together, but there's still a lot of friction and there's a lot of divergence. You're talking about people with some healthy egos.
Strong opinions.
Me, not the smallest among them. So, when we got back, Jim Highsmith and Alistair Cockburn convened another meeting at Snowbird, same place that we'd been having these kind of methodology meetings for a while. And so, we all went there, and other people have told the details of the meeting. I'm not going to be able to recall them precisely enough, so find one of those recountings of this. But it was not going well for me personally. I had a nasty sinus infection and I was on some heavy-duty drugs. So I don't really remember much of the meeting in general, but I knew that things weren't going very well, because there's all these people and they, I want my stuff in. No, I want my stuff in, and that contradicts your stuff.
And so we took a break. We walked out, and Martin and Jim Highsmith stayed behind. When we came in from the break, there was the basics of the manifesto. You know, that format: we value these things, but we value these things more. And the four specific items, that was all in place. And that was just a magic moment that I had nothing to do with. And then we came up with the principles. And I remember the only word in there that's mine is the word daily, when it talks about daily interaction with users. I don't think I had another thing in there. But when it came time to publish it, what order do the names go?
Like alphabetical?
Absolutely alphabetical. So when people say, "Oh, you're a signatory," as they know, I'm the first signatory alphabetically.
And then what was the impact of the Agile Manifesto?
Oh, instant. People were so excited. Again, we were now in the rumblings of the dot-bomb.
It was still going up.
I think so.
It was towards the end.
But definitely towards the end. But people were still looking for, like, how do we do this? How do we do this stuff? How to build software quickly, cheap, reliably. Everyone's searching for the optional...
With optionality.
With optionality. Yeah.
Because when things are uncertain is exactly when options give you the most value, and we had a story about how you could preserve optionality, all of us in our own separate ways. That was another case. So XP was the first time I had people tugging on my shirt. JUnit was another one, which was SUnit. I had SUnit. Erich Gamma was using this new language, Java. We were flying to America. He was going to show me Java. I was going to show him SUnit. So we developed JUnit, testing itself in itself, on the flight from Vienna to Washington Dulles.
Wow. On the plane, no internet.
No internet. Two and a half hours of battery. Like, the clock is ticking.
Yeah. And no power adapter in the seat. Oh, it was like horse-driven computing. So we landed and we gave JUnit to Fowler, who was at that OOPSLA, and the next day: I hear you have a Java testing framework. Can I get a copy? So we made floppy disks, 3½-inch diskettes, and we were handing them out as fast as we could, because there was so much demand for it. So that was the second time I've been through that kind of a demand...
Product-market fit.
Yeah. Exactly. Product-market fit. And then the Agile Manifesto was the next version of that, where people were just really excited about it. Beautiful piece of marketing, to have the original signatories, and then if you wanted to sign it...
You could sign it for a while. I think they closed it after a while because it got too many people.
Right. But that meant that people felt invested. They were already bought in. They'd already attached their names to this thing.
It's interesting, right, how being invested, being able to contribute or feel you're contributing, it can make a difference. It has made a difference, and for agile for sure.
So one piece of follow-up is that word agile. Part of the argument was around what are we going to call this thing, and somebody suggested agile. I don't remember who, but probably somebody does. And I objected. And what I don't like about it, I didn't like about it then and still don't like about it, is it's not defensible. Nobody's going to say I'm not agile. Oh no, I prefer rigid development. Oh, I prefer inflexible development. No, everybody's going to say that they're agile.
Which extreme doesn't have that problem. If you work hard at your skills, at being able to pair and being able to design incrementally and being able to test thoroughly and build tools, and you make that investment, now you say, "Okay, I'm an extreme programmer." If you haven't made that investment, you're never going to say that you're an extreme programmer if you're not. But you're going to say you're agile even if you're definitely not. So that was my objection back then, and that certainly played out. That word not only doesn't mean anything anymore, it means something negative.
Okay. Can we talk about that, the afterlife of agile, and some of the capital, you know, the capital-A version? There's a whole industry that has grown that initially was meant to do good things, but it turned into a snake oil industry in many ways. We now have scaled agile frameworks that are sold for massive amounts to huge companies, which, you know, bog them down with even more bureaucracy than you can imagine. How did you see this being played out, and did you expect agile to grow this big into both a commercial story and then all of these, I guess, snake-oily parts?
I was certainly afraid that that was going to happen at the time that we put it together. The Agile Manifesto is the intersection of the ideas of the people in the room. I think there's a lot more to software development than is contained in the manifesto. And I've written books and books and books about what I think those things are.
Without the foundation of technical skills, you can have the best intentions of we're going to be able to replan and we're going to be able to implement in any... or, you know, we have a set of features and we can implement them in any order and we can add new features anytime we want. And you can say you're going to do that, but if you don't have the technical chops to write efficiently, write reliable software in bits and pieces, to design in bits and pieces, to preserve and enhance optionality, to write your own tools when you need to do that, those things are technically difficult. It's like putting somebody at the top of the avalanche on a snowboard for the first time. Well, there's a certain kind of agility as you fall down the mountain and break your body into multiple parts, but this is not really what we're talking about. You need that foundation.
And there were people who were willing to say, "Nah, no, no, don't worry about that. This is easy. You can do this. Anybody can do this. Twice the work in half the time." From my perspective, that's just a lie. Can you get twice the work done in half the time? Yes, absolutely. Is it going to be a lot of hard work gaining the skills, which aren't taught in computer science school, aren't frequently modeled in your first employer? You're going to have to work hard to gain the skills to be able to do twice the work in half the time. And the genAI world is just playing this out again. Well, everybody can be a programmer. Yeah, but everybody can't be the same programmer.
Yeah, seems like there's a pattern where when there is a new technology, or a new methodology in this case, but I guess it's interchangeable...
Technology. Yeah.
Well, it's a technology that a group of people, a group of highly trained people, can get really good results with, and then they publish it and they share: this is working for us, here's the results. There's a bigger industry going around that's saying what you just said, that anyone can get these results and we will sell it to you, we'll show it to you. And of course, by the time you realize that, for example, a company like a large bank realizes that it's not really working, they're heavily invested, and maybe they're actually getting some minor results, just not the same. And then I guess you can argue this is the whole point of snake oil, right? Like snake oil, it does something, just not what it was advertised.
Let's talk about what happened after 2001. So there was a big dotcom bust. Can you take us back to what it was like being in the middle? So were you in Silicon Valley at that point?
'87 to '97 we lived in the Santa Cruz Mountains above Silicon Valley. Much of that time I commuted to work. Then we moved to Switzerland, '97 to '99. Then in the last part of when we were living in Boulder Creek in the Santa Cruz Mountains, we had bought acreage near my grandmother in southern Oregon. So we bought eight hectares of just trees and started developing power, well, road and so on. Went to Switzerland. Oh, we built the office and we had a trailer, and then we went to Switzerland and we came back. So I was living in rural southern Oregon at that time.
And the industry just went through this massive boom, which there are similarities, as I'm talking with people, with the current boom whenever you're working in AI right now. And then there was a sudden bust that, again, I've learned it from the history books or like reading back news, but apparently it was sudden, it was shocking. How did you see it? What happened in the industry? What were your friends working as programmers observing, or how were they impacted?
It was horrible for me personally. The turning point was 9/11. I had 8 months booked solid, work at very high rates, higher rates than I can charge now, even with inflation. And the day after 9/11, everyone canceled. I was also finishing the house that we were building. So we were about to come up on some big bills to finish the house at the same time that all of my income disappeared. It's overnight.
Overnight. Wow.
So things had already been bad. There were big bankruptcies, and the pets.com and the whatever, that was already happening. And then 9/11 just shut down everything. That was a big shock for me, and I ended up burning out pretty thoroughly. Severe depression. I had a really important lesson to learn about boundaries. So up until that time, remember, periodically I had people tugging on my shirt and...
Yeah, you had three really big product-market fits where people were after you.
Patterns even before that was also like that.
But you were a star.
I was, yeah, I was feeling... Yeah. And I would get these messages. Somebody would say, "Oh, JUnit saved my life. XP was fantastic and I love it and you're a genius and blah blah blah." And I'd feel really good knowing a message like that. Then I started getting messages: "XP ruined my life. I lost my job. My wife left me. I can't see my kids. I'm living on the streets. You..." And then I would feel really bad.
And the way I think about it now is that there's the way people perceive you and there's the way you perceive yourself, and then there's what's really true, which is somewhere different than either of those. When people are giving you a bunch of feedback that you're more awesome than you think you are, that just stretches your head. So you see this in celebrities periodically. There'll be somebody super famous and then their head explodes, and that's that gap between how people see you and how you see yourself.
And what I had to learn was the reason that people come to me with those out-of-proportion responses is because that's what they need. They need a hero or they need a villain. And their need for a hero or a villain has nothing to do with me. If it wasn't me, they'd be contacting you. They'd be contacting somebody else. It really doesn't have anything to do with me. But that recalibration, where I'm like, I'm trying to convince myself that I really am this awesome. No, I get feedback that I'm not. That was a serious reset for me.
So I went through a bunch of mental health problems, couldn't work, couldn't program at all. I started over with Sudoku, and eventually I could do sudokus on easy, and then eventually I could do them on medium, and then I started on crossword puzzles. Wow. And then eventually I got to a programming problem. I was doing a bunch of stuff with Eclipse when it was new. I got to a programming problem and I nailed it, and I went, "Oh, this is still fun. I can still do this." But yeah, the kind of a lost decade from 2002, let's say, to 2011 when I joined Facebook.
So you really went from being close to the peak of the industry, or the professional, you know, mountain, if you will, to just, I guess, just finding your way.
Yep.
Do you think something similar might have happened, was it not for this sudden crash, or being this sudden? Or was it just the intensity of everything just being pulled out from under your feet? What do you think it was?
I think that people are coming to me with these expectations that I know I can't meet, that it's going to blow up somehow eventually, for sure. You can't just live the rest of your life like that. That's what the classic midlife crisis is. It's the masks that used to work, that felt like they used to work. You realize, oh, they're not going to work going forward. I have to be myself. And actually, they've never worked. I was just fooling myself that they had worked. Yeah, I think it's going to come. It said 35 or 40 or 45, and mine was at 42.
But then in 2011, you got into Facebook. And I'm really intrigued by this story, because at this time Facebook was 7 years old, which meant that the median age was probably like 24 at the company, and there you are, an industry legend again. You've had all these contributions, TDD, XP, knowing how to build efficient software, and Facebook is building efficient software in a different way, and now you're showing up when you were 50 with these people half your age. I assume you could have gone back to consulting and done what you've done before.
I was trying to do the same thing. So I needed the money, for sure, trying to do the same things as a consultant that I'd done before, and there was just zero interest out there. I had college to pay for. I have five kids, and I knew I was going to have two tuitions for four years in a row. I needed some stability and income. Problem with book publishing: it doesn't make much money.
Yeah. Except in the rare cases for a guy.
Well, in the rare cases, in my case, where Amazon self-publishing has been invented.
Yeah.
And people buy your books in bulk. But outside of that, even for... Yeah. It doesn't.
Yeah. I love teasing you because you're so successful. I know that even if you can't take it, you have to take it.
I have to take it here, here on this podcast.
So I needed some stability, number one, but number two, these people were doing nothing that was in my books, and they were running a stable site. It's not perfect, but at this crazy scale, it was stable and kind of unprecedented. They were expanding. Users and growth were expanding dramatically, and they were innovating, all at the same time. So how in the world are these... like, this is a bumblebee. It can't fly according to my theories. I want to find out what's going on in there. So at that point I'm still very curious about methodology and how people get along, and software development sort of at the societal scale, but I also needed the money. So I joined, and I think I was the first or one of the first remote engineers. There were about 2,000 employees total, 700 engineers at that time. And I just wanted to parse how does it work that they have scale, growth, and innovation at the same time, because I'd never seen anybody do all three. You'd see people do one of those, two was rare, and all three was unprecedented. And apparently they weren't too interested in, no...
In the prior art. Can you tell that story about your TDD class? I think you told it many, many years ago somewhere else.
Yeah, absolutely. So I get there and I'm nervous, like, you know, how am I going to contribute? I don't want to just, you know, be here for a week and then get kicked out. So there was going to be a hackathon, and hackathons often came with classes, and so there was a signup sheet for classes, and I thought, all right, I'll give a TDD class, because after all, you know...
You wrote the book.
I wrote the book, I invented, you know, blah blah blah blah blah. And they clearly need it, I could see, because nobody's doing it. Very few unit tests at that time, which just shocked me. How can this be? So I put on the signup sheet: TDD class, from Kent Beck. Just before my class was one on Argentinian tango, and just after my class was one on advanced Excel techniques. When the time came for the classes, the Argentinian tango class was full, the advanced Excel class was full, and no one, not one, not even like a pity signup. Zero people had signed up for my TDD class. So these engineers clearly felt like they had it already dialed in and they didn't need anything from this old guy. So I decided, you know what? I'm just going to forget everything that I think I know about software engineering, and I'm gonna try to do things, just sort of monkey see, monkey do. I'm going to copy what I see people doing and get feedback and see if I can learn to develop in this different style quickly enough. Can I relearn software engineering fast enough not to get fired? And I ended up staying there for seven years.
What did you learn? What made it work? Because, again, going back there, what Facebook did from the outside would have made no sense. They didn't have tests at the time. They were running this massive site, somehow keeping it working. Oh, and they had young engineers who didn't have a decade or two of experience to know what mistakes to avoid.
Mostly young engineers.
Mostly. So we had some very senior people with great leadership skills.
Aha.
...who could model it. Many layers of feedback were built into the system. So we had developer machines that ran the site. So if you wanted to change the color from blue to green, you could do it on your developer machine.
You could check out... there was a monorepo-ish thing.
Yeah. And so you could just change anything and, because it was PHP, you could see the results of that change in seconds. So that gave you one level of feedback. Then you had code review, which gave you another level of feedback. You could roll out internally more frequently. And everybody was using Facebook for all kinds of stuff, personal and internal business stuff. So whatever feature you developed, people would start using it immediately. So you get another round of feedback. Then we had this phased rollout process where you'd start rolling your stuff out. If there was a problem, the blast radius would be limited to a few million people. Not...
Like automatic rollback based on signals.
Yeah. Not the whole thing. Chuck Rossi's deployment team also was another level of feedback. You had stars. They would secretly give you a number of stars, and if you were three stars, they wouldn't look at your stuff. But if you were a one star, you just couldn't get your stuff pushed. So that was another round of feedback. Then you deploy stuff and you'd look at the results, like the early observability stuff. So you get more feedback about what you're doing. So feedback comes in layers, like a filter. And if you get enough different layers...
Swiss cheese.
...the bad stuff sticks and the good stuff still goes through. Yeah. So the Swiss cheese model, even though there's holes everywhere...
...as long as they don't line up for six layers of cheese, then you're good. And would unit tests have been better? Maybe. I wrote unit tests for the first feature I rolled out, and I still caused a site event because there was some other coupled code that I didn't find. Meaning an outage.
Yeah. Yeah. Not a bad enough one to go through an incident review, which is another layer of that, where every Friday the most senior people would get together, and anybody who'd caused an incident would come in and explain: here's the timeline of what happened, here's what we learned, here's what we need to do to avoid this ever happening again. And if you went into incident review and you explained it that way, you were fine. If you went into incident review and said, well, ops did this and somebody else did that and blah blah blah blah blah, you could literally get walked to the door. That was another level of feedback that made sure that the same mistakes didn't happen again, and that was taken seriously.
What I know, and what many people know, is, well, Facebook for a long time did not do unit tests for most things. In fact, I think if someone tried to push them, they would often just delete it in code review. And, you know, that sounds bad in itself, especially at a time, this was the early 2010s, where testing was considered really best practice or baseline. But I think what people missed is all these other layers that most places did not have. My understanding is that to this date, Facebook's website and mobile apps rollout infrastructure is probably the most advanced in the world in how it automatically collects signals and does the auto rollout and the auto rollbacks, which just does not exist in 99.9% of places, because they don't have their scale or their opportunities or even their business, right? Because I guess, you know, outages are just... it's a bit different when a utility company goes
down versus when Facebook might go down, the impact.
Yes. And while I was there, so by the time I left 2017, Facebook was a very different place than when I joined. Over the first couple of years, Facebook became much more like a utility. The big site events, the big negative incidents, the notable ones would get names. And so there was one called the call the cops SEV, and it was the first time that people called 911 when Facebook went down.
Wow. It was like, oh crap, we need to take this even more seriously than we've been taking it. Okay. Because we're social infrastructure and people just expect it to absolutely work.
And what was it like inside Facebook? How the engineering culture, how engineers work compared to the rest of the industry? Because now you were in this bubble which worked very differently.
There was very little planning. There were no deadlines as such. Zuck would say, "I want to increase the resolution of photos, you know, by a factor of four." And the engineers would say, "Well, we can't do that because blah blah blah." And he'd say, "Yeah, I understand. Still want to see the photos looking better." And then people would go and do it, and it would take as long as it would take, or you'd work on it for a while and if it just couldn't for whatever reason, then you'd switch to something else.
Early on I had lunch with somebody who'd come from Microsoft and said the thing about Facebook is if you're at Microsoft and you have a good problem to solve, you will defend that problem tooth and nail because there aren't enough problems to go around. And at Facebook, if you're solving a problem and somebody else starts solving it, you just go on to the next thing because there's always some other trash fire burning someplace else. And that's certainly no longer true at Facebook. It's opportunity starved. Then it was opportunity rich.
I accidentally saved $5 million a year during my boot camp. No way. I was looking at the photos code, which at that time was a single PHP file that I printed out and taped it all together. It was 18 pages, the whole, that was photos, and it was the biggest photos site in the world at that time. And I looked at it, I thought, man, there's something wrong here. We were very careful to reduce the number of round trips between the front-end code and the cache or, even worse, databases. And so I looked at it and I realized, oh yeah, this can be made more parallel. So I made that switch and a week later the photos manager came to me and said, "Oh, ops noticed that the demand on the photos machines suddenly dropped when we rolled your stuff out, and they can decommission enough servers to save $5 million a year." And I was just farting around, you know?
So it was like the gold rush, and there's just gold nuggets sitting on the ground and you just pick them up. That's not true today, and even by the time that I left it was no longer true in that same kind of sense. But you could just be a programmer and do programmer stuff and you had enormous leverage, which was part of the magic of it at that time.
This is pre-IPO. The middle management, middle engineering management, like first and second level of engineering management, all had generational wealth in vested options but had to go public. So that tier was very focused on global optimization, not local optimization. They would give up. You know, you talk to some team and they're like, "Well, we could really use you, but I think you really should go here cuz that's what's going to make my stock options go up the most." Yeah. Which is crazy behavior once you get into this scarcity desert kind of mindset. Like, nobody's going to act that way. But at that point, it was extremely novel.
I collected a whole series of this. I found this manuscript the other day, How Facebook Works. There were a bunch of policies that I had never seen before. One of which was 50/50 goals. So, six-month performance review cycle. At the beginning of six months, you'd say, "Here are my goals." And when you reviewed those with your manager, if you had accomplished half of the goals, you get A+. If you accomplished everything you set out to accomplish, people, you know, you're sandbagging. You're not trying hard enough. You're not risking enough. You didn't learn anything over the course of the six months. If you accomplished none of your goals, you were just out.
So engineers and engineering managers would get fired much sooner than I'd ever seen anywhere before, which creates anxiety, but it also, like, you knew you didn't have to protect yourself from slackers, because everybody else was under the same kind of pressure and you were all trying to make the world more open and connected. Now it turns out the world can be too open and connected, but that's a separate set.
Yeah. But it feels like you were there during the golden years. Now morale is terrible, with all the engineers being assigned without asking them to do data labeling. It's all turning into a very different culture. But I guess it just shows that places do change. But it seemed that was a time where Facebook was growing. The mission was very interesting. It was, as you said, opportunity rich, and you were coaching engineers there. What did you learn about folks who are already, I guess, pretty standout if they got into Facebook? In what ways could you help them or did you help them?
So about a year in, I'd been working on a C++ project, infrastructure for the Facebook Messenger product, which had come out, become very successful, kind of outgrown its infrastructure, needed support. And I was not a good C++ programmer, and so I was not going to stand out there. I had six months to turn stuff around. And in the missing years I kept body and soul together by doing coaching, remote coaching. And so I knew I'd had, I don't know, hundreds of hours, maybe thousands of hours of coaching interaction.
And one of my friends at Facebook, an old-timer named Peter Demov, said, "You've talked about this coaching stuff. Why don't you just start doing that?" And Facebook was very much: you're an engineer, you feel like doing a thing, you do the thing. If it doesn't work out, you take the consequences. If it does work out, you get the rewards. So, I thought, "All right, I'm a coach now." So, I hung out my shingle and I found my first three students and started with daily one-hour conversation, which turns out to be way too much, for 3 weeks or four weeks or something. And two of the students worked out well and one of them got fired.
But yeah, they told other people, so people would come to me and ask for this coaching thing, which evolved into a program called Good to Great. And the idea was I'll talk with programmers who are good but have kind of stalled. You know, there's this punctuated equilibrium that happens where people get better and then they gather experiences without growing much, and they need a little kick to get them up to the next. And so that's the good to great part.
And I was coaching people one-on-one. I'd coach six people at a time, which is exhausting, but I was also matching up other senior engineers with junior engineers for coaching. And then we would have the meta conversation of coaching the coaches. Tell me about something that happened this week that you didn't know how to react to or was difficult, or we'd all talk. I brought in a storytelling consultant to do an offsite. I hired Aaron Oorc, was my administrator, cuz this is not my strong suit, kind of lining stuff up. And she worked with HR to analyze the program and discovered that the people who'd been my students were twice as likely to get promoted in the year following coaching than a cohort that was the sameish but didn't get coaching. So it really worked to accelerate the career progression of the people.
I didn't handle the politics of it very well. So this was learning and development outside of the learning and development organization, and I didn't understand that that was going to be an issue. So by the time I left there were big fans of Good to Great, but there were also people who didn't like the fact that it was around.
So I ended up coaching probably 200 people individually. I would write classes that I would give and that I'd teach other people then to give, that thousands more of engineers went through. And just before I left, I went to an offsite with the top 1% of Facebook engineers. And out of the 100 plus people, 100ish people there, 10 of them were former students of mine who had gotten promoted to that level. So I felt really good about how that all worked out.
That was kind of back to Ward. That was a kind of interaction that I was able to have with Ward. It's not always pleasant. It's not a pat you on the head and you're going to be fine. It's a, no, you're screwing this up. Go try this thing. Tell me how that works. Oh, you didn't try the thing? Oh, you don't want to work on this? Okay, we're done. Quite uncompromising. I say coaches are there to identify and induce productive discomfort. But the coaching program as a whole, by the time I left I had great-great-grand students. I'd coached people who became coaches who coached people who became coaches who now were coaching. I think there's an element to that, a way of learning in that kind of style, that just can't be duplicated.
So when Dario says we're going to eliminate software engineering, you don't understand what software engineers do. We're going to transform some of the activities that go into software engineering. Absolutely. I'm having a blast. But this idea that we're code monkeys, requirements and Jolt Cola in, code out. Come on.
To be honest, I do sense that Dario has a disdain for developers, software engineers, should I say. Or I've never seen an indication that he likes them or that he was one.
No, he clearly wasn't one. This is fine. It's like a physics background or something like that. That's fine. And you can say I'm going to replace your job. To me, I don't consider that disrespectful. That's ignorant.
By the way, can we talk about, you brought this up multiple times in our discussions. People awfully want to replace us developers, and we should probably reflect a little bit on that. You've had time to reflect. Why does this keep coming back?
Just, we're kind of sometime. I mean, that is the long and the short of it. My perspective is someone on the spectrum who's been an engineer for a long time, whose dad was an engineer, whose grandfather was a geek, you know, in his radio kind of way. So, I come by this all honestly.
We don't necessarily have good emotional regulation skills. Don't have natural empathy. It's why I play poker, by the way, so I get feedback when I don't have good empathy. We oftentimes are more direct than other people can easily handle. Yeah. In the business setting. Yeah. I'm just telling the truth, or I was just asking a question. Those are the most hideous things that I say, because, okay, yeah, you were just asking a question, but you're being an asking that question. And I didn't realize it, but I was, cuz that's how people react.
So I don't expect anybody to cut me any slack. There are people who say, "Well, it's up to the rest of the world to adapt to the ways that I'm weird." It's just not, because, I mean, it's not going to happen. So, learning empathy, learning how to read body language, learning how to read tone of voice, this is not natural skills, but they're skills. They're learnable. I'll never be as good at them as my partner, who's a social genius, but I can be not horrible at those kinds of skills.
Things like belligerence. That's a common social strategy for people like me, and has been a social strategy of mine. There's some disagreement between us and the way I resolve it is, you know, how long is this going to take? Four weeks. Has to be done in two weeks. Yeah, that's an invitation to have a conversation. When I say four weeks and you say no, it has to be two weeks, I don't have to shrink and say, "Okay, I'll try and get it done." I also don't have to say, "Yeah, go to yourself, jackass." Neither of those responses help. Say, "All right, well, let me understand your needs." Not an easy task for me, but I can do it. I have a little checklist. You know the first Terminator movie, where he's got the little pull-down menu of responses? Yeah, it feels like that oftentimes. But it's better to have the pull-down menu of responses than to do something that alienates the other person and ends the conversation before it's actually finished.
I think it's those kinds of things. It behooves us to learn how to communicate in a style that other people can actually listen. Which is why I bring in analogies from the finance world, from sports, from history, from every place I can find, in a desperate attempt to understand other people and help them to understand my perspective and what that brings to the situation in a way that they can actually comprehend it.
Jumping to the present times, where now for a couple of years we've had AI, LLMs, but now we just call it AI, or as you call it, the genie. Yeah. And it grants wishes, but it's not actually what you want. And it has some interesting characteristics. I'm wondering, how do you think this will change individual developers' work and also teams, companies, how tech companies are building software? What are you seeing so far? We talked a lot about what software engineering really is. We talked about the understanding, the communication, the learning as you are coding, and it seems that that is definitely shrinking, if not being taken away.
That's a choice. But I'll let you finish your question.
Just looking across the industry. Yes. And it also feels that there's this analogy, what you said when interfaces were out, that people were overdoing the interfaces, and it feels like this. We have these AI agents, or genies as we call them, and people are using it everywhere and they're going mad and forgetting some of the sensible stuff.
Yeah. What an open-ended question. So one of the things is that the pace of development is definitely accelerated. One thing I wonder: the pace of business hasn't accelerated, though, and that mismatch is going to become more and more apparent.
So I was at a client. They were showing they were spending $2 million a year on some SaaS product. Somebody vibe coded a replacement for it that was better for their uses and didn't cost $2 million a year. How is that vendor going to reply to that? Back in the olden times, two years ago, they'd have years to respond to, "Yeah, we have this add-on. It costs $2 million a year, but people don't really like it, and eventually they're going to find a replacement. We have five years to respond to that, or three years to respond to that." Now they've got, we have this add-on, we've been able to charge for it. That's going to go away in a month.
On their side, they could code up a replacement that was better. Yeah, they could code up, they're seeing the same kind of acceleration everybody else is. But is the need for a replacement going to go through their customer service to marketing to sales to business development to the product organization, da da blah blah blah? That chain is designed to take five years, and now they have a month, or they're going to be losing big chunks of revenue. This isn't AI's fault. This is just an acceleration, and their business process is just not prepared to respond in time. My personal definition of agile is responds in time, and they're not prepared to deal with the new pace.
Like, you're driving a tractor and all of a sudden you're in a race car. Still wheels, still an engine, but are your skills prepared to steer that car? Not how fast can it go, but how fast can you get from point A to point B on a windy mountain road? You're used to driving a tractor and now
You're in a Ferrari. It's not the car's fault, but I think that's a trend that I expect to play out, that we're going to see companies fail because they don't respond in time. They've been fat and happy. Kind of newspapers with, another analogy, newspapers with classified ads. Classified ads paid for reporters and paper print, you know, stuff printed on paper and taken around to everybody's houses, and then classified ads went away and journalism had to respond, and it's responded well in some ways but poorly in others, and we're less served by local journalism than we were before all this happened.
Okay. So now we have people who've been able to rely on switching costs to protect their profits, and the switching costs just drop to zero. Their profits are going to drop to zero, and some people aren't going to survive that change. Some people will. The flip side.
So you're paying for some service. You think, I could vibe code something better. And so you do, but you only solve this much of the problem. It's the... The part of the iceberg... You can see that you can vibe code the part of the iceberg that you can see.
So I'll talk my own book. I was at Gusto for three years, does small business payroll. Somebody said, "Well, I just asked Claude, I have this many hours at this rate, I'm in this tax bracket, what should my paycheck be? And it tells me all the numbers. I don't need Gusto anymore." And I'm just like, oh, you have no idea. Go ahead, run your own payroll for a quarter and then figure out all of the reports you need to submit to the various tax agencies and different states, and I live in this one, but I work in that one, and the company's based here, and now what should the number... Like, there's so much that goes on to correctly, compliantly execute payroll that isn't gross pay, net pay. So we're going to see people get into those where they're like, "Well, I vibe coded the tip of the iceberg. I threw away the rest of the iceberg, and now I'm in trouble because now I don't know what to do. Now I get to these downstream problems that I didn't even know existed." So we're going to see, on the side of the vibe coding replacers, we're going to see that kind of a naivety play out.
And what about for software engineers? Because a lot of the identity for engineers was around being able to craft code, caring about the craft, being able to visualize a lot of these things. And these tools are getting really good at doing a bunch of that stuff. What advice do you give to these folks on, okay, well, there's this new technology change, if you'd like to stay a top-of-the-game software engineer, what activities can you do, what mentality change should you do?
So my inspirational motto is: nobody knows. People come to me, they say, well, how does TDD apply in the augmented coding world? I said nobody knows. It's not just that I don't know, it's that nobody knows.
The big lesson I learned at Facebook was that there are three different phase states of software development. This exploration phase, where you've got to try a bunch of different things because you can't predict. Then something takes off, and we've talked about a bunch of those examples from my career. And the discipline of riding that rocket up once it's been lit is very different than the discipline, and it is a discipline, of exploring the space. So while you're expanding, you focus very intently, and it might even be unsustainable, but it doesn't last very long. And then there's another, you get to extracting value from that to feed the next set of explorations. This is 3X.
Right? Explore it. This is yet another model that you came up with sometime in 2016, '17.
Yeah. '15, '16, I finally figured out. I felt that I understood how Facebook had been able to be large, growing, and innovative at the same time. And it was by treating projects at different phases in a completely different style.
So, explore.
Explore is you're just looking for something and you can't predict. So you have to try as many... it's a numbers game. You try as many uncorrelated experiments as you can for the cheapest price.
Then you expand.
And then something takes off, and then you're in this expansion phase where, instead of trying a little bit of everything, you focus on the one thing that's working and you discard everything else, and you overcome obstacle after obstacle after obstacle. And then you get to a certain size, and now you can predict growth, and you can say, you can write a... if we roll out our product in a new country, we've done five countries already, here's the playbook, and you know how to do that. That's that extract phase. You've reached economies of scale. You can make small tweaks and it makes a big difference. You have a long life span also.
So how you write code, how you manage projects, who you hire, how many people, what the org structure is, is completely different in the three phases. For 20 years, we've been up in that extract stage. There's been a playbook. It's evolved a little bit, but you know, oh, we have too many bugs in production, here's the three things you can try. Oh, you know, we need to accelerate development, here's the things you can do. Now, people sometimes didn't do the things, but the playbook existed. And to be a senior engineer meant that you knew the playbook. And the more you knew the playbook, the more effective you could be. If you knew, oh well, I also know how to scale backends, you know, I know about idempotency and what advantages that brings if I implement it, and so on. Nobody knows now. That playbook has been wiped clean, and people whose identity is "I know the playbook" are now terrified. Who am I?
Now, it turns out that the skill of writing a playbook is completely different than the skill of applying a playbook. That stuff that we did in the days of objects, that was writing a playbook. That was that explore part of the curve. It's not that there isn't a way to be effective when you don't have a playbook. It's just that it's a different game. And the people who don't feel safe without a playbook need to turn their heads around to, like, well, nobody knows. It's not like there's some secret playbook for genie-based development that, you know, if only I paid a million dollars, I could have it. It just doesn't exist.
When we get glimpses of it, it changes next week. Like, small changes to the inputs cause large changes to the outputs. So we're all back in explore stage in this, where the more things we can try, the better. I'll get these questions: "Oh, well, I think we should blah blah blah. Instead of writing one test at a time, maybe we should write a bunch of tests at a time. Do you think that would work?" Nobody knows. Try it and tell us how it goes. If more people are trying more things in community and communicating, like, I did this thing here, I added this markdown file and it had this effect. Somebody else says, well, I added it and it made things worse. Okay, well, what's different about yours? Having that conversation, that's what's going to result in the playbook.
The Agile Manifesto, dated 2002, right?
2001. Yeah. 2001. The first OOPSLA, 1986. It took 15 years to write that manifesto, which is why when I see manifestos today, I'm just like, too soon. Not a bad idea. Would love to have one. Just too soon. It took 15 years for the technical change of object-oriented programming to come before we could say, here are the consequences of it. Here's how, in a simple way, we can express how to effectively use this technology that we've been using day in and day out for 15 years. The genie comes along. People are like, "Well, what's the new manifesto?" It's just not manifesto time yet.
As a closing, what do you find exciting looking ahead with AI agents, with genies, with all this change, with this clean slate that we're in? What gives you energy?
This is home base for me. The writing of the playbook. I just love that. I'm a tree shaker, not the jelly maker. So I love shaking the tree. I love getting stuff started. I have a very wide range of projects. So I have a project called Arlo, which is an object-oriented database. I have several fundamental data structures. I wanted to see if I could write code that was library-quality code for a language I didn't know. It turns out, yeah, I can. So I built a B+ tree that's faster than Rust's B-tree for some operations.
Wow.
Wow. Yes. But also, I'm not a Rust expert. Like, what could a Rust expert do with these same tools? And why didn't they write it? I don't know. But I'm building little bits and pieces of apps for stuff that I care about. I use the genie for business planning because, like you, I have a newsletter. Unlike you, my newsletter is kind of small, but it's pretty big. I'm doing okay. Now, how do I turn that into a sustainable business? Also, I hired a business partner to help with that. So I'm doing a lot of writing, reflecting on my experiences. I'm trying everything. If there's a secret sauce to what I'm doing, it's not being afraid to start over.
And your whole career shows this, from the very early days. TDD, XP, 3X, Tidy First, Genie.
Yeah. So if you look on my GitHub, you'll see project, project two, project three, project four, new project, new project two, new project three, new project. I'll take it, I'll push it a certain amount, and then the genie runs itself out of options, it can't make further forward progress, and so I'll wipe it away and start over. I won't try and tweak. I'll start over and say, all right, well, if I implement things in a different order, if I implement with this markdown file, or if I implement it with this commit hook... We collectively need to try absolutely everything. And some of those ideas are going to sound stupid and are going to work out great. Some of the stupid-sounding ideas are also going to be disastrous. But if we're willing to start over, then it doesn't matter. We're not really risking that much.
That creative impulse is what's come back to me with the genie. This idea that I can go, I wonder what a B+ tree looks like in Go. Here's an alternative to the B+ tree, this adaptive radix tree. What does that look like? I can find out. I sit down with a genie, I can work it out, and then there's this artifact that wasn't there before that's there now because of my imagination and my work.
And I had gotten fed up with the stupid minutiae of programming. Oh, for that you need to have version 7.1 of the... upgrade the thing, which then causes something else to break, which causes something else to break, which means that I can't use version 7.1. I have to... I just hated that. Having an idea, getting emotionally invested, getting a ways in and realizing I can't do this for no good reason. I hated that. And that kind of blockage just doesn't happen to me now. And oh, so this is hog heaven. I've got 40 years' worth of ideas, "This would be cool, but it's too big," that suddenly are back in play. And I'm having so much fun making things that are real.
I can see it. And you're sharing it as well. Kent, this was awesome, especially doing it finally in person.
Yeah, it was great. Great to be able to sit down with you in your home country. Here we are.
This was a special episode for me, recorded in Budapest, Hungary, right before Craft Conference 2026. It was a first getting to hear Kent walk through his entire career, start to present, in a way he's never done in a podcast before. One thing I think back to is how Kent said, "We're accumulating code faster than we're accumulating trust." Kent is so good at summarizing very true things like this. When you struggle through understanding a domain, represent it in code, and write tests that prove that you got it right, you end up trusting your program. And when you do that work alongside other people, you build trust with these people, too. Kent's point is that none of this happens when you just prompt an AI, or a genie as he calls it, and you get back code that works, and the AI says, "It's all done."
I also loved how consistent Kent has been across 50 years. Whether it's Smalltalk, design patterns, TDD, or AI today, his instincts are the same: try the stupid idea and don't be afraid to throw it all away and start over. As he put it, he's a tree shaker, not a jelly maker. And Kent's tree shaker impulse is right back on, with him trying stupid things with AI.
Finally, I appreciate how grounded Kent is. People kept asking him what the new manifesto for AI development is, and his answer is that it's too soon. The Agile Manifesto took 15 years of doing object-oriented programming before people like Kent could summarize the lessons. With AI, things are still changing quickly, and Kent is honest when he says that right now nobody knows what is working.
Do check out the show notes below for how Kent and I both thought that McKinsey did not know what they were talking about when they wanted to measure software engineering productivity. Also check the show notes for related Pragmatic Engineer deep dives on topics like tech, software craftsmanship, TDD and others. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show.
Article published