Martin Fowler on AI and Software Engineering: From Determinism to Non-Determinism
The Pragmatic Engineer
Martin Fowler, Chief Scientist at Thoughtworks, co-author of the Agile Manifesto, and author of Refactoring and Patterns of Enterprise Application Architecture, sat down in person with the host of The Pragmatic Engineer to discuss how large language models are changing software development. His central claim is that AI is the biggest change of his career, comparable to the move from assembly language to the first high-level languages. What makes it different, he argues, is less the rise in abstraction than the move from deterministic to non-deterministic tools. The conversation also covers his career, the Thoughtworks Technology Radar, vibe coding, testing, refactoring, design patterns, the Agile Manifesto, and the state of the industry.
An Accidental Route into Software
Fowler describes his entry into software in the late 1970s and early 1980s as largely accidental. At school he got poor marks for writing but did well in mathematics and physics. He also says he is "hopeless with my hands," unable to do things like remove rusted nuts from his car. That pushed him toward electronics, which needed little more than a soldering iron, and then to computers, which didn't need even that. Before university he spent a year at the UK Atomic Energy Authority writing Fortran IV. After a degree mixing electronic engineering and computer science, he chose computing over traditional engineering jobs, which he saw as poorly paid and low in status.
His first job was at the consulting firm Coopers & Lybrand. He wasn't hired as a strategist. He looked after Unix workstations because he was one of the few people who knew Unix. The small group he worked with had adopted ideas from a consultant who packaged them under the label "object orientation." Looking back, Fowler says there was "a lot of snake oil involved." He adds that this is a little unfair, because some of the ideas were very good, and the work got him into object-oriented thinking in the mid-1980s.
There he met Jim Odell, an American independent consultant and teacher who became his biggest early mentor. Fowler then spent a couple of years at a small company whose UK office, with four people, was its largest. After that he went independent, helped by work that Odell passed to him. He remembers thinking he would never work for a company again. He wrote his first books as an independent consultant, moved to the United States in 1993, and worked with Kent Beck on Chrysler's C3 project, which he calls the birth project of Extreme Programming.
Joining Thoughtworks and the "Chief Scientist" Title
Thoughtworks began as a client. It was running a project of about 100 people that Fowler says was "clearly going to crash and burn." He helped them see what was happening and recover, and they invited him to join. His reason for accepting was that other clients would say good ideas were hard to implement and stop there, while Thoughtworks would say they were hard to implement and try anyway, and usually pulled it off. He expected to stay a couple of years. That was 25 years ago.
He jokes that as Chief Scientist he is "chief of nobody" and does no science. The title was popular at the time for public-facing thinkers; he recalls Grady Booch holding it at Rational. The irony, he says, is that Thoughtworks employees could then choose their own titles, but he was not allowed to. Thoughtworks rejected his preferred alternatives, such as "flagpole," "battering ram," or his favorite, "loudmouth."
How the Technology Radar Is Made
The host lists items from the newest Radar, which came out on the day of recording. In "Adopt" are pre-commit hooks, ClickHouse for analytics, and vLLM for running LLMs efficiently. In "Trial" are Claude Code and FastMCP. Many AI-related items sit in "Assess." The host asks how Thoughtworks stays so close to the industry.
Fowler traces the Radar to a technology advisory board set up just over ten years ago by then-CTO Rebecca Parsons, who wanted practitioners to keep her informed about projects. Fowler was on the board mainly because he was a public face of the company. At one meeting, her technical assistant suggested building a picture of which technologies projects were using and how useful they were, because the company struggled to spread good ideas internally. That struggle existed when it had a few thousand people and is harder now that it has about 10,000. The assistant came up with the radar metaphor and its rings. Thoughtworks habitually publishes what it builds for internal use, so the Radar went public.
The process has changed as the company grew by an order of magnitude. People now nominate "blips," which are entries on the radar. They brief someone connected to them by geography, line of business, or technology, who in turn briefs what is now called the Doppler group ("we can be a bit loose with our metaphors"). Blip-gathering sessions happen a month or two before the meeting, and in the meeting the group goes through candidates one by one. Fowler calls it a bottom-up exercise. He admits he is now so far from day-to-day work that he doesn't recognize most of the technologies, though he sometimes picks up themes. Microservices, about ten years ago, was one such theme; it came through the Radar and led to his writing on the subject with James Lewis.
Both men note that Thoughtworks encourages clients to build their own radars. Fowler says client radars differ: they can be more prescriptive about what teams should do, and they can simply decline to engage with a technology. Thoughtworks can't do that, because if its clients use something, it has to learn it.
The Biggest Shift Since High-Level Languages
Asked what earlier change compares to AI, Fowler says it is the biggest of his career. Across the whole history of software, he thinks the closest parallel is the move from assembly to early high-level languages like COBOL and Fortran, which came before his time. He did a little assembly at university, which was useful mainly because it made him never want to do it again.
He describes what that transition meant. Assembly instructions differed from chip to chip, and even simple tasks required convoluted sequences of moves between memory and registers. Even Fortran IV, which he calls relatively poor, let you write conditionals and loops. It had no "else," allowed only one statement per "if," and needed gotos for blocks, but it moved programmers away from the hardware toward something more abstract. It also decoupled code, to some degree, from whether it ran on a mainframe or a minicomputer.
He thinks LLMs bring a similar degree of mind shift, but the character is different. There is some increase in abstraction. The larger part, he says, is "the shift from determinism to non-determinism," where you suddenly work in an environment that is non-deterministic, "which completely changes" how you have to think.
Abstraction, Rigorous Language, and Engineering Tolerances
The host asks whether English is simply the next abstraction layer above high-level languages. Fowler agrees there is some jump in abstraction but says it is smaller than the determinism jump. He emphasizes a feature of high-level languages he didn't mention earlier: the ability to create your own abstractions within them. Fortran allowed some of this through subroutines, and object-oriented and functional languages like Lisp allowed much more. He cites an old Lisp adage that you should create your own language in Lisp and then solve your problem in it. Balancing problem-solving with language-building, he says, is what leads to maintainable, flexible code.
AI helps a little here, he suggests, because abstractions can be built more fluidly. The catch is that their implementations are now non-deterministic, and "we've got to learn a whole new set of balancing tricks." He points to his colleague Unmesh Joshi, who uses the LLM to co-build an abstraction and then uses that abstraction to talk to the LLM more effectively.
He recalls reading, in a book he couldn't name during the interview, that if you describe chess games to an LLM in plain English it doesn't learn to play, but if you describe the same games in chess notation, it can. Fowler thinks this is partly because notation shrinks the token count, but mainly because it is a more rigorous notation. That suggests we may need rigorous ways of speaking to LLMs. He connects this to domain-driven design's ubiquitous language and to his work about a decade ago on domain-specific languages and language workbenches.
The host asks whether this is the first time non-determinism has become so widespread in software, since earlier neural nets were niche. Fowler agrees it is a whole new way of thinking, but sees parallels in other engineering fields. His wife is a structural engineer who always thinks in terms of tolerances: how much margin to add beyond what the math says, because material properties vary and you design for the worst case. Software, he argues, needs similar thinking about the tolerances of non-determinism, and must avoid skating too close to the edge. He expects "some noticeable crashes," particularly in security, because people are already skating too close.
Where LLMs Already Help: Prototypes and Legacy Code
Fowler names two areas of clear success at opposite ends of the scale. The first is rapid prototyping and exploration, the territory of vibe coding. Someone unsure of an idea can spend a couple of days exploring it far faster than before. That covers throwaway explorations and small disposable tools, including ones built by people who don't consider themselves developers. There is good reason to be suspicious of taking this too far, he says, but kept within its bounds it is very valuable.
The second is understanding legacy systems. Colleagues at Thoughtworks did semantic analysis of code, loaded the results into a graph database, and queried it in a RAG-like style. They could ask what happens to a piece of data, or which parts of the code touch it as it flows through the program. Fowler calls this "incredibly effective." Using generative AI to understand legacy code is one of only four items in the Radar's Adopt ring. He explains that it came from people already doing legacy work who tried the approach. Legacy modernization is a constant concern for Thoughtworks, since every company older than a few years has the problem "in spades."
What's Still Unresolved
Beyond those two areas, Fowler says practices are still being worked out. For building decent-quality software one-on-one with an LLM, he sees signs that you need very thin, rapid slices. Every slice should be treated as a PR from "a rather dodgy collaborator who's very productive in the lines of code sense," which means reviewing everything carefully. He mentions Kent Beck's name for the tool, "the genie," and Birgitta Böckeler's anthropomorphic donkey, Dusty. Used well, he says, the speed-up is real but not as large as advocates claim. It is "non-trivial" and worth learning. He names Birgitta, Kent, and Steve Yegge as people pushing this work forward.
Most of this experience, he notes, comes from greenfield work. Whether LLMs can safely modify legacy code is still open. He tells a story from James Lewis, who asked Cursor to rename a class in a modest program. It took an hour and a half and used about 10% of his monthly token allocation. The host recalls that JetBrains' ReSharper made class renaming a paid right-click feature around 20 years ago, and that early Swift in Xcode lacked such refactorings, which drew complaints. Fowler says Lewis did it to see what would happen, since the deterministic tooling has existed for a long time. He takes the point to be that modifying existing systems is still "really up in the air."
Team dynamics are the other open question. Software is built by teams, and Fowler expects that to continue. Even if AI made developers an order of magnitude more productive, which he doesn't believe it will, a team of 10 would still be needed where 100 were before, and he sees no sign of demand for software dropping. How to work with AI in a team setting is something "we're still trying to figure out."
Vibe Coding and the Learning Loop
Fowler uses the original definition of vibe coding: you don't look at the output code at all, and you may not know programming. He considers it good for explorations and disposable work, but not for anything with long-term life.
His example involves Unmesh Joshi, who asked an LLM to produce an illustrative "pseudo-graph" of capability over time for an article and committed it. Fowler wanted to move the labels closer to their lines. He opened the SVG and found it "astonishingly" convoluted and "gobsmackingly weird," although he had written the previous version himself in about a dozen lines. The lesson he draws is that vibe-coded output can't be tweaked. You throw it away and hope regeneration gets you what you want.
The deeper problem, which is the core of an article by Unmesh that had just been published, is that vibe coding removes the learning loop. Programming involves constant back-and-forth between ideas and what the computer does. Fowler agrees with Unmesh that this process can't be shortcut. If you don't look at the output, you don't learn. If you don't learn, you can't tweak, modify, evolve, or grow what you produced. "All you can do is nuke it from orbit and start again."
The host admits to getting tired while reviewing large volumes of AI output and letting things slip, and says many engineers worry about rigorous review as code volume grows. Asked about approaches that help people keep learning, Fowler says he hasn't seen a huge amount. He finds Unmesh's direction most promising: working with the LLM to build a language that communicates more precisely what you want. He adds another use Unmesh has highlighted, which is getting oriented in unfamiliar environments. James Lewis, for example, was using the Godot game engine on a Mac with a language he didn't know well. Fowler himself asks LLMs how to do things in R that he has done twenty times but can't remember. Generating a starting skeleton project is another such use.
Stack Overflow, Testing, and Tools That Lie
The host compares the moment to Stack Overflow's arrival, when junior developers pasted snippets without understanding them. He cites a top-voted but flawed email-validation answer that spread widely. Fowler agrees it is similar but "on steroids." He raises a further question: who will write Stack Overflow answers in the future? He has no problem with pasting LLM output to see if it works. After that, you should understand why it works, consider whether it is structured the way you'd like, not be afraid to refactor it, and write a test for anything that works.
He cites Simon Willison as someone who constantly stresses testing, and notes that Birgitta, coming from Thoughtworks' Extreme Programming culture, says the same. The host describes LLMs claiming all tests passed when running them showed five failures. Fowler replies that they "lie to you all the time." If they really were junior developers, as people sometimes describe them, "I would be having some words with HR." The host adds a personal case: asked to add today's date to a config comment, the model copied the previous entry's date and, when corrected, put in yesterday's. They agree on "don't trust, but do verify."
Summarizing where Thoughtworks developers are finding success, Fowler repeats prototyping, legacy understanding, and exploring new technologies or even domains, "as long as you trust it significantly less than you would trust Wikipedia 10 years ago."
Spec-Driven Development and Domain Languages
On spec-driven development, which the host says Birgitta is exploring, Fowler sees a risk of repeating waterfall if people write a large spec up front and pay little attention to code. What matters to him is doing "the smallest amount of spec you can possibly get to make some forward progress," then building, testing, and ideally deploying, in thin slices with a human verifying each time. He says Birgitta agrees on that point.
What interests him is whether specs can become a more rigorous, domain-language-like way of expressing abstractions, more fluid than code allows but still parallel to the codebase in the spirit of ubiquitous language. He notes that some programmers have already written business logic in, say, Ruby that domain experts could read. The experts couldn't write it, but they could spot what was wrong and suggest changes that a programmer could then make syntactically correct. That takes deliberate effort in how the language is designed. The open question is whether LLMs will let this happen more widely.
The Enterprise World
Fowler says the corporate enterprise is the world he knows best. There, developers are a small minority, business processes are complex, and legacy problems are usually worse. When the host offers banks as an example, Fowler replies that banks tend to be more technologically advanced than most corporations; retailers, airlines, and government agencies are often further behind.
He describes speaking at an agile conference for the Federal Reserve in Boston. Its staff are not currently allowed to touch LLMs because the consequences of error are so serious. On a tour of the cash-handling area, he saw the care and controls around sorting and counting notes. That made him think of an adage that to understand an organization's software development, you look at its core business. An airline's concern with safety, he says, shapes its thinking in the same way, "or ought to."
Asked how cautious enterprises differ from nimble companies, Fowler stresses that big enterprises are not monolithic. Some parts are adventurous, as his own small group at Coopers & Lybrand was, and "the variation within an enterprise often is bigger than the variation between enterprises."
Refactoring: Origins, Revision, and Renewed Relevance
Fowler first encountered refactoring when Kent Beck showed him, in a Detroit hotel room early in the C3 project, how he refactored Smalltalk code. Fowler had always cared about making code comprehensible, but he was struck by how small Beck's steps were. Because they were small, they didn't go wrong, and they composed into large changes. Beck was busy with the first Extreme Programming book, so Fowler decided to write the refactoring book himself. He took careful notes each time he refactored, which became the "mechanics" sections, and added an example for each. He used Java rather than Smalltalk because Smalltalk was "dying sadly" and Java was, in late-1990s thinking, "the only programming language we'd ever need."
He stresses that Beck didn't invent refactoring. Ralph Johnson's group at the University of Illinois at Urbana-Champaign built the first Refactoring Browser in Smalltalk, with John Brant and Don Roberts. IBM's VisualAge team, originally Smalltalk people, was aware of it. JetBrains, with early IntelliJ IDEA and later ReSharper, made automated refactoring something developers could rely on. Knowing how to refactor by hand still matters, he says, because some languages lack these tools and some refactorings aren't automated.
The word became common and was misused to mean any change. Fowler insists refactoring means very small behavior-preserving changes, "each step is so small that it's not worth doing," strung together to achieve a lot. The host recalls colleagues announcing "I'm doing a refactoring" at stand-up for days on end.
The 2019 second edition switched to JavaScript, both to reach a broader audience and to be less object-centered ("extract function" instead of "extract method"). Fowler also wanted to refresh the examples and give the book "another 20 years of life" to "keep me going until I croak."
On whether refactoring has caught on, Fowler says it is hard for him to judge because he mostly talks with Thoughtworks people. He reads plenty online that makes him shake his head at how refactoring is described, let alone practiced. He maintains that the disciplined approach is actually faster. Progress has been real, especially in tooling, "maybe not as much as I'd have hoped for."
Looking ahead, he says he isn't seeing it yet, but expects refactoring to become increasingly important. If AI produces a lot of code of questionable quality that works, refactoring is how to improve it while keeping it working. He says current LLMs "definitely cannot refactor on their own." He points to Adam Tornhill's work combining LLMs with other tools. The host notes that describing a small refactoring to a command-line agent often takes longer than doing it in an IDE.
Fowler sees promise in LLMs as a front end to deterministic tools, much as people use LLMs to draft SQL they can then check and adjust. He recalls a large company's API migration across a big codebase, about a year earlier, that was reported as an LLM achievement. By his account it was roughly 10% LLM and 90% another tool, whose name he couldn't recall. The interesting interplay, he says, is "using the LLM as a starting point to drive a deterministic tool," so that you can see what the deterministic tool is doing.
Why Patterns Went Out of Fashion
The host notes that design patterns were common interview topics around 2002, when Patterns of Enterprise Application Architecture appeared with more than 40 patterns such as Lazy Load and Identity Map, but faded from mainstream discussion in the 2010s. Fowler explains that patterns aim to create a shared vocabulary, much as medicine uses Greek and Latin jargon. They are useful for describing alternatives and deciding when to apply something, not for cramming as many into a system as possible. He suspects they may have lost favor partly because people used them "like pinning medals on a chest." He recently worked with Unmesh Joshi on Patterns of Distributed Systems and still finds the form valuable. Why patterns became unfashionable, he says, is hard for him to judge, and they may come back.
The host suggests startups treated patterns and strict UML as legacy baggage, preferring whiteboard boxes, and that each generation reacts against the last. He also relays Grady Booch's view that well-architected cloud building blocks such as managed databases reduced the need for architectural thinking. Fowler suspects there are still patterns for using those services but hasn't explored them, partly because colleagues haven't brought him draft articles on the topic.
Both agree that every organization develops its own jargon, including internal system names. Fowler says books like his try to offer shared words across environments, and the mismatches only show when you move between them. He tells of someone who joined an established bank from a startup and said that after three years they finally understood the problem. Such systems are not logical, Fowler says, because they are built by humans: vendors favored by one manager, reorganizations, and personal history accumulate into "a complicated mess." Uber, he says, is lucky to be young, but if it survives 50 years it will look like American Express, whose re-architecture planning the host once learned had taken three years.
The Agile Manifesto
Fowler traces the manifesto to a gathering Kent Beck held about a year earlier in rural Oregon. The group debated whether Extreme Programming should stay narrow or broaden. Beck chose narrow, which left open what to do with the broader set of ideas that overlapped with Scrum and others. That led to the 2001 meeting in Utah, chosen over Dave Thomas's preferred Anguilla. Fowler says he wasn't heavily involved in organizing it, though Bob Martin insists they discussed it over lunch in Chicago.
He remembers little of the meeting itself and regrets not keeping a journal. He would love to know how the "this over that" structure of the values came about. He has a fairly clear memory, which he cautions may be unreliable, of Bob Martin pushing for a manifesto, and of himself thinking the document would be ignored but the exercise of writing it would help the group understand each other. Its impact came as a shock. He quotes Alistair Cockburn: a brilliant idea will be either ignored or misinterpreted, and you don't get to choose which. He points out that the text says "we are uncovering," making it a snapshot of 2001.
For Fowler, agile's success is practical. In 2000, clients resisted what Thoughtworks wanted: tests, automated builds, small increments. The standard approach was a five-year plan with two years of design before implementation and then testing. Thoughtworks wanted to run that entire process for a subset of requirements in a month, "and of course we really wanted to do it in a week." Now clients let them work much closer to how they want. He wanted "the world to be safe" for people who wanted to work that way. Despite bad side effects, he thinks the industry is better off. Measured against the original vision, though, progress is "a pale shadow," and he suspects most of the surviving 17 authors would agree.
Cycle Time in the AI Era
Asked whether AI changes agile, since customers may want quality up front, Fowler says it is too early to know. He still bets on small slices reviewed by humans. He hopes AI lets teams do slices faster, and he would rather have smaller, more frequent slices than more work per slice. He says the biggest gains have come from faster cycles: look at queues in your flow, and if an idea takes two weeks to reach running code, work out how to make it one.
The host describes how Boris, one of Claude Code's creators at Anthropic, built 20 interactive prototypes of a progress-display feature in two days, recording each prompt and output. Fowler ties this back to feedback loops: tightening them so we learn faster about what we are trying to do.
How Fowler Learns, and Whom He Trusts
Fowler says his main way of learning now is editing articles by practitioners for his website. He doesn't do day-to-day production work; the only production code he writes runs his site. Experimentation comes second, when he has time. He reads Birgitta and Simon Willison, whose output rate he envies, and follows Kent Beck, joking that much of his career has been "leeching off Kent's ideas." He occasionally watches videos, "although I really hate watching videos."
He is thinking about how to judge sources in what he calls an epistemological crisis, and plans to write about it. One signal he trusts is a lack of certainty. In the late 1990s he looked for architecture writing from the Microsoft world and found Jimmy Nilsson, whose book was openly tentative about how he currently saw things. Fowler found that trustworthy. He is also drawn to writers who lay out trade-offs. Anyone who says always, or never, use microservices "can be completely discounted." Clients who ask for cookbook answers will get into trouble, he says, because anyone offering one either doesn't understand the problem or is hiding the nuance.
Advice for Junior Engineers
Juniors should use and explore AI tools, Fowler says, but they lack the judgment to tell whether output is good. His advice is the same as ever: find a good senior mentor, who "is worth their weight in gold," and consider prioritizing that above much else in a career. Meeting Jim Odell was "blind luck" and the best thing that happened to him, and he still thinks of Kent Beck as a kind of mentor. With AI, remember it is "gullible and it's likely to lie to you." Ask it why it gives that advice and what its sources are, as you would ask a person about their context, because it is regurgitating what it saw online, good or bad.
Rapid Fire
Fowler's current favorite language is Ruby, from long familiarity, but his love is Smalltalk, which he calls unmatched for fun in the 1990s. He mentions the Pharo project and wishes he had weeks to explore Smalltalk again. For books, he recommends Daniel Kahneman's Thinking, Fast and Slow for building intuition about probability and statistics. He thinks the world would be better if more people understood statistics, and wishes school maths had emphasized it over calculus. Tabletop gaming has sharpened his probabilistic reasoning. He also recommends The Power Broker, about Robert Moses, who was never elected yet controlled more money than New York's mayor or governor for about 40 years. He values it for showing how power works in a democracy, often out of plain sight, and for writing so good he would stop to appreciate passages. Reading excellent writing, he says, makes you a better writer. At 1,200 pages it's long, and he is working through the same author's multi-volume, still-unfinished biography of Lyndon B. Johnson. His board game pick is Concordia, fairly abstract, easy to learn, and rich in decisions.
The State of the Industry
Fowler is positive in the long term: technology can still do huge things, and demand exceeds what we can imagine. In the short term, he describes something like a depression in the developed world's software industry, citing figures he has heard of a quarter to half a million jobs lost. Thoughtworks grew about 20% a year until around 2021 and then "hit a wall," as clients stopped spending. AI is "clearly bubbly," he says, but bubbles are unpredictable in size, timing, and aftermath. Unlike blockchain and crypto, he believes there is real value in AI, though how it plays out is unknown. He sees it as a repeat of the late 1990s and 2000s at perhaps an order of magnitude more scale.
The most important thing to hit the industry, in his view, is not AI but the end of zero interest rates. Job losses began before AI because of it. Macroeconomic uncertainty, including what he calls "Looney driving the bus" in the United States, keeps businesses from investing. The result is a strange mix of near-depression in software alongside an AI bubble.
He still thinks software is a good profession to enter, though the timing isn't as good as 2005. He does not believe AI will wipe out software development. It will change it as dramatically as the move from assembly to high-level languages, but the core skills remain. Those are less about writing code than about knowing what to write, which means communication, especially with users. From his healthcare modeling work, he notes that he learned a great deal about healthcare processes, but you would never want him treating you, because he is not a doctor. That is why domain experts must stay involved, and why he sees effective collaboration as what distinguishes the very best developers.
What similar changes have you seen that could compare to some extent to AI in the technology field?
It's the biggest I think in my career. I think if we looked back at the history of software development as a whole, the comparable thing would be the shift from assembly language to the very first high-level languages. The biggest part of it is the shift from determinism to non-determinism and suddenly you're working in a non– with an environment that's non-deterministic which completely changes.
What is your understanding and take on vibe coding?
I think it's good for explorations. It's good for throwaways, disposable stuff, but you don't want to be using it for anything that's going to have any long-term capability. When you're using vibe coding, you're actually removing a very important part of something, which is the learning loop.
What are some either new workflows or new software engineering approaches that you've kind of observed?
One area that's really interesting is…
Martin Fowler is a highly influential author and software engineer in domains like agile, software architecture, and refactoring. He is one of the authors of the Agile Manifesto in 2001, the author of the popular book Refactoring, and regularly publishes articles on software engineering on his blog. In today's episode, we discuss how AI is changing software engineering, and some interesting and new software engineering approaches LLMs enable, why refactoring as a practice will probably get more relevant with AI coding tools, why design patterns seem to have gone out of style the last decade, what the impact of AI is on agile practices, and many more.
This podcast episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsor. If you enjoy the show, please subscribe to the podcast on any podcast platform and on YouTube.
So, Martin, welcome to the podcast.
Well, thank you very much for having me. I didn't expect to be actually doing it face to face with you. That was rather nice.
It's all the better this way. I wanted to start with learning a little bit on how you got into software development, which was what, 40ish years ago.
Yeah. It was, yeah, it would have been late 70s, early 80s. Yeah. I mean, like so many things, it was kind of accidental really. At school I was clearly no good at writing because I got lousy marks for anything to do with writing.
Really?
Yeah. Oh, absolutely. But I was quite good at mathematics and that kind of thing, and physics. So, I kind of leaned towards engineering stuff and I was interested in electronics and things, cuz the other thing is I'm hopeless with my hands. I can't do anything that requires strength or physical coordination. So, all sorts of areas of engineering and building things, you know, I've tried looking after my car and, you know, I couldn't get the rusted nuts off or anything. You know, it was hopeless.
So, but electronics is okay because that's all very, you know, it's more in the brain than, you know, you need to be able to handle a soldering iron, but that was about as much as I needed to do. And then computers, and it's dead easy, I don't even need a soldering iron. So, I kind of drifted into computers in that kind of way. And that was my route into software development.
Before I went to university, I had a year working with the UK Atomic Energy Authority, or ukulele as we call it. And I did some programming in Fortran IV and it seemed like a good thing to be able to do.
And then when I finished my degree, which was a mix of electronic engineering and computer science, I looked around and I thought, well, I could go into traditional engineering jobs, which weren't terribly well paid and weren't terribly high status, or I could go into computing where it looked like there was a lot more opportunity. And so I just drifted into computing. And this was before the internet took off. This was…
What kind of jobs were there back then that you could get into? And what was your first job?
Well, my first job was with a consulting company, Coopers and Lybrand, or as I refer to them, Cheetum and Lightum. And we were doing advice on information strategy in the particular group I was with, although that wasn't my job. My job was, I was one of the few people who knew Unix because I'd done Unix at college, and so I looked after a bunch of workstations that they needed to run this weird software that they were running to help them do their strategy work. And then I got interested in what they were doing with their strategy work and kind of drifted into that. I look at it back now and think, god, there was a lot of snake oil involved. But hey, it was my route into the industry and it got me early into the world of object-oriented thinking, and that was extremely useful, to get into objects in the mid-80s.
And how did you get into object-oriented? Back then, we're talking probably the mid-80s, that was a very kind of radical thing. And you said you were working at a consulting company, which didn't seem like the most cutting edge. So how does two plus two get together? How did you get to do cutting-edge stuff?
Because this little group was into cutting-edge stuff and they had run into this guy who had some interesting ideas, some very good ideas as well as some slightly crazy ideas. And he packaged it up with the term object orientation, which wasn't really the case, but it was, it kind of, you know, it's part of the snake oil as it were. I mean, that's a little bit cruel to call it snake oil because he had some very good ideas as well. But that kind of led me into that direction, and of course in time I found out more about what object orientation was really about, and those events led to my whole career.
In the next 10 or 15 years, how did you make your way and eventually end up at Thoughtworks? And also you started to write some books, you started to publish on the side. How did you go from someone who was brand new to the industry and kind of wide-eyed and just taking it all in, learning things, to starting to slowly become someone who was teaching others?
Well, here again, bundles of accidents, right? So, while I was at that consulting company, I met another guy that they had brought in to help them work with this kind of area, an American guy, who became really the biggest mentor and influence upon my early career. His name is Jim Odell, and he had been an early adopter of information engineering and had worked in that area, and he saw the good parts of these ideas that these folks were doing, and he was an independent consultant and a teacher, and so he spent a lot of his time doing work along those lines.
I left Coopers and Lybrand after about a couple of years to actually join the crazy company, which is called PEK. And I was with them for a couple of years. It was a small company. There was a grand total of four of us in the UK office, and that was the largest office in the company. Kind of thing. And so, having seen a big company's craziness, I then saw a small company's craziness. Did that for a couple of years, and then I was in a position to go independent, and I did, helped greatly by Jim Odell, who fed me a lot of work basically, and also by some other work I got in the UK, and that was great. I remember leaving PEK and thinking, that's it, independent life for me. I'm never going to work for a company again.
Famous last words.
Exactly. And I carried on. I did well as an independent consultant throughout the '90s, and during that time I wrote my first books. I moved to the United States in '93, and I was doing very, very happily, and obviously got the rise of the internet, lots of stuff going on in the late 90s. It was a good time, and I ran into this company called Thoughtworks, and they were just a client. I would just go there and help them out.
Yeah. The story gets more. I had met Kent Beck and worked with Kent at Chrysler, the famous C3 project, which is kind of the birth project of extreme programming. So I'd worked on that, seen extreme programming, seen the agile thing. So I'd got the object orientation stuff, I got the agile stuff, and then I came to Thoughtworks, and they were tackling a big project, a big project for them at the time. Still sizable, about 100 people working on the project. So, it's a sizable piece of work, and it was clearly going to crash and burn. But I was able to help them both see what was going on and how to avoid crashing and burning, and they figured out how to sort of recover from the problem.
But then they invited me to join them, and I thought, hey, you know, join a company again, maybe for a couple of years. They're really nice people. They're my favorite client. You know, I always thought of it as, other clients would say, "These are really good ideas, but they're really hard to implement." While Thoughtworks would say, "These are really good ideas. They're really hard to implement, but we'll give it a try." And they usually pulled it off. And so I thought, "Hey, with a client like that, I might as well join them for a little while and see what we can do." That was 25 years ago.
Yeah. And then fast forward to today, your title has been, for I think over a decade, chief scientist.
Since I joined, that was my title at joining.
Since you joined. So I have to ask, what does a chief scientist at Thoughtworks do?
Well, it's important to remember I'm chief of nobody and I don't do any science. The title was given because that title was used a fair bit around that time for some kind of public-facing ideas kind of person. If I remember correctly, Grady Booch was chief scientist at Rational at the time.
Actually, true.
And there were other people who had that title. So it was a high-falutin, very pretentious title, but they felt it was necessary. It was weird because one of the things of Thoughtworks at that time was you could choose your own job title. Anybody could choose whatever job title they liked. But I didn't get to choose mine. I had to take the chief scientist one. They didn't like titles like flagpole or battering ram or loudmouth, which is the one I most prefer.
And one thing that Thoughtworks does every six months, and the latest one just came out, is the Thoughtworks Radar. And this latest radar, it just came out I think a few days ago. It's the…
Today it was launched, I think.
Actually it was today. So by the time this is in production it will have been a few weeks, but it's actually really, really fresh. So I just looked at it, and I'll just list a few things that I saw there. In adopt, which is the ones that they recommend: using pre-commit hooks, ClickHouse for database analytics, vLLM, this is for running LLMs on cloud or on-prem in a really efficient way. For trialing: Claude Code, FastMCP, which is an MCP framework for MCP servers. And they're also recommending a lot of different things related, for example, to AI and LLMs to assess. Can you share a little bit of how Thoughtworks comes up with this technology radar? What's the process? It feels very, very kind of on the pulse every time, like it feels close to the pulse of the industry, and again, I talk with a lot of other people. How do people at Thoughtworks stay this close to what is happening in the industry?
Okay. Yeah. Well, this will be a bit of a story. Okay. So, it started just over 10 years or so ago. Its origin was, one of the things that we've really pushed at Thoughtworks is to have technical people, practitioners, really involved at various levels of running the business, and one of the leaders of that was our former CTO, Rebecca Parsons. So Rebecca became CTO and she said, I want an advisory board who will keep me connected with what's going on in projects. So she created this technology advisory board, and it had a bunch of people whose job was to brief her as to what was going on. We'd meet, you know, two or three times a year. She had me on the advisory board not so much for that reason but because I was very much sort of a public face of the company. She wanted me present and involved in that. And originally that was just our brief. We would just get together and we'd talk through this stuff.
And then at one of these meetings, Daryl Smith, who was actually her TA at the time, technical assistant, said, we've got all these projects going on, it would be good to get some picture of what kinds of technologies we're using and how useful they are, so as to better exchange ideas, because like so many companies, we struggle to percolate good ideas around enough. I mean, even then, when we were only just a few thousand, it struggled, and we're 10,000 now. So we thought, okay, this is a nice idea, and he came up with this idea of the radar metaphor and the rings of the radar that we see today, and we had a little meeting and we created the radar. And it's a habit, if we do something for internal purposes, we try and just make it public, and that's always been a strong part of the Thoughtworks ethos. It's part of why I'm there, of course, is, you know, we talk about everything that we do and we share everything, we give away our secret sauce all the time. So we did that and people were very interested, and so we continued doing it.
Now, the process has changed a bit over time. At that original meeting, many of the people that were in the room were actually hands-on on projects, advising clients all the time. Now, as we've grown an order of magnitude, it's much harder to do that. And we've also created more of a process where people can submit blips, nominate them. A blip being a point on the radar, an entry. And they will go to somebody that's either connected geographically or through the line of business or technology or whatever and say, "Hey, we think this technology is interesting." They'll brief us a little bit about it. And then they brief the members of what's now called the Doppler group, because we make a radar. Yeah, I mean, we can be a bit loose with our metaphors at times. And then at the meeting we'll decide which of these blips to put on the radar and not, and obviously you get some cross-pollination because somebody will say, oh yeah, I talked to somebody about this as well. And so it's very much this bottom-up exercise.
And that's how it's created now. So we will do blip-gathering sessions about a month or two before the radar meeting and gradually shake them up, and then in the meeting itself we go through them one by one. And for me it's a bit weird because I'm so detached from the day-to-day these days that it's just this lineup of technologies and things, I have no idea what most of them are, but interesting to hear about, and sometimes I latch on to certain themes or something like that. And that was an important part of microservices about 10 years ago, because that came up through that radar process, and we got together with James Lewis and we ended up writing a good bit further about that. But that's really what happens, is we go through this process of spotting this stuff.
Yeah. And the radar analogy, I know some companies also take the idea, which by the way Thoughtworks encourages, saying make your own radar, take it into your own company. I think they even have tools around it. I really like how Thoughtworks never said this is the thing for the industry. They said this is the thing for us. This is what we see. This is what we recommend our team members or maybe our clients to consider. And I also like that there's a hold: maybe just beware, we're not seeing great results with this, and here are the reasons for it. And yeah, I guess the reason it feels fresh is probably a lot of work that Thoughtworks does, it feels cutting edge because it's all
It's all about, half of it or a third of it feels that it is around the hottest topic right now: AI, LLMs, and all the techniques that people are trying to see if they work, or are the things that we are seeing that actually start to work.
Yeah, I mean Thoughtworks has basically got several thousand technologists all over the world doing projects of various kinds for all sorts of different organizations, and the radar is a mechanism that we've discovered is a way of getting some of that information out of their heads and spreading it around, both internally and to the industry as a whole. And you're right, it is a recommended thing for clients to do, to try and do their own radars. It's slightly different when it's a client radar thing, because sometimes there it can be more of a "this is what we think you should be doing" with a bit more of a forcefulness to it than we would give. And also they can be a bit more choosy, in the sense that they can say, yeah, we're just not interested in doing certain technologies, while for us it's a case of, if our clients are doing it, then we're going to find out about it, right? We have to use it.
Of course the radar is full with a lot of AI and LLM related things, because this is a huge change. In my professional career, it feels by far the biggest technology innovation change coming in. Looking back on your career, what similar changes have you seen that could compare to some extent to AI in the technology field?
It's the biggest, I think, for my career. I think if we looked back at the history of software development as a whole, the comparable thing would be the shift from assembly language to the very first high-level languages, which is before my time, right, when we first started coming up with COBOL and Fortran and the like. I would imagine that would be a similar level of shift.
So you started to work with Fortran, and you probably knew people who were still doing assembly, or at least knew some of the people from that generation.
There was a bit of assembly around when I was working still.
From what you picked up around that time, what was that shift like in terms of mindset? Because it was a big change, right? You really needed to know the internals of the hardware and the instructions and the different...
I did very little assembly at university, but it's been very useful because I never want to do it again. [laughter]
Very wise. But what did you pick up in terms of what needed to change and how it changed the industry, just moving from mostly assembly to mostly higher-level languages?
Well, I mean, for a start, as you said, things were very specific to individual chips. The instructions were different on every chip, as well as things like registers, where you access memory. You had these very convoluted ways of doing even the simplest thing, because your only instruction was for something like: move this value from a memory location to this register. And so you've always got to be thinking in these very, very low-level forms. And even with a relatively poor high-level language like Fortran, at least I can write things like conditional statements and loops. There's no else in my conditional statements in Fortran IV, but I can at least go "if" and I can get one statement. I can't do a block of statements, I have to use go-tos, but it's better than what you can do in assembly, right? And so there's a definite shift of moving away from the hardware to thinking in terms of something a bit more abstract, and I think that is a very, very big shift.
And then of course, once I'm using Fortran, I can be insulated to some degree away from the hardware I'm running on. Am I running this on a mainframe? Am I running this on a minicomputer? I mean, there's issues, because the language always varied a little bit from place to place, but you've got a degree of decoupling there. That was really quite significant, I think. I mean, I only did it on small microprocessor-like units, because again it was the electronic engineering part, right, so we were fairly close to the metal anyway for some of that.
But you definitely had that mind shift, and I think with LLMs it's a similar degree of mind shift. Although, as I've written about it, the interesting thing is the shift is not so much an increase of a level of abstraction, although there is a bit of that. The biggest part of it is the shift from determinism to non-determinism, and suddenly you're working with an environment that's non-deterministic, which completely changes how you have to think about it.
Martin just talked about how AI is the most disruptive change since the move from assembly to high-level languages. That transition wasn't just about changing the language we use; it required entirely new toolchains. Similarly, AI-accelerated development isn't just about shipping faster, it's about measuring whether what you ship actually delivers value. That's where modern experimentation infrastructure comes in, and where our presenting sponsor Statsig can help.
With Statsig, instead of stitching together point solutions, you get feature flags, analytics, and session replay, all using the same user assignments and event tracking. For example, you ship a feature to 10% of users. As you do, the other 90% automatically become your control group with the same event taxonomy. You can immediately see conversion rate differences between groups, drill down to see where treatment users drop off in your funnel, then watch session recordings of specific users who didn't convert to understand what went wrong. The alternative is running jobs between different services to sync user segments between your feature flag service and your analytics warehouse, and then manually linking up data that might have different user identification logic. It's a lot of work and it can also go wrong. Statsig has a generous free tier to get started, and pro pricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statsig.com/pragmatic.
And now, let's get back to the shift in abstraction with LLMs.
Can we talk about that shift in abstraction? Because one very naive way of looking at it is saying, well, we've had the three levels, right? We have assembly, where you have commands for the hardware. You need to be intimately aware of the hardware. We have high-level programming languages, starting with C, later Java, later JavaScript, where you don't need to be aware of the hardware, you're aware of the logic. And what you might say as well is we have a new abstraction: you have the English language, which will generate this code. You're saying you don't think it's an abstraction jump. Why do you think this is?
I think there's a bit of an abstraction jump. I think the abstraction jump difference is smaller than the determinism to non-determinism jump. And it's worth remembering one of the key things about high-level languages, which I didn't mention as I was talking earlier on, is the ability to create your own abstractions in that language. That is particularly important as you get to things like object orientation, towards more expressive functional languages like Lisp. Fortran and COBOL didn't really have so much of that; you could do that to some extent, because at least with Fortran you can create subroutines and build abstractions out of that. But you've got so many more tools for building abstractions when you've got the abilities of more modern languages, and that ability to build abstractions is crucial.
So you can build a building block inside of the language that sets you... and of course here we have domain-driven development later that enables these things and so on.
Exactly. I mean, an old Lisp adage is that really what you want to do is to create your own language in Lisp and then solve your problem using the language that you've created. And I think that way of thinking is a good way of thinking in any programming language. You're both solving the problem and creating a language to describe the kinds of problems you're trying to solve. And if you can balance those two nicely, that is what leads to very maintainable and flexible code. So the building of abstractions, that's, to me, a key element of high-level languages, and AI helps us a little bit in that, because we can build abstractions a bit more easily, a bit more fluidly. But we have this problem that now we're talking about non-deterministic implementations of those abstractions, which is an issue, and we've got to learn a whole new set of balancing tricks to get around that.
My colleague Unmesh Joshi has written a couple of things that I've really been enjoying about his thinking, because he's really pushing this: using the LLM to co-build an abstraction and then using the abstraction to talk more effectively to the LLM. And I'm finding that a really, really interesting way of thinking about how he's working with that, because he's really pushing that direction.
There's a thing I read, and I can't remember the book off the top of my head, we'll have to dig it out later, that talked about how apparently if you describe to an LLM a whole load of chess matches, and describe them just in plain English, when you do that the LLM can't really understand how to play chess. But if you take those same chess matches and describe those chess matches to the LLM in chess notation, then it can. And I thought that was really interesting, that obviously you're shrinking down the token size, but you're also using a much more rigorous notation to describe the problem. So maybe that's an angle of how we use LLMs: what we have to come up with is a rigorous way of speaking, and we can get more traction that way. And of course that has great parallels with the ideas of domain-driven design and ubiquitous languages, and also some of the stuff that I was working on a decade or so ago around domain-specific languages and language workbenches. So there's some fascinating stuff around there; it'll be interesting to see how that plays out.
Yeah. And I guess, is this the first time we're seeing a tool that is so wide in software engineering that is non-deterministic? Because we did have neural nets, for example, in the past, but I feel the application of those was a lot more niche and not everywhere. Now every single developer, I mean, if you're using code generation, you are using non-deterministic things. Of course we're integrating them left and right, trying out where it works. Is it fair to say that this is probably the first time we're facing this challenge? Deterministic computers we know very well. We know their limits and all those things, and of course there's some race conditions and some exotic things, but now we have...
Exactly.
...a problem to solve for.
It's a whole new way of thinking. It's got some interesting parallels to other forms of engineering. In other forms of engineering, you think in terms of tolerances. My wife's a structural engineer, right? She always thinks in terms of: what are the tolerances? How much extra stuff do I have to do beyond what the math tells me, because I need it for tolerances? Because yeah, I mostly know what the properties of wood or concrete or steel are, but I've got to go for the worst case. We probably need some of that kind of thinking ourselves. What are the tolerances of the non-determinism that we have to deal with, and realizing that we can't skate too close to the edge, because otherwise we're going to have some bridges collapsing. I suspect we're going to do that, particularly on the security side. We're going to have some noticeable crashes, I fear, because people have skated way too close to the edge in terms of the non-determinism of the tools they're using.
Oh, for sure. But before we go into where we could crash, what are some either new workflows or new software engineering approaches that you've observed or are aware of that sound exciting, that we can now do with LLMs, or at least we can try to give a go, that would have been impossible with our old deterministic toolkit?
Right. One area, one that has got lots of attention already, is being able to knock up a prototype in a matter of days. That's just way more than you could have done previously. So this is the vibe coding thing. But it's more than just that, because it's also an ability to try explorations. People can go, hey, I'm not really quite sure what to do with this, but I can spend a couple of days exploring the idea much, much more rapidly than I could have before. And so for throwaway explorations, for disposable little tools and things of that kind, including stuff by people who don't think of themselves as software developers, I think there's a whole area. And we can, with good reason, be very suspicious of taking that too far, because there's a danger there. But we also realize that as long as you treat that within its right bounds, that's a very valuable area, and I think that's really good.
On a completely opposite end of the scale, one area that's really interesting is helping to understand existing legacy systems. My colleagues have put a good bit of work into this a year or two ago. And basically the idea is you take the code itself, do essentially the semantic analysis on it, populate a graph database essentially with that kind of information, and then use that graph database in a RAG-like style, and you can begin to interrogate it and say, well, what happens to this piece of data? Which bits of code touch this data as it flows through the program? Incredibly effective. And in fact, if I remember correctly, we put understanding of legacy systems into the Adopt ring, because we said, yeah, if you're doing any work with legacy systems, you should be using LLMs in some way to help you understand.
So in this ring in the Thoughtworks Radar, the fewest things are in Adopt. Adopt says we strongly suggest that you look at this, at least Thoughtworks themselves look at it. There's only four items, and one of them is, yes, to use GenAI to understand legacy code, which to me tells that you have seen great success. Which is refreshing to hear, by the way; I did not hear this as much. And I guess it helps at Thoughtworks, I'm sure you have to work with a lot of...
Well, I mean, it came from the fact that some of the folks who had done some really interesting work on legacy code stuff happened to bump into this and look at it and say, "Hey, let's try this out." And they found it to be very effective. And it also has been an ongoing interest for many of us at Thoughtworks, because we have to do it all the time. How do you effectively work with the modernization of legacy systems? Because every big company that is older than a few years has got this problem, and they have it in spades.
And then especially just simple things: people leave, right? As simple as that. And having GenAI that can help you make some progress is already better than making no progress.
Exactly. So those are two areas where, right away, I would say there's great success for using LLMs. And then there's the areas that we're still figuring out. I'm certainly seeing more and more interesting stuff as people try to figure out how to work with an LLM on a one-to-one basis to build decent quality software. We're seeing some definite signs of how you've got to work with very thin, rapid slices, small slices. You've got to treat every slice as a PR from a rather dodgy collaborator who's very productive in the lines-of-code sense of productivity, but you can't trust a thing that they're doing. So you've got to review everything very carefully when you play with the genie like that. The genie is Kent Beck's term for it. Or Dusty, the sort of anthropomorphic donkey, which is how Bita...
I love her take.
Yeah. But using it well, you can actually definitely get some speed up in your process. It's not the kind of speed up that the advocates are talking about, but it is non-trivial. It's certainly worth learning how to make some use of this, and it's folks like Birgitta or Kent or Steve Yegge, those are the folks I think who are pushing this. We're still, I think, learning how to do this.
Everyone is learning it. Absolutely.
And it's still the question, and most of the experience we're gaining is building in a greenfield environment. So that leaves big questions in terms of the brownfield environment. Well, we know that LLMs can help us understand legacy code. Can they help us modify legacy code in a safe way?
It's still a question. I mean, I was just chatting with James Lewis, because he's in town as well, this morning, and he was commenting that he was playing with Cursor and he was just building something like this, and he said, "Oh, I wanted to change the name of a class in a not too big program," and he sets it off to do that, and comes back an hour and a half later and has used, you know, 10% of his monthly allocation of tokens, and all he's doing is changing the name of a class.
And we actually, in IDEs we actually have functionality which I still remember when it was cutting edge. This was probably 20 years ago when Visual Studio, it wasn't even Visual Studio, it was JetBrains who came out with an extension called ReSharper which helped refactor code, and people paid serious money, this was like $200 per year or something, to get this plugin, and now you could right click and say rename class and it went and it built the graph behind the scenes somehow, it went and changed. You could rename variables, and again this was a huge deal. In fact, in Xcode, Apple's developer IDE, for a while when Swift came out you couldn't do these refactors, and it was, you know, people were like... So it's interesting how some things are easy, we've solved it, and LLMs are not very efficient at, not very good at it.
Yeah.
Yes, and then I mean he did that just to see what it was going to be like, right, cuz he knows you can just, I mean, we've had this technology for a long time, so it's kind of amusing. I mean, but it's also to the point that when working with an existing system and modifying an existing system, that's still really up in the air. And then another area that's really up in the air, both greenfield and brownfield, is what happens when you've got a team of people, because most software has been built by teams and will continue to be built with teams, because even if, and I don't think it will, AI makes us an order of magnitude more productive, we still need a team of 10 people to build what a team of 100 people needed to build, and we will always want this stuff. There's no sign of demand dropping for software. So we will always want teams, and then the question is of course how do we best operate with AI in the team environment, and we're still trying to figure that one out as well. So there's lots of questions, we got some answers, some beginnings of answers, and it's just a fascinating time to watch it all.
You mentioned vibe coding. What is your understanding and take on vibe coding?
Well, when I use the term vibe coding, I try to go back to the original term, which is basically you don't look at the output code at all. Maybe, you know, take a glance at it out of curiosity, but you really don't care, and maybe you don't know what you're doing because you've got no knowledge of programming. It's just spitting out stuff for you. So that's how I define vibe coding. And my take on it is kind of as I've indicated, I think it's good for explorations. It's good for throwaways, disposable stuff. But you don't want to be using it for anything that's going to have any long-term capability.
Because it's, I mean, again, just this is a silly anecdote, but I was working, my colleague Unmesh, he just wrote something that we published yesterday. And as part of doing this, we create this little pseudo graph of capability over time kind of thing, which is, you know, one of those silly little pseudo graphs that helps illustrate a point. And he asked the LLM to create this. He described the curves he wanted and it came up with it and put it up there. And he committed it to our repo. And I was looking at it and thinking, yeah, that's a good enough graph. I want to tweak it a little bit. I want to, you know, the labels are a bit far away from the lines they're labeling, so I'd like to bring them closer. So I open up the SVG of what the LLM has produced and, oh, I mean, it was astonishing how complicated and convoluted it was for something that I had written the previous one myself, and I knew it was, you know, a dozen lines of SVG, and SVG is not exactly a compact language, right, because it's XML. But this thing was gobsmackingly weird. And I mean, that's the thing: when you vibe code stuff, it's going to produce God knows what, and often it really is, and you cannot then tweak it a little bit.
You have to basically throw it away and hope that you can generate whatever it is you're trying to tweak. And the other thing, of course, that's the difference, and this is the heart of the article that Unmesh wrote that we published yesterday, is when you're using vibe coding in this kind of way, you're actually removing a very important part of something, which is the learning loop. If you're not looking at the output, you're not learning. And the thing is that so much of what we do is we come up with ideas, we try them out on the computer, with this constant back and forth between what the computer does and what we're thinking. We're constantly going through that learning loop program approach, and Unmesh's point, which I think is absolutely true, is you cannot shortcut that process. And what LLMs do, they just kind of skim over all of that and you're not learning. And when you're not learning, that means that when you produce something, you don't know how to tweak it and modify it and evolve it and grow it. All you can do is nuke it from orbit and start again. The other thing I've done occasionally with vibe coding is... oh, vibe coding as a consulting company, so many problems to fix.
For sure. But you are right on the learning side, both on vibe coding and AI. One thing that I'm noticing on myself is it is so easy to, you know, give a prompt, you get a bunch of output, and, you know, you should be reviewing a lot of this code, either yourself or in a code review, but what I'm seeing on myself is at some point I start to get a bit tired and I just let it go. And this is also what I'm hearing when talking with software engineers: the ones who are working at companies which are adopting these tools, which is pretty much every company, there's a lot more code going out there, a lot more code to review, and they're asking, "How can I be rigorous at code reviews when there's just more and more of them than before?" Have you seen approaches that help people, both less experienced people and also more experienced engineers, keep learning with these tools? Just approaches that seem promising.
Not a huge amount. I am very much paying attention to what Unmesh is doing with this, because his approach very much is that notion of let's try and build a language to talk to the LLM, work with the LLM to produce a language to communicate to the LLM more precisely and carefully what it is that we're looking for. And I do feel that is a promising and very much a more promising line of attack. Make sure, do we create our own specialized language for working with whatever problem that we're working on. And I think that actually brings another... we're talking about things we know LLMs are useful for, another thing, and this is again something Unmesh has highlighted, is understanding an unfamiliar environment. Again, I was chatting with James, he's working on a Mac with C, which is not a language he's terribly familiar with, using this game engine called Godot.
Godot. Yeah.
Yeah, Godot. And he doesn't know anything about this, right? But with the LLM, he can learn a bit about it because he can try things out. And if you take it with that exploring sense... and I mean, I can't remember, I've certainly got to the point where I'm typing in to the LLM, "Oh, well, how do I do so and so in R," that I've done 20 times, but I still can't remember how to do it. And exploring, and Unmesh makes a point again, setting up initial environments. You know, give me a starting project, a sample starting skeleton project so I can just get moving. And so that kind of exploratory stuff and helping in an unfamiliar environment and just learning your way around an unfamiliar set of APIs and coding ideas and the like, it can be quite handy for.
I wonder if this is not all that new, in the sense that I remember, you know, one of the last kind of big productivity boosts in the industry, about 10 or 15 years ago, was Stack Overflow appearing. So before Stack Overflow, when you Googled for questions, you bumped into this site called Experts Exchange, and there was the question and you had to pay money to see the answer, or you had to pay money to get an expert to answer, but usually there was nothing behind it even if you paid, and most of us, I was a college student, I just didn't pay, right? So you just couldn't find the answer and you were all frustrated. But then Stack Overflow came along and suddenly you had code snippets that you could copy, and of course what a lot of young people or less experienced developers, even like myself, did is you just take the code, put it in there and see if it works. As you got to more experienced engineers or developers, you started to tell the junior engineers, like, you need to understand that first, or even if it works, you need to understand why it works. You should read the code. And I feel there was a few years where we were going back and forth of people mindlessly copy-pasting snippets. There were problems with, I think there was a question about email validation, and a top voted answer was not entirely correct. And it turns out that a good part of software and developers just used that one. I feel we've kind of been around this already.
Yeah, it's a similar kind of thing, but
maybe at a smaller scale.
Yeah. But even more boosted and on steroids, and with the question of, you know, how are things going to populate in the future, because who's going to be writing Stack Overflow answers anymore?
Yeah. So I wonder if what we're getting to is like you need to care about the craft. You need to understand what the LLM's output is, and it's there to help you, and if you're not doing it, I mean, like, you should, but if you're not, you'll eventually be no better than someone just prompting it mindlessly.
Exactly. Yeah. I mean, I have no problem with taking something from the LLM and putting it in to see if it works, but then once you've done that, understand why it works, as you say, and also look at it and say, is this really structured the way I'd like it to be? Don't be afraid to refactor it. Don't be afraid to put it in. And then of course the testing combo: anything you put in that works, you need to have a test for, and if you constantly are doing that back and forth with the testing process.
Martin Fowler was just talking about the importance of testing when working with LLMs and in general when building quality software. Speaking of quality software, I need to mention our season sponsor, Linear. I recently sat in on one of Linear's internal weekly meetings called Quality Wednesdays, and I was completely blown away. This was a 30-minute meeting that happens weekly. In this session, the team went through 17 different quality improvements in half an hour. 17. It's a fast and super efficient meeting. Boom, boom, boom. Every developer shows a quality improvement or performance fix that they made that week. And it can be anything from massive backend performance wins that save thousands of dollars to the tiniest UI polish that most people wouldn't even notice. For example, one fix was fixing the height of the composer window very slightly changing when you entered a new line. Another one was fixing this one pixel misalignment. Can you imagine caring that much about the details? After doing this every single week for years, their entire engineering team has developed this incredible eye for quality. They catch these issues before they even ship. Now, one of their engineers told me that since they trained this muscle over time, they start noticing patterns while building stuff. So fewer of these paper cuts ship in the first place. This is why Linear feels so different from other issue tracking and project management tools. Thousands of tiny improvements do add up and you feel the difference. When you use Linear, you're experiencing the results of literally hundreds of these Quality Wednesday sessions. Thomas, their CTO, recently wrote a piece about this weekly ritual, and I'll link it in the show notes below. If your team cares about craftsmanship and building products that people actually love using, check out Linear at linear.app/pragmatic. Because honestly, after seeing how they work up close, I understand why so many of the best engineering teams are switching. And now, let's get back to the importance of testing when working with LLMs.
I mean, one of the people I particularly focus on in this space is Simon Willison, and something he stresses constantly is the importance of tests. Testing is a huge deal to him and being able to make these things work. And of course, you know, Birgitta is from Thoughtworks. We're very much an extreme programming company. So she's steeped in testing as well. So she will say the same thing. You've got to really focus a lot on making sure that the tests work together. And of course, this is where the LLMs struggle, because you tell them to do the tests and
I'm only hearing problems, or experiencing them myself, like when the LLM tells me, "Oh, and I ran all the tests. Everything's fine." You run npm test: five failures. Yeah, I see some improvements there, by the way, with Claude Code, also other agents. But yes, it's the nondeterministic angle. Sometimes they can lie to you, which is weird, right? I'm still not
They do lie to you all the time. In fact, if they were truly a junior developer, which is how sometimes people like to say they should be characterized, I would be having some words with HR.
Yeah. Like the other day I just had this really weird experience, which is the simplest thing. I have a configuration file where I add just new items, a new JSON, you know, blob, and I put the date of when I added it just in the comments, saying added on, you know, October 2nd, added on November 1st. It's always the current date. And I told the LLM, can you please add this configuration thing and add the current date? And it added it, and it just copied the last date. And I said, that is not today's date. It said, oh, I'm so sorry, you know, let me correct that for you. And it put yesterday's date. And I feel you need to get this experience to see that it can gaslight you for a simple thing like today's date, which, you know, you could call a function, whatnot, but it's down to who knows which model I was using, how that model works, whether the company creating it is optimizing for token usage or not, etc., etc., etc. So in the end, even for the simplest things, when you're a professional working on important stuff, you should not trust.
Yeah, absolutely. Never. Yeah, you've got to, don't trust, but do verify.
Verify. Yes. Speaking with developers at Thoughtworks and the people you're chatting with, what areas are they successfully using LLMs day-to-day, though? Like, we did mention just right now testing. We also mentioned things like prototyping,
But do you see some other things where it's starting to become a bit of a routine? Like if I'm doing this thing, let me reach for an LLM, it can probably help me.
Yeah, I mean, I've mentioned many of that, right? The prototyping, the legacy code understanding, oh yes, the fact that you can use it to explore new technology areas, potentially even new domains, as long as you trust it significantly less than you would trust Wikipedia 10 years ago. Those are the things that I'm hearing so far.
Yeah. One interesting area that Birgitta is exploring is spec-driven development. There's this idea of, well, you know, LLMs have their own limitations, but what if we define pretty well what we want it to do and give it this really good specification, and it can run with it, it can run long, it has iterations and so on. What is your take on this, and do you have a bit of a déjà vu? Because we've heard this once, right? Your career started around this thing called waterfall development. So how are you seeing it similar but also different this time?
Well, the similar to waterfall is where people try and say let's create a large amount of spec and not pay much attention to the code. And here I mean, whether you talk, again, this is what you mean by spec-driven development, is it so much focusing on that or is it doing small bits of spec, do the tight loop? I mean, to me the key thing is you want to avoid the waterfall problem of trying to build the whole spec first. It's got to be do the smallest amount of spec you can possibly get to make some forward progress. Cycle with that, build it, get it tested, get it in production if possible, and then cycle with these thin slices. What role a spec may play to drive, in either case, could be argued to be a form of spec-driven development. But to me, what matters is the tight loops, the thin slices, that kind of thing.
And I know Birgitta definitely agrees on that point, coming because she and you have to be the human in the loop verifying every time. That's clearly crucial.
Where the spec-driven development then ties in interesting, again, it comes back to this thinking of building domain languages and domain-specific languages and things of that kind. Can we craft some kind of more rigorous spec to talk about? And that's, you know, I mentioned what Unmesh was doing there, using it to build an abstraction, because essentially what we're saying is that it gives us the ability to build and express abstractions in a slightly more fluid form than we would be able to do if we were building them purely within the codebase itself. But we still don't want them to deviate too much from the codebase, right? We still want the ubiquitous language notion that it's the same language in our head as is in the code, and we're seeing the same names and they're doing the same kinds of things. The structure is clearly parallel, but obviously the way we think is a bit more flexible than the way the code can be. And then, can we blur that boundary a bit by using the LLM as a tool in that area? So that's the area that I think is interesting in that direction.
It's interesting and new, because I feel we've never been able to use language as close to representing code ever, or business logic, and this is very new.
Yeah. Although again, there are plenty of people who take that kind of DSL-like thinking into their programming, and I know people who would say, yeah, I would get to the point where I could write certain parts of the business logic in a programming language like, say, Ruby, and show it to a domain expert and they could understand it. They wouldn't feel the ability to be able to write it themselves, but they could understand it enough to point out what was wrong or what was right in there. And this is just programming code, but that requires a certain degree of the way you go about projecting the language in order to be able to get that kind of fluidity. And so that kind of thinking, like trying to make an internal DSL of a programming language, or maybe building your own external DSL.
DSL meaning domain-specific language, like if you're working with accountants, you're going to have the terms that they use, the way they use it and so on.
Yeah. And what you're trying to do, of course, is create that communication route where a non-programmer can at least read what's going on and understand it enough to be able to find what's wrong about it, and to suggest changes which may not be syntactically correct, but you can easily fix them because you as a programmer can see how to do that. And that's the kind of goal, and some people have reached that goal in some places. So the interesting thing is whether LLMs will enable us to make more progress in that direction and see that happening more widely.
And I guess this must be, I'm just assuming, correct me if I'm wrong, this must be especially important in enterprises, these very large companies where software developers are not the majority of people. Let's say they're 10 or 20% of staff, and there's going to be accounting, marketing, special business divisions who all want software written for them, and they know what they want, and historically there's been layers of people translating this, may that be the project manager, the technical pro, etc. So you're saying that there could be a pretty interesting opportunity, or just an experiment, with LLMs that maybe we can make this a bit easier for both sides.
That is the world I'm most familiar with, right, is that world. I mean, my sense is you're very familiar with the big tech company and the startup worlds, but this corporate enterprise world, of course, is a whole different kettle of fish, because exactly the reason that you said, suddenly the software developers are a small part of the picture and there's very complex business things going on that we've got to somehow interface in. And of course also there's usually a much worse legacy system problem as well.
And there's going to be regulation, there's going to be a history, there's going to be exceptions because of all the knowledge. I think we can all just think of banks of all the things, because there's a perfect storm, right? They have regulation that changes all the time. They have incidents that they want to avoid going forward. They'll have special VIP, I don't know, accounts or whatever that they'll want to do. And of course, they have all these business units that all know their own rules and frameworks. And they've been around since before technology. Some of the banks have been around for, you know, 100 plus years.
Yeah. And remember, the banks tend to be more technologically advanced than most other corporations in software.
That's a good one.
You're looking at the good bit when you're talking about banks.
You have worked with some of the less advanced folks as well.
I mean, yeah, retailers, airlines, government agencies, things of that kind. I mean, it was interesting. I was chatting with some folks working in the Federal Reserve in Boston, and they have to be extremely cautious. They are not allowed to touch LLMs at the moment because the consequences of error when you're dealing with a major government banking organization are pretty damn serious. So you've got to be really, really careful about that kind of stuff. And yeah, their constraints are very different.
And it brought to mind there's an adage that says that to understand how the software development organization works, you have to look at the core business of the organization and see what they do. I was at this agile conference for the Federal Reserve in Boston and they took me on a tour of the Federal Reserve, where they handle the money. And so I saw the places where they bring in the notes that have been brought in from the banks, and they clean them and count them and all the rest of it, and send out the stuff again. And you look at the degree of care and control that they go through, as you could imagine. I mean, when you're bringing in huge wedges of cash and it has to be sorted and counted and all the rest of it, the controls have to be really, really strenuous. And you look at that, and you look at the care with which they do all of this, and you say, "Yep, I can see why in the software development side that mindset percolates, because they are used to the fact that they really have to be careful about every little thing here." A lot of corporations of course have that similar notion. You're involved in an airline, you are really concerned about safety. You're really concerned about getting people to their death. That affects your whole way of thinking, or ought to, and it does.
And I guess this is a reason we always see a divide in technology usage, because you have the startups, which is a group of people, they just raised some funding or they have no funding. They have nothing to lose. They have zero customers. They have everything to gain. They need to jump on the latest bandwagon. They want to try out the latest technologies, oftentimes build on top of them or sell tools to use the latest technology, and they're here to break the rules. And midway, when you start to have a few customers in a business, you're starting to be a bit more careful. And of course, 50 or 70 years down the road, when the founders have gone and now it's a large enterprise, you will just have different risk tolerance, right?
Exactly, yeah.
But what I find fascinating talking about this is that I'm unsure if there has been any new technology that has been so rapidly adopted everywhere. You mentioned that, let's say, the Federal Reserve or some other government organizations might say let's not touch this yet, but they are also evaluating it, it sounds like. So if they're one of the most, I guess, behind in the technology curve, for very good reason, and they're already aware of it or using it, which probably means that it's everywhere now.
Oh, it is. I mean, we see it all over the place, but again, with more caution in the enterprise world, where they're saying, "Yeah, we also see the dangers here."
And then you're seeing more nimble companies that you work with and the more enterprise-focused. What would you say is the biggest difference between their relationship with AI, their approach? Is it this caution, or are there other characteristics that the big, more traditional, more risk-averse companies approach it differently?
The important thing to remember with any of these big enterprises is they are not monolithic. So small portions of these companies can be very adventurous and other portions can be extremely not so. And so what you'll see is, I mean, like when I started at Cheetah Lightwe, right, and I was in this little bit that was very, very aggressively doing really wacky things, right? I mean, you'll find that in any big organization, you'll find some small bits doing some stuff. And so it's really the variation within an enterprise often is bigger than the variation between enterprises.
Good to keep that in mind. So speaking about refactoring, LLMs are very good at refactoring, and you've written the book back in 1999 called Refactoring. This is now the second edition, which 20 years later has been refreshed. And it's actually a really detailed book going through different code smells that could show where the code is, techniques of refactoring it. On the first page already, I really like this, it has a list of refactorings. I don't know how the publisher printed this because it's so unusual, but it's right here on the table of contents. Why did you decide to write this book back in 1999? Can you bring us back to what the environment was like, and what was the impact of the first edition of this book?
Okay. So, I first came across refactoring at Chrysler, when I was working with Kent Beck, right early on in the project. I remember in my hotel room, the Courtyard or whatever in Detroit, him showing me how he would refactor some Smalltalk code. And I mean, I was always someone who liked going back to something I'd already written and make it more understandable. I've always cared a lot about something being comprehensible. That's true in my prose writing and in my software writing. And so that I knew, but what he was doing was taking these tiny little steps, and I was just astonished at how small each step was, but because they were small, they didn't go wrong, and they would compose beautifully, and you could do a huge amount with this sequence of little steps. And that really blew my mind away. I thought, "Wow, this is a big, big deal."
But Kent at the time, his energy was to write the first Extreme Programming book, the white book. He didn't have the energy to write a refactoring book. So I thought, well, I'm going to do it then. And I started by, whenever I was refactoring something, I would write careful notes, partly because I needed it for myself. How do I extract a method so as I don't screw it up? And so I would write careful notes on each one. And then each of those turned into the mechanics in the refactoring book, that step. And then I'd make an example for each one. And that was the first edition of the book. And I did it in Java, not in Smalltalk, because Smalltalk was dying, sadly, and Java was the language of the future, the only programming language we'd ever need in the future, in the late 90s. And so that's what led to the first book.
And the impact, well, I mean, and also refactoring, I should also stress, it wasn't invented by Kent. I mean, it was very much developed by Ralph Johnson's crew at the University of Illinois Urbana-Champaign. They built the first Refactoring Browser in Smalltalk, which is the first tool that did the automatic refactoring that we talk about now. That was the original, the Refactoring Browser, built by, I'm blanking on, John Brant and Don Roberts, did that.
And then when the book came out, that got more interest. There was already some interest from the IBM VisualAge folks, because they came out of Smalltalk. The original versions of VisualAge were in fact built in Smalltalk. And so they were already aware of what was going on to some degree, but it was the JetBrains folks that really caught the imagination, because they put it into the early versions of IntelliJ IDEA and really ran with it. Then you ran into it with ReSharper, of course. And they really made the automated refactorings become something that people could rely on. But it's still good to know how to do them yourself, because often you're in a language where you haven't got those refactorings available to you. So it's nice to be able to pull out that stuff, and some of them aren't obviously in there.
And yeah, so the impact it's had is refactoring became a word, and of course, like all of these words, got horribly misused, and people use refactoring to mean any kind of change to a program, which of course it isn't, because refactoring is very strictly these very small semantics-preserving, behavior-preserving changes that you make, tiny, tiny steps. I always like to say each step is so small that it's not worth doing, but you string them together and you can really do amazing things.
I think we've all had that story. At least I had a story where one of my colleagues, or it could have been me, but oftentimes one of my colleagues would say at stand-up, like, "Oh, I'm just going to do a refactoring," and then next day, "Oh, I'm still doing the refactoring," next day, "Oh, I'm still doing the refactoring," and you know, that missed a part of the small changes for sure. What made
…you do a second edition for the book 20 years later in 2019, which was fairly recent? Well, it was a sense of wanting to refresh some of the things that were in it. There were some new things that I had. I was also concerned that, I mean, when you've got a book that's written in late 1990s Java, it shows its age a bit.
Yes.
And although the core ideas I felt were sound and people could still use it, I felt giving it a more, doing it in a more modern environment. And then the question was, you know, would I stay with Java or did I switch to another language, and in the end I decided to switch to JavaScript. I felt it would reach a broader audience that way and also allow a less object-oriented centered way of describing things. So instead of extract method it's extract function, because of course it's the same process for functions, and also some things that you wouldn't necessarily think of doing in an object-oriented language. But it was mainly just to get that refresh, to redo the examples, to really hopefully give it another 20 years of life, because it's got to keep me going until I croak, you know.
Yeah. So you published this book 25 years ago or 26 years ago in the industry, based on your interactions with developers. How has the perception of refactoring changed? Because in the book you specifically wrote that you see refactoring as a key element in the software development life cycle, and you've also talked about how when you refactor, the overall cost of changing code over time can be a lot cheaper. Was there a time where there was a lot more uptake on this, or is there still, or do you feel it's kind of like a little bit like maybe refactoring went a little bit out of style, as some of those really innovative tools at the time like JetBrains and others, they're maybe not as kind of referenced even though they're everywhere?
It's hard to say for me, because, I mean, again, most of the interaction I have is with folks at Thoughtworks. They tend to be more clued up with this kind of stuff than the average developer. Certainly, I read plenty of things on the internet that make me just shake my head at how even refactoring is being described, let alone the lack of doing it, and certainly in the kind of structured way, controlled way that I like to do it, because I like doing it quickly and effectively. And you know, it's one of those things where the disciplined approach actually is faster, even though it may seem strange to describe it that way. But I mean, it's at least been part of our language now. People talk about doing it. It's in these tools and they do it very effectively. The refactorings that they do, I mean, it's wonderful to work in an environment where you can actually automatically do so many of these things. And so I feel we've definitely made some progress. Maybe not as much as I'd have hoped for, but you know, that's often the way with these things.
Looking ahead with AI tools, they generate a lot more code a lot faster. So we're just going to have a lot more code. We already have a lot more code. How do you think the value of refactoring, thinking about your intended meaning of those small ongoing changes, is going to be important? And are you already seeing some of this being important?
I wouldn't say I'm already seeing it, but I can certainly expect it to be increasingly important, because again, if you're going to produce a lot of code of questionable quality, but it works, then refactoring is a way to get it into a better state while keeping it working. These tools at the moment definitely cannot refactor on their own, although we've combined them with other things. Adam Tornhill does some interesting stuff with combining LLMs with other tools to be able to get a much more effective route, and I think that kind of approach, combining, could be a good way to do it. But definitely the refactoring mindset, and thinking how do I make changes by basically boiling them down to really small steps that compose easily. That's really the trick of it. The smallness and the composability. Combine those two and you can make a lot of progress.
It's interesting because right now if you want to refactor you need to have your IDE open for sure. And I mean the fast way is just using the built-in tools or moving things around. What I found as well is describing it when I have a command line open with, like, Claude Code or something similar, it's tough, or I spend more time explaining it than me doing that small change. And I do wonder if we will see more integrations in this end as well, so that LLMs can actually do it, or some of them might do it automatically, because as you say, it doesn't work out of the box. But I think for any quality software, I mean, we all learn the hard way that if you just kind of leave it there and don't go back and don't change it up when your functions get, just the simple things, right, when your function gets too long, when your class gets too long, you break it up, otherwise you're not going to understand it later.
Yeah, it'll be interesting as well to see if it provides a way for us to control the tool. I mean, one of the things that interests me is where people are using LLMs to describe queries against relational databases that turn into SQL. You don't know how to get the SQL right, but if you type the thing at the LLM, it will give you back the SQL, and you can then look at it and say, "Oh, this is right or not right," and tweak it, and it gets you started, right?
And so similarly with refactoring, it may allow you to get started and say, "Oh, these are the kinds of changes I'm looking at," and be able to make some progress in that. I mean, particularly where you're talking about these automated changes across large code bases. There was an example of this, was it a year ago or so, when one of these big companies talked about this massive change they made to change APIs and clean up the code, and they mentioned it as an LLM thing, but it wasn't an LLM. It was a different tool, and I'm completely blanking on what the names of all of these things were. Oh, I have a 60-year-old brain and I can't remember anything anymore. It'll come to me at some point. But actually, it was a combination of, you know, maybe 10% LLM and 90% this other tool. But again, that provided that extra leverage that allowed them to make the progress. I think those kinds of things are really quite interesting: using the LLM as a starting point to drive a deterministic tool, and then you're able to see what the deterministic tool is doing. That's, I think, where there's some interesting interplay.
Speaking about going on from refactoring to software architecture, you were very busy writing books around the early 2000s. You wrote the book Patterns of Enterprise Application Architecture in 2002, and this was a collection of more than 40 patterns, things like lazy load, identity map, template view and many others. And I remember around this time there was your book about enterprise architecture patterns, there was also the Gang of Four book. There was a lot of talk; when I was interviewing around that time, on interviews they were asking me questions about how to do a factory pattern and singleton and all of these things. Software architecture was talked about, my sense was, in a lot of places, or a lot more. Then something happened, something starting from the 2010s. I no longer hear most technologists talk about patterns or architecture patterns. How have you observed this period of when the book came out? What was the impact of it, and why was it important to talk about it and put it into the industry? And how have you seen this change of where we stopped talking more on patterns, and why do you think it happened?
Yeah, I mean, what you're doing with patterns is you're trying to create a vocabulary to talk more effectively about these kinds of situations. I mean, it's just like, you know, in the medical world they come up with this jargon in Greek and Latin to more precisely talk about things that are quite involved and complex. Yes. And with patterns what we're trying to do is trying to evolve that same kind of language, except we're not doing it in Greek and Latin. I certainly feel that they do help communication flow more effectively, you know, once people are familiar with that terminology. I mean, you don't look at them as some kind of, you know, how many of them can you cram into the system you're building. It's more a sense of how can you use it to describe your alternatives and the options that you have, and also think more about when to apply things or not apply them. I mean, patterns are only useful in certain contexts. So you very much have got to understand the context of when to use them.
And yeah, it's kind of a shame that some of the wind has gone out of the sails of that, perhaps because people were overusing them in terms of trying to use them as a sort of, like, pinning medals on a chest. But it can still be very, I mean, I worked very recently with Unmesh on his book on patterns in distributed systems, and I felt that was a very good way of coming up with, again, a language to describe how we think about the core elements and better gain an understanding of how distributed systems work, which is an important aspect of how to deal with life these days, because we're all building these kinds of distributed systems. So I still feel that they can be a very good way of expressing that. It's hard for me to get a sense of why they kind of became less fashionable. Maybe they'll become more fashionable again. Who knows? But I'm always looking for ways to try to spread knowledge around and make things more understandable. And I do feel that this idea of trying to identify these, create these nouns that we can talk about things more precisely, is a good way of part of doing that.
I wonder if, because I've seen, I've worked at places where we used these things, and then places where we just threw them out the window, no one was using it. And a difference was honestly just kind of the age and the attitude of the company, because there was a sense at some point that the patterns there were for legacy companies. So startups would just start from a blank sheet of paper, you know, a whiteboard. You know, UML was a perfect example, where UML had pretty strict rules on how to do the arrows. And if you do that right, you could even generate code and do all these things. And at startups, the software architecture still exists, but you just put it on the whiteboard and you just drew a box or a circle and you didn't care about the arrows. And it was just, I guess, we're not going to lock ourselves into existing ways of doing things. And it's a bit of an education as well, like you do need to onboard to these things. You all need to have a shared understanding, and maybe it's just a combination of these two things. And I guess it's a generational thing as well. You know, every few years a new generation comes out, and the same way where at some point I was one of the first people in college where it was super cool to use Facebook, and it was just all scholar students, and then when my parents went on there it was super uncool to use Facebook, or my grandparents came on there. I kind of stopped using it when they started using it. So I wonder if there are like these waves going back and forth, because inside of these startups there is a language, like, you know, lingo, about how they talk about the architecture, and it starts to form over time. You start to see it, whether it's longer tenure people, you get more and more of the jargon, except it's not in a book that anyone can read, but you have to go in there or go to a similar company where they take the jargon with them.
Exactly. And people will create these jargons. And it's an inevitable part of communication. You can't explain everything from first principles requiring five paragraphs every single time. If you're using the term all the time, you just make a word out of it. And then everybody creates their own words. And all you're doing when you're coming up with a book like the Patterns of Distributed Systems is you're trying to say, "Okay, here's a set of words with a lot of definition and explanation of them, and let's hope we can kind of converge on that so that we can communicate a bit more widely." But it's also quite natural for people to say, you know, within our little environment, we create our own little jargon, so we don't take notice of that. And then you get the mismatches that occur; you only really notice that as you cross these different environments.
Grady Booch had an interesting take on this, by the way. So I asked him about the same thing, because he's been so much into software, he still is into software architecture, and he's progressed the field a lot. And he said that what he thinks happened is that, starting in like 20—because the patterns died out from mainstream industry, I'll say again, it's still in some pockets—but around the 2010s, one interesting thing that happened around that time is cloud. The cloud started to get bigger, AWS, Google Cloud, and a lot of companies started to build similar things. They started to build, initially, on-premise backend services where you had most of your business logic; later it moved to the cloud. And Grady said that these hyperscalers, the cloud providers, AWS for example, they built all these services that are really well architected, so you can kind of use one after the other, and it's well done. You don't need to worry too much about your data storage; you just use, let's say, DynamoDB or a managed Postgres service. So suddenly architecture is not all that important, because these blocks take care of it for you. You have these building blocks, and now you're talking about using this database on top of this system. His observation was maybe architecture was solved with a well-architected building block that you could use, and you didn't have to reinvent the wheel.
Yeah. But I suspect there are still patterns of using these things, and that's something I haven't delved into because I just haven't had the opportunity to focus on that, or more precisely, I haven't had enough of my colleagues banging on my door with draft articles to be able to publish on it.
Well, one pattern that I do see is every company, you know, names their systems. Some have wacky names, some have logical names. But when you talk about architecture, you typically talk about, you know, like at Uber we had the bank emoji service, which was being migrated to Gulfstream, which was, you know, these all sound like they don't make too much sense if you're from the outside. Sometimes they have proper names, they try with that, the payment profile service, but then there's a new version and that's now the payment pro—that's PP2, anyway. But inside every company, you will talk about these specific names and you will talk about how they work, how small they are, how large they are, and that's kind of, I feel, oftentimes the lingo.
Yeah, it is. That's again part of the lingo of larger organizations. And again, you take a company that's been around for much longer than Uber, and of course that lingo is baked into the organization. It can take you several years just to figure out what the hell's going on, because it just takes you that long to learn all of these systems and how they interconnect.
Well, one of the fascinating conversations that I had many years ago was with someone very high up in American Express, and we were talking about how he was responsible for rearchitecting their system to the next generation. And he was just getting ideas on how to socialize ideas and get things out. And I asked, how long have you been working on this? It has been 3 years.
And I was like, "Okay, so where are you, are you done?" He's like, "No, no, this is just the planning. [laughter] We're close to finishing the planning." And to me, it didn't compute, because like, in 3 years of planning? But again, once I started to understand the scale of the business, how much money, how many legacy systems they have, half of what he did was talk with business stakeholders to convince them or get buy-in. I guess this eventually happens with most companies, except when you're at a younger company or digital-first or tech-first companies, meaning founded in 2010 or later. You still don't see this, but it might come in 10 years.
>> Oh yeah, it certainly will. Oh, it's interesting. I remember I was chatting with somebody who had joined an established bank, and they had joined from a startup, and one of their jobs was to modernize the way the bank stuff was going. And the comment was, "Now I've been here 3 years, now I think I can understand the problem. I've got some idea of what I can do, what can be done." But it just takes you that long to really understand where you are in this new landscape, because it's big and it's been around a long time and it's complicated, and it's not logical because it's built by humans, not by computers. It's not a logical system.
And there's all sorts of history in there, because all sorts of things happen because so-and-so met so-and-so and had a row with so-and-so. And all of these things kind of percolate over time, and this vendor came in here and was popular over here, and then the person who liked this vendor got moved to a different part of the organization, and somebody else came in who wanted a different vendor. And all of this stuff builds up over time to a complicated mess. And any big company is going to have that kind of complicated mess, because it's very hard to not get into that situation. And yeah, I mean, Uber's lucky that it's only a relatively young company, but assuming it survives, in 50 years' time it'll be like American Express, right?
>> Yep. You can already see the changes, the layers of processes and so on, which is kind of necessary as you grow. Speaking of change and iteration and agile: you were part of the 17 people who created the Agile Manifesto, and I previously asked Kent Beck about this, who was another person involved. Can you tell me from your perspective what was the story there, on how you all came together, how this pretty chaotic, I think, day played out, and what was the reception, as you recall, back then? This was 2001.
>> Right. So I always feel the origin of it was actually a meeting we had that Kent ran about a year before we did the Agile Manifesto. It was a gathering of extreme programming folks who were working with extreme programming, and we had it at this place near where Kent was living at the time, in middle-of-nowhere Oregon. And he also invited some people who weren't directly part of the extreme programming group, folks like Jim Highsmith, along as well. And part of the discussion we had was: should extreme programming be the relatively narrow thing that Kent was describing in the white book, or should it be something more broad that had many of the similar kinds of principles in mind? And Kent decided he wanted something more concrete and narrow. And then the question is, well, what do we do with this broader thing, and how does it overlap with things like what the Scrum people were doing and all that kind of stuff? That's what led to the idea of getting together people from these different groups.
And we had the argument about whether we were going to hold it in Utah, because Alistair wanted it in Utah, and then Dave Thomas wanted to have it in Anguilla in the Caribbean, and for whatever reason we ended up in Utah, and the skiing. And we gathered together the people that we did, and of course it was a case of who actually came along, because obviously lots of people were invited who didn't come. And I wasn't terribly involved with that, although Bob Martin does insist that I got involved. He mentioned some lunch in Chicago, which is very likely, because I was going to Chicago all the time for work at the time. So I probably did, but I don't remember.
And of the meeting itself, I actually don't remember very much of it, which is a shame. I curse myself for not writing a detailed journal of those few days. I'd love to know, you know, how did we come up with that "this over that" structure for the values, for instance, which I think was really wonderful, but I have no idea how that got put together. So unfortunately, I get very vague about the actual doing of it. I do have a fairly clear memory, although we should be wary about that, and I'll come to why perhaps later, of Bob Martin being the one who was really insistent on "I want to make a manifesto," and me thinking, oh well, yeah, we can do that. The manifesto itself will be completely useless and ignored, of course, but the exercise of writing it will be interesting.
>> And that was my reaction to it. No matter how I felt about the manifesto, I felt, ah, nobody will take any notice of this.
Oh, wow.
>> But hey, we're having fun writing it, and we're understanding each other, etc. And that will be the value, right? We'll understand each other better.
>> And then of course the fact that it made a bit of an impact was kind of a shock. And then of course it gets misused most of the time, because there's that lovely quote from Alistair Cockburn that your brilliant idea will either be ignored or misinterpreted, and you don't get to choose which of the two it is.
>> Well, it also helps that the manifesto has four different lines, and so people just pick and choose which one they want to point to.
>> 12 principles.
>> Oh, and the 12 principles, yes. And the fact that it says at the beginning "we are uncovering," and that this is a continuous process, and what the manifesto is, is just: this is what we've got so far. So it's a snapshot of a point in time of where we were in 2001. Yeah, all sorts of subtleties to the manifesto.
But I think it had an impact in the sense that there was a certain way that we wanted to write software at Thoughtworks for our clients in 2000, and it was a real struggle, because they didn't want to work the way we wanted to. We said we want to put all this effort into writing tests, and we want to have an automated build process, and we want to do these kinds of things. We want to be able to progress in small increments. All of these kinds of things were anathema. You know: no, we've got to have a big plan over five years, and we'll spend two years doing a design, and we'll produce a design, and then it'll get implemented over the next year or so, and then we'll start testing, right? I mean, that was the mentality of how things ought to be done.
>> Yeah. That was just the commonly understood wisdom, right?
>> Yeah. And our notion of: no, we'd like to do that entire process for a subset of requirements in one month, please. Only a month. And of course we really wanted to do it in a week, but you know, baby steps. And so to me the great thing about agile is that we can actually go into organizations and operate much closer to the way that we'd like to be able to. Our clients will let us work the way we want to, to a much greater extent than we were able to do back in 2000. And so that is the success. I just wanted the world to be safe for those people that wanted to work that way to be able to work that way. Yeah, there's all sorts of other bad things that have happened as a result of all of this, but on the whole I think we are a bit better off.
>> And do you see, especially when you look at the enterprise clients that you have a lot more visibility into, a definite change from 25 years ago, like the concepts of agile are way more accepted? Like working with the customer, having a lot more incremental delivery, forgetting about these very long pieces of work, like it's just common everywhere, right? Can we say that, or at least?
>> I would say we've made significant progress, but compared to how we'd like it to be and where our vision is, it is still a pale shadow of what we wanted. And I suspect most of the 17 that are still with us would agree with that. We still feel we can do much, much better than we've been, but we have actually made material progress. And the thing is that we were always in that situation where we're kind of nudging our way forwards at a much slower rate than we'd like to be.
Yeah. Now of course AI is coming, and it is now everywhere, and it will be everywhere. So the core idea behind agile was that you make incremental improvements, and the shorter the better, and you could then build software that incrementally starts to improve. But today, especially with AI, there's going to be more software everywhere. There already is. And there's a sense that customers don't necessarily want to wait for incremental improvements. They want to see quality upfront. Do you think that agile will work just as well with AI, with even shorter increments, or do you think we might start to think about some different way to work with AI, putting on the quality lens up front as well, and getting back to a little bit of, you know, spec-driven development, like getting a version of the software that is just great to start with?
I don't know how the AI thing is going to play out, because we're still in the early days. I still feel that building things in terms of small slices, with humans reviewing it, is still the way to bet. What AI hopefully will allow us to do is to be able to do those slices faster, and maybe do a bit more in each slice, but I'd rather get smaller, more frequent slices than more stuff in each slice. Improving the frequency is usually what I think we need to do, and just cycle those steps more rapidly. That's where I felt we've had our biggest gains, through that more rapid cycle rather than trying to do more stuff in the same cycle, as it were.
And I still get a sense of that when talking to people, still saying, you know, can you look at all of the things that you do in software development and increase the frequency? Do half as much, but in half the time, and speed up that cycle. Look for ways to speed that through. And also just look at what you're doing. Look for the queues in your flow and figure out how to cut those queues down. If you were able to get some ideas from idea to running code in two weeks, how do you get it down to a week? Just try to constantly improve that cycle time. And I still feel that that's our best form of leverage at the moment, improving cycle time.
>> Yeah. And I've been talking with some of the leading AI labs on how they use it, because of course they're going to be on the bleeding edge. They will use this; it's also in their own interest to use their own tools. At Anthropic, on the Claude Code team, one of the creators of Claude Code, Boris, shared how he did 20 prototypes of a feature: the progress bar, when you do a task, how it lists out different steps and shows you where it's at. And he built 20 different prototypes that he all tried out and got feedback on, and decided which one to go with, in two days. And he showed me: he had videos, he just recorded these as he went, the exact prompt that he used, the output. And these were interactive prototypes, so they were not just, you know, on paper, but they were inside.
>> And to me, this was like, wow. If you would have told me you built 20 prototypes and asked me how long it took, I would have said two weeks, maybe a week if they were small, like paper prototypes. But you can still speed it up, and it is still manageable. Some of them he threw away. Some of them he shared with a small group, a bigger group. So I feel you're right on how we have not reached the limit of how quickly we can look at things.
>> Yeah, it comes back to feedback loops. I mean, so much of it is trying to figure out how we introduce feedback loops into the process, how we tighten those feedback loops so we get the feedback faster, so that we're able to learn. Because in the end, again, it comes back to: we have to be learning about what it is we're trying to do.
Speaking about learning and keeping up to date: how do you learn about AI? How do you keep up to date with what's happening? What approaches work for you? And what are approaches you see your colleagues follow who are also staying up with what's going on?
Well, the main way I learn these days is by working with people who are writing articles that are going onto my site, because my primary effort these days is getting good articles onto my site. And my view is that I'm not the best person to write this stuff, because I'm not doing the day-to-day production work. Haven't been doing it for a long time. The only production code I write is, ironically, the code that runs the website. I still write code, I still generate stack traces, but it's only within this very, very esoteric little area. So as a result, it's better for me to work with people who actually are doing this kind of work and help them get their ideas and their lessons and express them to as many people as possible. So I'm learning through the process of working with people to write their ideas down, which is a very interesting way of learning, because of course you're very deeply involved in the editing process for a lot of that material. That's my primary form.
I do do some experimentation when I get the chance, not as much as I'd like, but I do see that as a second priority to working with people. So it's only in the off time that I get to do that. And of course reading from what I feel are some of the better sources. Fortunately, one of those better sources is Birgitta, who has been writing with me. So that's good.
Simon
>> She's excellent. Yeah.
>> Birgitta's stuff is superb. Simon Willison, I keep an eye on what he's doing all the time. I wish I had his energy, his work rate for getting stuff out. Actually, I wish I had your energy, the amount of stuff you get out these days. And so I look for sources like that. I'm always interested in what folks like Kent are up to, because let's face it, so much of my career has been leeching off Kent's ideas, and there's no reason to stop doing that if it's still working, right? And so those are the kinds of sources. Then sometimes some books come through, and I work through those. So a lot of it is in that kind of direction. I might even watch a video occasionally, although I really hate watching videos.
So yeah. So it sounds like: find the people you trust, the sources you trust. Again, your blog, I can very much recommend it, because you have several people writing on it, so you actually have a pretty good frequency of in-depth articles about interesting topics. I rarely see topics that have been discussed in depth, and so I enjoy checking it out because of it.
I mean, one of the questions that I've been pondering is how you identify what a good source of information is. And this is more general, not just due to our profession, but of course due to the world generally, as we seem to be in an epistemological crisis of trying to understand what's going on in the world. And at some point I'm going to sit down and write this down, and I'll get a more coherent answer from it, but part of what I'm always looking for is a lack of certainty. I think a good
thing when people tell me, oh, I know the answer to this, I'm usually a good bit more suspicious, and I'm much more conscious of when people say, this is what I understand at the moment, but it's fairly unclear.
I remember one of my favorite early books when I was writing on the software architecture, I remember desperately looking for something in the Microsoft world as opposed to something in the Java world. There was a lot being written in Java world. This is back around the late 90s. Lots of stuff was being written in Java land, not much in Microsoft land. And then I discovered this Swedish guy, Jimmy Nilsson. And his book was full of stuff that says, well, this is how I'm feeling about this, this is the way to approach this stuff. He was very tentative all the time, very much clear that this was how he was currently feeling, but he understood that things might change. I've since got to know Jimmy really well and he's a fantastic guy. But what impressed me so much and what influenced me so much is I felt very much the degree to which, oh, this is somebody I can trust, because they're not trying to give me this false sense of certainty and confidence, and I think that's important.
Also someone who's keen to explore nuances and saying, well, this works in these circumstances. If somebody tells me, oh, you should always use microservices, or somebody says you should never use microservices, I mean, both of those arguments can be completely discounted. It's when you say, "Ah, these are the factors that you should be considering about whether to go in this direction or that direction." Whenever someone is stepping back and saying, "Ah, it's a trade-off. There's various things involved. Here's the factors you should go." And it's not going to be a simple answer. You've got to dig into the nuances. Then again, that increases my confidence because, again, I'm feeling this is someone who's thinking these things through and not just coming on a sort of simple railroad and going down it.
And I guess with these sources, you can also trust that everything we do in software engineering, it's going to be trade-offs, right? The most common answer of, like, how long will it take is it depends. It depends on are we doing a prototype, it depends on do I know the technology, etc. So if you're reading sources or if you're accessing sources where they tell you, okay, in my situation, you actually learn about their situation and you can figure out, like, okay, in this specific case for them, this worked or it didn't work, and later you can probably apply it a bit better. Because, again, it's very different if you're going to be working as a software engineer inside a highly regulated retailer that's 70 years old versus you've just started a brand new startup where, go and knock yourself out, zero customers. A huge difference.
Yeah. And then that's, I mean, and again you see it. I mean, frankly, we see it with clients. A lot of clients say, give us the answer, give us the cookbook, straightforward answer that I just need to apply. If you're looking for that kind of cookbook answer, you're going to get in trouble, because anybody who will tell you there's a cookbook answer, they either don't understand it or they're deliberately covering it up for you, because there's always tons of nuance involved.
We keep going back to this, like, now more than 50-year-old article, the No Silver Bullet, right? One question I got from online, I asked what people would like to ask from you, is what would your advice be today for junior software engineers who are starting out? There's all this AI stuff going on. We know with learning, I think you also mentioned, or it might have been Unmesh who mentioned, with junior engineers it could be a bit iffy: if you're relying too much on AI, will that hinder your learning? Because learning is important. If one of these engineers asked you, like, "Hey, I'm a junior engineer. I'd like to eventually become a more experienced engineer, what tactics would you advise me, especially with AI tools? Should I rely on them? Should I not? Is there something that might work better than other things?"
Well, I mean, certainly we have to be using AI tools and exploring their use. The hard part if you're more junior is you don't have this sense of to what extent is the output I'm getting good. And in many ways the answer is what it's always been: find some good senior engineers who will mentor you, because that's the best way that you're going to learn this stuff. And a good experienced mentor is worth their weight in gold, and in fact in many ways it's worth prioritizing that above many other things when it comes to your career, is getting that met. I mean, again, me finding Jim Odell early on in my career was enormously valuable. The best thing that could have possibly happened to me was just blind luck. But seek out somebody like that who can be your mentor. I mean, although we're peers in some ways, I often think of Kent Beck as a mentor, because, you know, we may be the same age or whatever, but his thinking is always leaping forwards. And so watching what he's doing has been very valuable. So again, find somebody like that.
The AI can be handy, but always remember it's gullible and it's likely to lie to you. So be probing on asking it: okay, why are you giving me this advice? What are your sources? What's leading you to say this? I mean, I remember this, this is generally a good thing: whenever people are giving you something, is to say, what is leading you to say that? What is the background? What is the context you're coming from? What are the things that are leading you to this point of view? And by probing that, you can get a better understanding of where they're coming from. And I think you have to do the same thing with the AI, because in the end the AI is just regurgitating something it saw on the internet. So the question is, did it see good stuff on the internet or did it see most of the crap that's on the internet, right? But if you can find your way to the good stuff, then that can be much more useful.
And looking at all this change that's happening right now with AI, LLMs, how do you feel about the tech industry in general?
I mean, in a broad sense, I'm positive, because I still feel there's so many huge things that can be done with technology and software. And we're still in a situation where demand is way more than we can imagine.
But that's a long-term view. I mean, at the moment we're in this very, I'm going to say, very strange... life has always been a strange phase. I mean, strange in different ways. The current strangeness is we're basically in a huge, certainly in the developed world, depression. I mean, we've seen a huge amount of job layoffs. I've heard numbers bandied around of quarter million, half a million jobs lost. I mean, it's that kind of magnitude. I mean, we're seeing it. At Thoughtworks, we used to be growing at 20% a year all the time until about 2021. We've hit a wall, and we see our clients are just not spending the money on this stuff. I mean, AI is doing its own separate thing, but it's almost like a separate thing going on, and it's clearly bubbly. But the thing with bubbles is you never know how big they're going to grow. You don't know how long it's going to take before they pop, and you don't know what's going to be after the pop. I mean, all this stuff is unpredictable. I do think there's value in AI in a way that, say, there wasn't with blockchain and crypto. There's definitely stuff in AI, but exactly how it's going to pan out, who knows? And I mean, I went through this cycle with stuff in the '90s and 2000. So it's a repeat of that, only at probably an order of magnitude more scale.
So all of that's going on, but really what's happening, the most important thing that's hit us, is not AI. It's the end of zero interest rates. That's the big thing that really hit us. And that's why the job losses started before AI, because of that kicking in. And we don't know how that's going to change, because this is a much more macroeconomic thing. We have a loony driving the bus in the United States. We have all sorts of other pressures going on internationally. Great uncertainty at the moment, and that's affecting us, because it means that businesses aren't investing. And while businesses aren't investing, it's hard to make much progress in the software world. And so we have this weird mix of no investment, pretty much depression in the software industry, with an AI bubble going on. And they're both happening at the same time.
And one masks the other. And yeah, depends on where you are. Like, I was in Silicon Valley, and if you're an AI company, inside it all looks great. If you're outside, again, you can benefit from it, but it's a lot more careful. And if you're outside of this bubble, let's say you're at a startup or a company that is not in AI, it's just tough. So you have these worlds happening.
I mean, this is still, I think, an industry with plenty of potential in the future. I think it's a good one to get into. You know, the timing is not as great as it would be getting into this industry in, say, 2005. But I still feel there's a good profession here. I don't think AI is going to wipe out software development. I think it'll change it in a really manifest way, like the change from assembly to high-level languages did, but the core skills are still there. And the core skills of being a good software developer, in my view, are still, it's not so much about writing code. That's part of the skill. A lot of the skill is understanding what to write, which is communication, and particularly communication with the users of software, and crossing that divide, which has always been the most critical communication path.
And you've also mentioned the expert generalist is becoming a lot more important, which, when I looked into the details, we'll link the article in the show notes, I think it was again...
Unmesh has been on fire.
He's on fire. But all the traits seem to have nothing to do with AI. It's about curiosity. It's about going deep. It's about going broad. It sounds like I'm hearing more and more people who are thinking longer about what it means to be a standout software engineer. The basics don't seem to change, right?
Yeah. And I do think that, and it has always been, communication and being able to collaborate effectively with people has always been, to my mind, the outstanding quality of what really makes the very best developers come through, certainly in the enterprise commercial world, which is the one I'm most familiar with. Because all the software we're writing is for people who are doing something very different to what we do. I remember when I was working in the health service, I always said, you know, here I am doing this conceptual modeling of health care. I understand a huge amount about the process of health care. You are not going to want me to treat whatever your medical problems are, because I am never going to have that skill, because I'm not a doctor. And so therefore the doctors have to be involved in the process.
So as closing, I just wanted to do some rapid questions where I'll fire and then you say what comes to mind. What is your favorite programming language and why?
I would say at the moment my favorite programming language is Ruby, because I'm so familiar with it. I've been using it for so long. But the one that is my love is Smalltalk, without a doubt. Smalltalk. There was nothing as much fun as programming in Smalltalk when I was able to do it in the '90s. That was such a fantastic environment.
You and Kent Beck. And Kent Beck is writing his Smalltalk server. It's his baby. I think he's making progress.
And I mean, there is still stuff going on. There is the Pharo project in Smalltalk. And I keep thinking, you know, if I could just take off some weeks and stop everything else I was doing, maybe investigate, see what's going on in the Smalltalk world again, because it was... I mean, there's still so much power in that language.
What are one or two books you would recommend, and why?
So a book I do particularly like to recommend is Thinking, Fast and Slow by Daniel Kahneman. I like it because he does a really good job of trying to give you an intuition about numbers and spotting some of the many mistakes and fallacies we make when we're thinking in terms of probability and statistics. And this is important in software development, because a lot of what we do is greatly enhanced if we could understand the statistical effects of what we see, but also in life in general, because I think our world would be a hell of a lot better if way more people understood a bit more about probability and statistics than they do. I mean, like most kids probably, when I did maths at school it was heavily calculus-based. I really do feel that it would have been a lot better if, you know, it was much more statistics-based, because of the knowledge of being able to use that. Well, I mean, one of the things that has helped me more with probability and probabilistic reasoning has been the fact that I'm heavily into tabletop gaming, where you have to constantly think in terms of probabilistics. And I just honestly feel that knowing that is important, and this book is, I think, a great way to get into that. And so it was one of the best reads I've had in the last few years.
Another book that I'd mention, that is completely separate and is challenging in a completely different way, that I've been totally obsessed with, is a book called The Power Broker. So this is a book about a guy called Robert Moses, who most people have never heard of, but was the most powerful official in New York City for about 40 years, from about 1920 to 1960. He was never elected to any office. He controlled more money than the mayor or the governor of New York during that time. And this book is about how he rose to power, how power works in a democratic society, often not in plain sight. And it's a fascinating book for that. It's also a fascinating book because it is so well written. There have been moments when I would just, you know, I've been reading a several-page passage of something and I would just have to stop to just appreciate how brilliant what I just read was. And that's valuable, because to be a better writer, and I think we all gain by being a better writer, it's really important to read really good writing. And his writing is magnificent. The downside is it's 1,200 pages. It's a really long book, but I was enjoying it so much that I didn't mind. And then once you go on from that, you move on to his second biography, because he's only written two biographies, and that's his currently five-volume biography of Lyndon Baines Johnson, LBJ, which is equally brilliant, and I've been reading it, but it's a lot more to ask, because it's four volumes so far and he still hasn't finished the fifth. But again, there are moments when I was just gobsmacked by how brilliant the writing was, and gobsmacked by the way, again, power works in a democratic society. And I think to understand how our world works, these kinds of books are really, really valuable.
And finally, can you give us a board game recommendation? You are very heavily into board games. Your website has a list of them as well.
Yeah, it's a tricky one, because it's kind of like saying, I'm really interested in getting into watching movies, which would be the movie you would recommend? Right, because there are so many different tastes and things. If I'm going to pick something that's, I think, not too complicated for someone to get into, that I think still has quite a lot of richness, at the moment I think the game I'd pick out would be something called Concordia. It's fairly
abstract in its nature, but it's easy to get into and it's got quite a good bit of decision making in the process.
Well, Martin, thank you so much. It was great that we could make it happen in person as well.
Yes, having that worked out really well. I just happened to be in Amsterdam for something else and I know somebody in Amsterdam, so I thought I'd get in touch and we finally get the chance to meet face to face.
It was amazing. Thank you.
Thank you.
Thanks very much to Martin for this interesting conversation. One of the things that really stuck with me is how the single biggest change with AI is about how we're going from deterministic systems to non-deterministic ones. This means that our existing software engineering approaches that were based on assuming a fully deterministic system, like testing, refactoring and so on, probably won't work that well and we might need new ones unless we can make elements more deterministic.
I also liked how Martin mentioned to us that the problem with vibe coding is that when you stop paying attention to the code generated, you stop learning and then you stop understanding, and you might end up with software that you have no understanding of. So be mindful in the cases when you are happy with this trade-off.
For more reading on AI engineering best practices and an overview of how the software engineering field changed in the past 50 years, check out related deep dives in The Pragmatic Engineer, which are linked in the show notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. This helps more people discover the podcast, and a special thank you if you leave a rating as well. Thanks and see you in the next
Article published