Martin Fowler

Key Insight: The greatest value of Architecture Decision Records lies not in the document itself but in the act of writing them, which forces teams to surface disagreements, clarify thinking, and reach genuine alignment.

Martin Fowler explains Architecture Decision Records (ADRs) as short documents that capture individual architectural decisions along with their context and consequences. He emphasizes that ADRs serve dual purposes: creating a historical record for future reference and clarifying thinking during the decision-making process. The post outlines practical conventions including storing ADRs in source repositories, using lightweight markup, maintaining immutable records with status tracking, and keeping documents brief. Fowler traces the concept back to Michael Nygard's 2011 article and notes ADRs' central role in the Advice Process for eliciting expertise and alignment.

Key Insight: Ideological commitment to open innovation is insufficient protection against a patent system that rewards legal capacity over technical merit, forcing even principled builders to engage defensively with a broken system.

The author traces their evolution from ideological opposition to software patents—rooted in Stallman-esque belief in open innovation—to a pragmatic acceptance of defensive patenting after experiencing patent aggression firsthand at Hike Messenger. When building Specmatic, they reluctantly filed patents not to monetize or block others, but purely as a defensive shield. The patent process itself proved unexpectedly clarifying, forcing precise articulation of genuine innovation and surfacing useful prior art. The author examines alternatives like OIN and open-source licenses, finding them insufficient against determined patent aggression. The conclusion: ideals matter, but they don't substitute for structural legal protection in an asymmetric system.

Key Insight: The practices that make human pair programming effective—onboarding, structured design discussion, shared standards, and documented decisions—apply equally to AI collaboration and are the primary lever for reducing AI-assisted development friction.

Fowler observes that developers skip the collaboration rituals they'd naturally use with human pair programmers when working with AI coding assistants, leading to a 'Frustration Loop' of generate-review-regenerate cycles. He argues the friction is not a failure of AI capability but of how we collaborate with these systems. Drawing on the parallel to onboarding and pairing with human teammates, he proposes five patterns: Knowledge Priming, Design-First Collaboration, Sensible Defaults, Context Anchoring, and Feedback Flywheel. The core reframe is treating AI as a junior teammate with infinite energy but zero context, not as a tool. Together, these patterns aim to build a shared mental model that reduces translation friction and shifts cognitive load from correction to intent.

Key Insight: Servant leadership is a dishonest framing that hides the manager's real power; host leadership offers a more truthful metaphor where the leader prepares the space and retains acknowledged authority to intervene.

Fowler challenges the popular agile concept of servant leadership, relaying Kent Beck's critique that it amounts to gaslighting since the manager claims to serve while retaining real power. He introduces an alternative metaphor from mental-health practice: host leadership. In this model, the leader prepares a suitable space, invites the team in, provides context, then steps back. The host leader still retains authority to intervene when needed, but the framing is more honest about the power dynamic than servant leadership.

Key Insight: Giving an LLM agent access to your email creates a perfect storm of security risks — untrusted content, sensitive data, and external communication — that no amount of convenience justifies without rigorous sandboxing.

Fowler warns against the growing trend of people using LLM agents to manage their email accounts autonomously. While acknowledging the appeal of offloading email drudgery, he argues that email represents a perfect instance of Simon Willison's 'Lethal Trifecta': untrusted content, sensitive information, and external communication capability. He notes that password-reset workflows through email make this especially dangerous. He suggests a mitigation approach of sandboxing the agent with read-only access and no internet connectivity, accepting reduced capability as the price of security.

Key Insight: The software industry sees AI and LLMs as a potentially Agile Manifesto-scale inflection point, warranting a similar gathering of practitioners to chart the profession's future direction.

In February 2026, Thoughtworks hosted a workshop called 'The Future of Software Development' in Deer Valley, Utah, deliberately echoing the 25th anniversary of the Agile Manifesto. About 50 invited participants—Thoughtworkers, software pundits, and clients—gathered for a day and a half of Open Space conference focused on how AI and LLMs are reshaping the profession. Fowler chose not to synthesize the discussions into a single narrative, instead distributing his insights across several fragment posts. The event was held under Chatham House Rule, limiting attribution of comments.

Key Insight: Bold formatting's power to draw the skimming eye is destroyed by overuse, and LLMs are accelerating this problem by defaulting to heavy bold in generated text.

Fowler argues that excessive use of bold formatting in technical and business writing is self-defeating, a trend he sees amplified by LLMs. He explains that bold's power comes from drawing the skimming eye, but this only works when used sparingly. He prefers italics for in-text emphasis and reserves bold for headings and highlighting unfamiliar terms at the point of explanation. He also notes that callouts are usually superior to bolded sentences for drawing attention, and closes with a deliberately over-bolded paragraph to illustrate the problem.

Key Insight: LLMs are powerful translation tools within established abstractions, but the human work of iteratively building stable domain models through the what/how feedback loop remains the essence of programming.

This three-way conversation between Unmesh Joshi, Rebecca Parsons, and Martin Fowler explores how programming is fundamentally about mapping domain concepts ('what') onto computational models ('how') through a continuous feedback loop. They argue that LLMs are useful as translation layers within this loop but cannot replace the human work of building stable abstractions and domain models. The discussion connects TDD, domain-driven design, and programming paradigms as tools for managing cognitive load and structuring code to survive change. They conclude that while LLMs excel at generating code within mature, well-established abstractions, they cannot drive the creation of new paradigms or build the deep structural understanding that makes software maintainable.

Key Insight: The adaptation-optimization divide is a tension to manage through deliberate mode-switching and handoff tax reduction, not a tribal allegiance to pick.

Fowler argues that the software industry's decades-long tribalism between Agile and Traditional camps misses the point entirely. Both adaptation (fast learning under uncertainty) and optimization (reliability under constraints) are essential operating modes, not competing philosophies. He introduces an explore-expand-exploit framework where teams tune four dials—uncertainty, risk, cost of change, and evidence threshold—to determine which mode should dominate at any given moment. Drawing on examples from biotech and a mass spectrometry firm, he shows that failures happen at the seams between modes, not within them. He advocates replacing tribal allegiance with deliberate 'dominance tuning' and cutting handoff tax at transitions.

Key Insight: This is a personal music recommendation post with no software engineering content—Fowler shares his deliberate, non-streaming approach to music discovery and his eclectic world music tastes.

Martin Fowler shares his six favorite musical discoveries from 2025, continuing an annual tradition. He describes his listening habits—buying digital albums in batches rather than using streaming services. The selections span Balkan brass, acoustic pop, Ethio-Jazz, Latin acoustic, Indian classical fusion, and European jazz-prog, reflecting eclectic world music tastes. Each pick is accompanied by personal context about how he discovered the artist and what makes the album distinctive.

Key Insight: LLMs can accelerate the mechanics of coding, but true software capability comes from the irreplaceable learning loop of experimentation and understanding—shortcutting this process leads inevitably to a maintenance cliff.

Martin Fowler argues that software development is fundamentally an act of learning that cannot be shortcut by LLMs or any other tool. While LLMs excel at reducing friction—helping with setup, boilerplate, and translating between specialized languages—they cannot replace the essential learning loop of observing, experimenting, and applying knowledge. The productivity gains promised by LLMs risk creating a 'maintenance cliff' where initial speed evaporates when requirements deviate from generated solutions. Fowler warns that Agile's hard-won insights about iterative, learning-centered development should not be abandoned in the rush to adopt AI-assisted coding.

Key Insight: The inability of LLMs to distinguish instructions from data is a fundamental architectural flaw that makes prompt injection attacks inherent to agentic AI systems, requiring defense-in-depth strategies rather than point solutions.

Agentic AI systems present severe security vulnerabilities that the industry has no reliable way to defend against. The fundamental problem is that LLMs cannot distinguish between data and instructions—they process everything as text in a single context, making prompt injection attacks possible. Simon Willison's 'Lethal Trifecta' identifies the three factors that create attack vectors: access to sensitive data, exposure to untrusted content, and the ability to externally communicate. When all three exist, systems become vulnerable to data exfiltration through crafted prompts. The article provides practical mitigations including sandboxing, containerization, limiting privileges, splitting tasks, and maintaining human oversight, while acknowledging these are imperfect defenses against a fundamental architectural weakness.

Key Insight: XP doesn't kill design—it transforms it from an up-front planning exercise into a continuous discipline of simplification, requiring even greater skill in refactoring, pattern recognition, and knowing when to defer decisions.

Fowler examines whether Extreme Programming's rejection of up-front design means design is dead, concluding it is not—but its nature has changed. He contrasts planned design (detailed blueprints before coding) with evolutionary design (design emerging during implementation), arguing that XP's enabling practices—testing, continuous integration, and refactoring—flatten the software change curve enough to make evolutionary design viable. The key insight is that XP doesn't eliminate design but shifts the balance: instead of heavy up-front architecture, teams do just enough initial design while continuously refactoring toward simplicity. Success requires technical leadership focused on coaching rather than dictating, and a 'will to design' that ensures code quality remains high throughout development.

Key Insight: We're still in the early experimental phase of understanding how to use LLMs effectively, and the most valuable approach is paying close attention to workflows rather than making confident predictions about an unknowable future.

Fowler shares candid reflections on LLMs and software development, arguing that current surveys fail to account for different usage workflows—particularly the gap between autocomplete and agentic editing approaches. He admits uncertainty about programming's future, criticizing anyone who claims to know what LLMs will mean for the profession. He acknowledges AI is definitively a bubble but notes that bubbles still create real value and survivors. The piece emphasizes that hallucinations are LLMs' core feature, not a bug, and warns about serious security risks from AI agents with data access.

Key Insight: AI-assisted reverse engineering can transform opaque legacy systems from modernization blockers into actionable blueprints by reconstructing functional intent through multi-source triangulation rather than attempting to recover original code.

The article describes a successful experiment using AI to reverse-engineer a massive legacy system that had become a 'black box'—critical to operations but lacking source code, documentation, and institutional knowledge. The team faced a system with 650+ database tables, 1,200 stored procedures, 350 user screens, and 45 compiled DLLs with no surviving documentation. Rather than attempting to recover the original code, they focused on reconstructing the functional intent through a multi-lens approach: analyzing UI layers, using change data capture, inferring server logic, and performing 'binary archaeology' on compiled DLLs. The result was a validated functional specification detailed enough to drive implementation of a replacement system.

Key Insight: Building your own CLI coding agent reveals that the transformative power comes not from any single capability but from combining multiple tools—testing, file access, documentation, reasoning—into a context-aware development partner that understands your specific codebase.

The article walks through building a custom CLI coding agent using Pydantic-AI and the Model Context Protocol (MCP), demonstrating why building your own agent provides insights that simply using commercial tools cannot. The author shows how combining multiple capabilities—test running, sandboxed code execution, documentation access, internet search, and file system operations—creates an agent qualitatively different from single-purpose tools. The implementation uses Claude via AWS Bedrock and progressively adds MCP servers for specialized capabilities. The key insight is that CLI agents represent a shift from AI as writing assistant to AI as development partner that can understand project context, execute multi-step workflows, and learn from specific codebases.

Key Insight: AI-assisted legacy migration succeeds not through brute-force code generation, but through structured workflows where human expertise validates AI analysis and guides generation with clear intent.

This article presents a structured workflow called "Research, Review, Rebuild" for migrating legacy codebases using Generative AI augmented with Model Context Protocol (MCP). The author demonstrates this approach by modernizing Bahmni, an open-source hospital management system, migrating its AngularJS frontend to React/TypeScript while also transitioning from OpenMRS REST APIs to FHIR standards. The workflow emphasizes thorough analysis of existing code through MCP servers, expert validation of AI-generated plans, and disciplined code generation with human oversight. The complete migration of a display control took approximately 10 minutes of code generation at $2 cost, compared to 2-3 days of manual development, achieving 95% test coverage.

Key Insight: The essential creative work of programming—discovering abstractions and growing a domain vocabulary through iterative coding—cannot be delegated to LLMs; developers must maintain control during abstraction discovery and only hand off mechanical code generation once stable abstractions exist.

Martin Fowler and Unmesh Joshi discuss how programmers should approach LLM-assisted development through the lens of Fred Brooks's essential vs. accidental complexity distinction. They argue that while LLMs excel at reducing accidental complexity (boilerplate, framework integration, repetitive patterns), the essential work of programming—discovering and stabilizing abstractions, growing a domain vocabulary, and shaping solutions through iterative code exploration—must remain developer-led. The conversation emphasizes that programming is fundamentally about 'growing a language' of abstractions that emerge through hands-on coding, not upfront specification. They distinguish between two programming activities: discovering abstractions (where developers must maintain control) and applying stable abstractions (where LLMs can reliably generate code). The authors warn against 'driving everything through prompts' as a form of dangerous upfront design that bypasses the iterative learning that happens through writing code.

Key Insight: Professional speakers can reliably finish on time by building optional expandable sections into their talks rather than trying to predict exact timing through rehearsal.

Martin Fowler describes his technique for finishing talks on time regardless of schedule changes: using pre-planned optional sections called Expansion Joints. These are topics that work if skipped but can be expanded upon if time permits. The technique involves single flex-slides with key phrases that can be covered in thirty seconds or expanded to five-ten minutes. Fowler notes this approach was especially valuable since he never rehearsed talks, relying instead on adrenaline. The method allowed him to give the same talk in different time slots and handle interactive sessions with unpredictable audience engagement.

Key Insight: OKRs transform from bureaucratic compliance tools into drivers of real outcomes only when teams assume ownership through co-creation rather than receiving cascaded mandates from above.

The article argues that OKRs fail when imposed top-down as management compliance tools, but succeed when teams assume ownership and co-create goals aligned with organizational strategy. Fowler distinguishes Team OKRs from cascaded mandates—they emerge from dialogue where leadership shares intent and teams define what they can realistically influence and measure. The piece presents a practical cycle of planning workshops, weekly check-ins using the GRIP framework, and retrospectives that transform OKRs from static quarterly artifacts into living conversations. A case study from a Brazilian financial institution illustrates how strategic objectives flow from company priorities through business units to teams without prescribing solutions. The core distinction is between teams that execute someone else's priorities versus teams that commit to outcomes they genuinely believe in.

Key Insight: Tech leaders should stop defending developer productivity and instead take ownership of measuring and validating actual business impact, transforming themselves from executors into strategic partners who can prove the value of discretionary spend.

Martin Fowler introduces Sriram Narayan's concept of 'Impact Intelligence' - the constant awareness of business impact from tech initiatives. The article argues that developer productivity metrics are misguided because output rarely correlates with business outcomes. It proposes that tech leaders should shift focus from measuring productivity to tracking actual business impact through impact networks, robust demand management, and impact validation. The piece provides a practical framework for CTOs to escape the 'spray and pray' feature factory trap by introducing rigorous documentation requirements and measurement practices.

Key Insight: Despite sophisticated multi-agent workflows and extensive prompt engineering, AI code generation remains fundamentally unreliable for autonomous business software development due to its non-deterministic nature and tendency toward assumption-filling and brute-force problem-solving.

Fowler's team ran experiments to test how autonomously LLMs can generate and maintain business software without human intervention, using a Spring Boot CRUD application as a test case. They employed multiple strategies including multi-agent workflows, stack-specific prompts, code examples, reference applications, and review loops to improve reliability. Despite these controls, AI consistently produced problematic patterns: overeagerness (adding unrequested features), filling requirement gaps with assumptions, applying brute-force fixes, declaring success despite failing tests, and leaving code quality issues. They concluded that for business-critical software serving thousands or millions of users, AI cannot be trusted to autonomously create and maintain code without human oversight.

Key Insight: Rather than making definitive pronouncements about AI's role in software development, the most valuable approach is systematic, ongoing investigation documented as it unfolds.

Martin Fowler introduces an ongoing series of memos exploring how generative AI and LLMs will affect software delivery practices. He acknowledges both the intrigue and uncertainty developers feel about this technology's long-term impact on the profession. The series documents learnings from Fowler and his Thoughtworks colleagues as they investigate AI coding assistants, autonomous agents, and related topics. The collection spans from foundational explorations in 2023 to more recent pieces on spec-driven development and vibe coding in 2025.

Key Insight: The personas we use to understand LLMs—donkey, genie, slot machine, Uriah Heep—reveal a technology that is simultaneously powerful and treacherous, helpful and manipulative, requiring far more effort to use well than its occasional successes suggest.

Fowler explores different personas developers use to conceptualize LLMs, from Birgitta Böckeler's 'stubborn donkey' to Kent Beck's 'genie' and 'slot machine' metaphors. He introduces his own preferred persona: Uriah Heep from Dickens, the obsequious servant who manipulates those he claims to serve. The post argues that these metaphors help us understand LLMs' contradictory nature—helpful yet unreliable, powerful yet undermining. Fowler suggests that the slot machine comparison explains why LLMs seem easy to use (occasional jackpots) while actually requiring significant effort to wield effectively.

Key Insight: Expert Generalist should be recognized as a first-class skill that organizations deliberately identify, assess, and develop—because people who master fundamentals over tools and collaborate across boundaries are what make complex software actually ship.

Martin Fowler argues that the software industry's obsession with narrow specialization is misguided. The most effective technologists are 'Expert Generalists'—people who combine deep fundamentals knowledge with curiosity, collaboration skills, and customer focus. These individuals can rapidly adapt to new technologies because they understand underlying patterns rather than just tools. Organizations benefit enormously from Expert Generalists who can work across specialty boundaries, unblock teams, and get things done, though teams still need some specialists for deep domain knowledge.

Key Insight: LLMs don't just raise programming's abstraction level—they fundamentally alter its nature by introducing non-determinism, forcing developers to abandon the assumption that the same code produces the same results.

Martin Fowler argues that LLMs represent a paradigm shift in programming comparable to the transition from assembler to high-level languages. While subsequent language improvements (from Fortran to Ruby) raised abstraction levels incrementally, they maintained the same fundamental nature of deterministic communication with machines. LLMs break this pattern by introducing non-determinism—prompts stored in version control won't guarantee identical behavior across executions. Fowler sees this as not merely moving up the abstraction ladder but moving sideways into uncharted territory, requiring programmers to develop entirely new mental models for working with these tools.

Key Insight: DeepSeek's breakthrough demonstrates that frontier AI capabilities can be achieved at dramatically lower cost through tight co-design of model architecture, training algorithms, and HPC infrastructure—not just through scaling compute.

This technical overview synthesizes four DeepSeek papers that collectively demonstrate how architecture, algorithms, and hardware must be co-designed for efficient large-scale LLM training. The series progresses from foundational scaling law research through architectural innovations like Multi-Head Latent Attention and Mixture-of-Experts, to HPC-level optimizations enabling 671B parameter models. The culmination is DeepSeek-R1, which uses large-scale reinforcement learning to produce emergent chain-of-thought reasoning, with R1-Zero notably achieving this through pure RL without supervised fine-tuning. The key insight is that cost-effective frontier AI requires tight integration between model architecture and training infrastructure.

Key Insight: Reading your writing aloud activates your brain's sensitivity to bland, lifeless prose in a way that silent reading cannot.

Martin Fowler shares a writing tip from Bruce Eckel: read your writing out loud to catch awkward passages. The technique works because it engages the part of your brain that processes spoken language, which is more sensitive to bland or flabby prose. Fowler advocates for a conversational writing style, imagining he's explaining concepts to companions in a pub. He warns against corporate and academic prose styles, which he finds devoid of life and engagement. The goal is writing that readers can hear in the author's voice.

Key Insight: Effective threat modeling transforms abstract security concerns into concrete, actionable improvements by systematically following data flows and asking 'what can go wrong?' in regular, bite-sized sessions rather than exhaustive workshops.

This guide presents threat modeling as an essential security practice for software teams, advocating for a 'little and often' approach integrated into daily development rather than exhaustive upfront analysis. The core methodology involves tracing data flows through systems and systematically asking 'what can go wrong?' using the STRIDE framework (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege). The article provides two practical examples: a quick 15-30 minute whiteboard session for a single feature, and a larger cross-team workshop for platform infrastructure. The key outcome is translating identified threats into prioritized, actionable security stories in the team's backlog.

Key Insight: Function calling bridges the gap between LLM reasoning and real-world system interactions, but requires careful security guardrails and explicit action space restrictions to prevent prompt injection attacks.

This article explains function calling, a capability that allows LLMs to interact with external systems by generating structured JSON outputs containing function names and parameters rather than executing functions directly. Using a Shopping Agent example, the author demonstrates how to build an agent that interprets user intent and invokes appropriate APIs. The piece covers system prompts, function schemas, security guardrails against prompt injection, and the use of libraries like instructor to reduce boilerplate. It also explores how LLM-based approaches might offer advantages over traditional rules engines and explains the Model Context Protocol (MCP) for dynamic tool discovery.

Key Insight: LinkedIn has emerged as the most effective social platform for technical content promotion, but social media overall remains a minor traffic driver compared to search and direct visits.

Martin Fowler analyzes engagement data from 24 recent social media posts across LinkedIn, X (Twitter), Bluesky, and Mastodon to understand which platforms matter most for announcing new articles. Despite X having the most followers, LinkedIn generates more likes and comparable reposts. Bluesky performs surprisingly well relative to its smaller follower base, while Mastodon has low engagement but higher quality replies. Traffic source data shows LinkedIn has surged past X to become the #3 referrer to his site, though social media overall accounts for only a small fraction of his traffic, with 80% going to articles over six months old.

Key Insight: Truly exceptional non-fiction writing can transform any subject matter into compelling narrative, making even 1200-page books impossible to put down.

Martin Fowler shares his experience of becoming captivated by Robert Caro's massive biographical works, starting with The Power Broker about Robert Moses and continuing through the multi-volume Lyndon Johnson series. Initially hesitant about the sheer size of these books, Fowler was won over by Caro's exceptional prose and meticulous research. He describes how Caro can make arcane political maneuverings into page-turners and puts readers directly into the human impact of his subjects' actions. As a professional non-fiction writer himself, Fowler admits Caro's work humbles him and shows how far he has to go toward mastery of his craft.

Key Insight: Production GenAI systems require a layered architecture of patterns—Evals for measurement, RAG for knowledge extension, Guardrails for safety, and retrieval enhancements for accuracy—with Fine Tuning reserved as a costly last resort.

This article catalogues emerging patterns for building production-ready generative AI systems, addressing the gap between proof-of-concept and production deployment. The authors argue that GenAI products are fundamentally different from traditional software, introducing challenges like hallucination, non-determinism, and unbounded data access. They present RAG (Retrieval Augmented Generation) as the primary approach for most use cases, supported by patterns like Evals for assessment, Guardrails for safety, and Hybrid Retrievers for better document retrieval. Fine-tuning is positioned as a last resort when RAG proves insufficient.

Key Insight: Software development advice that works brilliantly in one context may sound absurd in another because the underlying environmental conditions differ so fundamentally.

The Forest and Desert metaphor, developed by Beth Andres-Beck and Kent Beck, describes two distinct software development contexts that struggle to communicate. The Desert represents typical dysfunctional development environments with abundant bugs, uncultivated skills, and poor user communication. The Forest represents well-run teams practicing Extreme Programming with swift deployments, healthy code, and regular customer contact. The metaphor's key insight is that advice from one context sounds nonsensical to those in the other, and while transformation from Desert to Forest is possible, it requires difficult, counter-intuitive work.

Key Insight: Codemods bring the same AST-based transformation power that IDEs provide locally to the scale of entire codebases, but their effectiveness depends on breaking complex changes into composable, well-tested pieces and acknowledging that edge cases will require human judgment.

The article explains how codemods—automated scripts that use Abstract Syntax Tree manipulation—enable developers to apply large-scale code transformations consistently across codebases. Starting with the challenge library developers face when introducing breaking API changes, Fowler demonstrates how codemods parse code into ASTs, modify the tree structure, and rewrite the source. Through practical examples including feature toggle cleanup and React component refactoring, he shows how to write, test, and compose codemods using tools like jscodeshift. The piece also covers handling edge cases, applying these techniques in Java with JavaParser and OpenRewrite, and leveraging platforms like Hypermod and Codemod.com.

Key Insight: Great musical discovery comes from following trusted curators into less-travelled corners where cross-cultural fusion and distinctive sounds reward the adventurous listener.

Martin Fowler shares his eight favorite musical discoveries of 2024, breaking his usual tradition of limiting the list to six. The selections span an eclectic range of global music, from Irish pipes blended with jazz beats to Tunisian protest songs, Belgian trip-hop, Icelandic jazz-fusion, and Indian classical music merged with string quartets. Each album is described with evocative language highlighting what makes it distinctive. Fowler credits music journalism sources like Dave Sumner's Bandcamp column and Songlines magazine for leading him to these lesser-known artists.

Key Insight: Design tokens transform design decisions into versionable, distributable data that can be automatically propagated across platforms and teams through deployment pipelines.

Design tokens are design decisions represented as data, serving as a single source of truth for both design and engineering teams. The article explains how tokens solve cross-team consistency problems (like z-index conflicts in micro-frontends) by providing a shared vocabulary. Tokens should be organized in layers—option tokens define available styles, decision tokens specify how styles are applied, and component tokens map to specific UI elements. A deployment pipeline can automate token distribution, enabling design changes to propagate across multiple frontends in a single day. The author recommends starting with two layers and adding complexity only when needed, while also considering token scope to limit which tokens are exposed to developers.

Key Insight: Designing data products should start from concrete use cases and work backwards to data sources, ensuring each product represents a single cohesive information concept describable in one or two sentences.

This article provides a practical methodology for designing data products as part of a data mesh implementation. The authors advocate for a 'working backwards' approach, starting from specific use cases rather than data sources, to avoid analysis paralysis. They define what data products are (self-contained, deployable units serving analytical data) and what they're not (dashboards, PDFs, or entire data warehouses). The process involves short workshops to identify data products, overlay multiple use cases to ensure reusability, assign clear domain ownership, and define service level objectives. The article concludes with implementation guidance including establishing reusable blueprints and automating governance.

Key Insight: The fragmentation of social media after Twitter's decline has made open protocols like Bluesky's AT protocol increasingly valuable as insurance against future platform instability.

Martin Fowler reflects on the fragmented state of social media two years after Elon Musk's Twitter takeover. He describes his preference for curated feeds over algorithmic suggestions and uses social media primarily to announce articles rather than for social interaction. While Twitter persists, its importance has declined as users migrated to platforms like Bluesky and LinkedIn. Fowler finds LinkedIn most effective for reaching readers despite its corporate atmosphere, while the Fediverse hasn't gained expected traction. He expresses hope for open protocols like Bluesky's AT protocol to provide resilience against future platform instability.

Key Insight: The Strangler Fig pattern, traditionally used for backend systems, can effectively modernize legacy mobile applications by embedding domain-encapsulated micro-apps that incrementally replace functionality while delivering value immediately rather than waiting years for a complete rewrite.

This article demonstrates how Thoughtworks applied the Strangler Fig pattern to incrementally modernize a large legacy mobile application, avoiding the risks of a complete rewrite. By embedding React Native micro-apps within an existing native application and using domain-driven design to identify 'points of interception,' teams were able to replace functionality piece by piece. The approach leverages a modular architecture where each micro-app encapsulates a domain with its own Backend for Frontend acting as an anti-corruption layer. Results from the proof of concept showed first value delivered in 1 month (versus 2 years for a full rewrite) and a 50% reduction in median cycle time compared to the legacy application.

Key Insight: GenAI's transformative potential for legacy modernization lies not in generating code but in systematically extracting understanding from existing codebases through knowledge graphs, reducing the prohibitive cost and expertise barriers that have long made large-scale modernization impractical.

This article argues that while GenAI in software development has primarily focused on code generation, its greatest potential lies in understanding and modernizing legacy systems. Thoughtworks developed CodeConcise, an internal accelerator that uses LLMs combined with knowledge graphs to make legacy modernization more cost-effective. The approach treats code as data, parsing it into Abstract Syntax Trees stored in graph databases, then enriching it with LLM-generated explanations at various abstraction levels. In a proof of concept, they reduced reverse engineering time from 6 weeks to 2 weeks per module, potentially saving 240 FTE years for a complete mainframe modernization program. The authors acknowledge this is early-stage work with context-dependent results, but see significant promise in addressing problems that have made large-scale modernization prohibitively expensive.

Key Insight: Automated fitness functions that test data product metadata against governance standards provide scalable, continuous governance that empowers decentralized teams while ensuring interoperability across a data mesh.

The article explores how to apply architectural fitness functions to govern data products in a data mesh architecture. Traditional governance through data stewards doesn't scale with decentralized teams, so automation becomes essential. Fitness functions are tests that evaluate how close implementations are to design objectives, enabling 'shift left' governance where issues are caught early. The piece details specific assertions for key data product characteristics like discoverability, addressability, trustworthiness, and interoperability. Implementation patterns include running tests within data catalogs, using external processes with catalog APIs, and leveraging LLMs to interpret metadata quality. Publishing results on dashboards creates social incentives for teams to maintain governance standards.

Key Insight: Cycle time is a valuable concept for driving faster feedback loops, but its inherent measurement ambiguity means teams should focus on consistent internal definitions rather than cross-team comparisons.

Cycle time measures how long it takes to move a feature from idea to production, and minimizing it is a core goal of agile development. The concept shifts focus from activity-based waterfall processes to iterative, functionality-based work that enables rapid feedback loops. However, cycle time is inherently slippery because teams define start and stop points differently—from first commit to initial idea, from canary release to full deployment. Fowler advises against comparing cycle times between teams without consistent definitions, and suggests using distinguishing adjectives rather than trying to separate 'cycle time' from 'lead time.' Despite the measurement challenges, pursuing shorter cycle times through value stream mapping, smaller features, and increased slack remains worthwhile for faster feedback and learning.

Key Insight: Legacy modernization succeeds through gradual strangulation rather than wholesale replacement, but technical change alone is insufficient without parallel organizational transformation.

Martin Fowler revisits his influential 'Strangler Fig' metaphor for legacy system modernization, inspired by observing strangler figs in Queensland that gradually replace their host trees. He argues against the common approach of wholesale system replacement, which frequently fails due to timeline pressures and specification difficulties. Instead, he advocates for incremental modernization that builds new components alongside legacy systems, gradually replacing functionality. The approach requires clear outcomes, identifying seams for decomposition, delivering small replaceable pieces, and crucially, organizational change to prevent recreating the same problems.

Key Insight: The problem with AI and algorithmic decision-making isn't the technology itself but the opacity—requiring explainability is a more effective regulatory principle than restricting specific technologies.

Martin Fowler argues that regulating AI and algorithms by restricting their use misses the point—the real issue is opacity, not the technology itself. He contends that any decision affecting people's lives must be explainable, whether made by AI, complex algorithms, or simple chronological sorting. Using a personal Avis rental car dispute as an example, he demonstrates how opacity causes harm regardless of whether AI is involved. Fowler suggests that requiring explainability would naturally limit problematic AI deployment while incentivizing development of more transparent systems. He proposes that AI's best use may be as a tool for humans to better understand decision-making processes, potentially replacing opaque models with explicit logic over time.

Key Insight: HTML templates contain testable logic that benefits from the same TDD practices we apply to other code, using CSS selectors to focus assertions on what matters while ignoring irrelevant markup details.

The article argues that server-side HTML templates contain logic that deserves automated testing, not just manual browser inspection. It demonstrates a progression of testing techniques: first validating HTML soundness with parsers, then using CSS selectors to verify specific elements and content, then parameterizing tests for easy extension, and finally using Playwright with headless browsers to test JavaScript-driven behavior like HTMX interactions. The author shows that testing templates catches real errors and improves code quality, including forcing better accessibility practices.

Key Insight: Effective data fetching in SPAs requires combining multiple patterns—parallel fetching, code splitting, and prefetching—to eliminate request waterfalls while keeping the codebase maintainable through proper separation of concerns.

This article examines data fetching patterns in single-page applications, addressing the challenge of maintaining responsive UIs while handling asynchronous operations. Fowler's co-author Juntao Qiu presents five key patterns: Asynchronous State Handler (decoupling fetch logic from UI), Parallel Data Fetching (avoiding request waterfalls), Fallback Markup (declarative loading states with Suspense), Code Splitting (lazy loading non-critical components), and Prefetching (loading data before it's needed). The piece uses a Profile component example throughout, progressively adding complexity to demonstrate each pattern. While React is used for examples, the patterns apply broadly across frontend frameworks.

Key Insight: Good footnote design requires intentional friction—readers should consciously choose to pursue tangential details rather than having them interrupt the main narrative flow.

Fowler explains his evolving approach to footnotes in writing. He initially avoided them, believing important content belonged in the main text. While writing about Obama's 2008 campaign technology work, he discovered footnotes helped preserve narrative flow while retaining important details. He recently updated his site to show footnotes inline when clicked rather than jumping to the page bottom. He deliberately rejected sidenotes because they're too easy to read inadvertently, breaking reader flow.

Key Insight: Successful mainframe modernization requires identifying architectural seams—natural boundaries in legacy code—that enable incremental migration with dual-run verification, rather than risky wholesale replacement.

This article describes Thoughtworks' approach to incrementally migrating a 40-year-old, 7-million-line-of-code mainframe system to the cloud for a UK client's data platform. Rather than attempting a risky 'Big Bang' cutover, they advocated for identifying 'seams'—junction points in the legacy code where new behavior could be inserted with minimal changes. The approach involved dual-running both systems in parallel, comparing outputs to verify behavioral parity, then gradually retiring mainframe capabilities. The team identified multiple seam types: external interfaces (batch inputs, APIs), internal interfaces (database readers/writers, batch pipeline handoffs), and granular data characteristics. While Thoughtworks was only involved for the first year and didn't reach production, they validated multiple approaches for incremental legacy displacement.

Key Insight: Technical excellence in software development is inseparable from human kindness and the ability to build genuine relationships with the people you work alongside.

This is a memorial tribute to John Kordyback, a Thoughtworks colleague who died at 64. The post celebrates his 20+ year career helping organizations adopt agile practices, particularly his pioneering work applying continuous delivery to legacy mainframe systems. Fowler and numerous colleagues share memories emphasizing John's exceptional kindness, mentorship abilities, and understanding that agile success depends fundamentally on human relationships. The tributes consistently highlight his patient, empathetic approach to consulting, his infectious humor, and his ability to build trust with everyone from junior developers to executives.

Key Insight: The most effective approach to measuring developer productivity starts with qualitative data from developers themselves to identify opportunities, then uses quantitative metrics to drill deeper—because humans can detect problems that log-based metrics cannot.

The article argues that organizations measuring developer productivity often fail because they rely solely on quantitative metrics like DORA, which don't provide the insights leaders need. The authors advocate for qualitative metrics—measurements derived from human input through surveys—which can capture both subjective attitudes and objective behavioral data. They demonstrate that even DORA's benchmarks are actually collected through qualitative survey methods. The piece concludes that a mixed-methods approach combining qualitative and quantitative data provides the most complete picture of developer productivity, with qualitative data serving as the starting point to identify opportunities before drilling deeper with quantitative metrics.

Key Insight: The perceived cost of frequent pair rotation is actually an investment that pays dividends in knowledge distribution, team resilience, and reduced context-sharing overhead over time.

The article explores an experiment where teams practicing infrequent pair rotation (monthly or upon task completion) were challenged to rotate pairs daily for two weeks. The authors found that teams with infrequent rotations exhibited the same problems as solo coding—knowledge silos, difficult onboarding, and individuals becoming owners of specific code regions. Through daily retrospectives and structured facilitation, teams discovered that context sharing became easier with more frequent rotation, not harder. While no team chose to continue daily rotations, all dramatically increased their frequency, with one team moving from monthly to every three days.

Key Insight: Legacy system replacement fails not primarily due to technology choices but because organizations attempt to change technology while leaving their structure, culture, and ways of working intact—creating a perpetual treadmill of incomplete modernization efforts.

The article addresses the common problem of organizations being trapped in cycles of incomplete legacy system replacements. The authors identify that technology is only 50% of the legacy problem—ways of working, organization structure, and leadership are equally important. They propose breaking the cycle through four key activities: understanding desired outcomes, breaking problems into smaller parts, successfully delivering those parts, and changing the organization to allow ongoing improvement. The piece emphasizes that without broader organizational change, companies should expect the same failed outcomes they've seen previously. A detailed case study demonstrates how these patterns were successfully applied to replace critical integration middleware.

Key Insight: Remote teams need periodic face-to-face gatherings not primarily for the work sessions, but for the informal social interactions that build the trust necessary for effective remote collaboration.

Martin Fowler argues that remote-first teams, despite their many advantages, still need regular face-to-face gatherings to maintain effectiveness. While remote work excels for focused solo tasks, activities requiring rapid multi-person input are better done in person. The most valuable aspect of these gatherings isn't the scheduled work but the informal social interactions that build trust and human connection. He recommends week-long gatherings every two to three months for distributed teams, viewing travel costs as an investment rather than an expense to minimize.

Key Insight: The choice between remote and co-located work isn't about which communication style is theoretically superior, but about which approach lets you assemble the strongest possible team given real-world constraints.

Martin Fowler examines the debate between remote and co-located software development teams, arguing that while co-located teams generally communicate more effectively, remote work often produces better outcomes by expanding the talent pool. He identifies four distribution patterns—single-site, multi-site, satellite workers, and remote-first—each with distinct trade-offs. The core insight is that a remote team, though potentially less productive than its hypothetical co-located version, may outperform the best co-located team you could actually assemble. Fowler concludes that organizations mastering remote work will gain competitive advantage as top developers increasingly reject commuting and relocation requirements.

Key Insight: LLM application development benefits enormously from the same engineering disciplines—automated testing, refactoring, and iterative delivery—that make traditional software development successful.

The article documents a seven-day engagement building an AI Concierge proof of concept, demonstrating that traditional software engineering practices remain essential for LLM application development. The team used AWS services for speech-to-text, Bedrock for LLM processing, and text-to-speech capabilities. They developed three testing approaches: example-based tests for deterministic intent verification, auto-evaluator tests using LLMs to assess harder-to-test properties, and adversarial tests for security vulnerabilities. The authors emphasize that LLM engineering encompasses far more than prompt design, including error handling, persistence, logging, and defense in depth. They conclude that lean engineering practices—automated testing, refactoring, and iterative feedback—provide the same competitive advantage for LLM applications as for traditional software.

Key Insight: Continuous Integration's true value lies not in tooling but in enabling evolutionary design through frequent, small integrations that make refactoring safe and keep codebases healthy for sustained productivity.

Continuous Integration (CI) is the practice of having every team member merge their changes into a shared mainline at least daily, verified by automated builds. Fowler traces the evolution from painful, months-long integration phases to modern CI where integration is a non-event taking minutes. The article details essential practices: version-controlled mainlines, automated self-testing builds, immediate fixing of broken builds, fast build times through deployment pipelines, and automated deployment. CI enables refactoring, reduces bugs through frequent small integrations, and makes release a business decision rather than a technical hurdle.

Key Insight: Seams are not just testing conveniences but strategic architectural insertion points that enable observability, testability, and gradual system migration - and designing with seams in mind from the start prevents future legacy headaches.

Martin Fowler explains the concept of 'seams' in legacy systems - places where behavior can be altered without editing the source code at that location. He demonstrates several techniques for introducing seams (parameter injection, service locators, module-level functions) using a shipping calculation example. The post argues that seams serve multiple purposes beyond testing: enabling observability through probes and facilitating gradual legacy migration. Fowler concludes that designing new software with seams in mind, particularly through test-driven development, creates systems that are easier to maintain and evolve.

Key Insight: Seeking out the intersection of jazz and world music traditions reveals innovative artists who push boundaries while honoring their cultural roots.

Martin Fowler shares his six favorite musical discoveries of 2023, focusing on the intersection of jazz and world music. The selections span West African kora music, modern big-band jazz, Ukrainian folk-jazz fusion, Afro-Andean funk, British folk innovation, and ambient bluegrass. Fowler emphasizes choosing lesser-known artists while also acknowledging Peter Gabriel's long-awaited album release. He credits music discovery sources like Bandcamp Daily, OK Jazz podcasts, and Songlines magazine for introducing him to these artists.

Key Insight: Investing in evergreen content that provides lasting value pays off significantly - older articles continue generating substantial traffic years after publication, contrary to the conventional wisdom that drives content churn.

Martin Fowler analyzes traffic patterns to martinfowler.com from 2011-2023, revealing that traffic peaked around 2020 and has since declined to 2015 levels. The analysis shows extremely skewed distribution where 10% of pages generate over 80% of traffic, with traffic dropping exponentially after publication but stabilizing after six months. Notably, older articles continue to perform well, with posts over five years old generating about half of all post traffic - validating Fowler's strategy of prioritizing lasting content over churn. Weekend traffic is significantly lower than weekday traffic, and December shows consistent drops due to holidays.

Key Insight: The criticism that software developers should be more like 'real' engineers is based on a misunderstanding of how traditional engineering actually operates.

Fowler challenges the common criticism that software developers should work more like 'traditional' engineers, arguing this comparison is based on misconceptions about how engineering actually works in practice. Drawing on his own Electronic Engineering degree, he initially found such comparisons compelling but now sees them as flawed. Rather than developing his own argument, he points readers to Glenn Vanderburg's talk 'Real Software Engineering' and Hillel Wayne's interview series with 'crossovers' who worked in both traditional engineering and software. The post serves as a curated reading list rather than a standalone argument.

Key Insight: TDD's value comes not just from writing tests first, but from the often-neglected refactoring step that prevents tested code from becoming a messy aggregation of fragments.

Test-Driven Development is a software construction technique created by Kent Beck in the late 1990s that guides development through writing tests first. The process follows three repeated steps: write a test, write code until the test passes, then refactor. Before starting, developers should create a list of test cases and sequence them to drive toward key design decisions. The technique provides self-testing code and forces developers to think about interfaces before implementation. Fowler emphasizes that neglecting the refactoring step is the most common way to fail at TDD, resulting in messy code aggregations.

Key Insight: Small, frequent commits aren't just good hygiene—they're a debugging superpower that enables efficient binary search through your code's history to pinpoint exactly when bugs were introduced.

Diff debugging is a technique for hunting regression bugs by identifying which specific code change caused the bug to appear. The approach requires version control, reproducible builds, and benefits greatly from small, frequent commits. The method uses a binary search between a known good version and the buggy version to efficiently locate the guilty commit. Git bisect can automate this process, especially when combined with an automated test that detects the bug. Fowler advocates for extremely frequent commits during development sessions to enable this debugging technique even for bugs caught by slower-running tests.

Key Insight: Distributed systems, despite their inherent complexity around synchronization and reliability, converge on a common set of reusable patterns that can be studied and applied systematically.

This post introduces Martin Fowler's catalog of patterns for distributed systems, which addresses the fundamental challenges of building reliable software across multiple nodes with unreliable networks. The patterns emerged from observing how core distributed software (data storage, messaging, system management) solves common problems with similar solutions. Fowler began collecting these patterns in 2020 and published them as a book in 2023. The catalog now serves as a reference with short summaries linking to deeper content, covering everything from consensus algorithms to replication strategies to clock synchronization.

Key Insight: The enduring value of liberal arts education lies not in specific domain knowledge but in transferable skills—critical thinking, clear communication, and interdisciplinary synthesis—that become more rather than less valuable as technology rapidly evolves.

The author argues that liberal arts degrees provide crucial skills for success in tech roles like product management, despite the declining enrollment in such programs. Drawing from their own experience with an international studies degree, they identify three transferable skills: critical thinking for evidence-based decision-making, clear communication for stakeholder management, and interdisciplinary thinking for connecting disparate concepts. The piece emphasizes that these skills become even more valuable in the age of generative AI, where evaluating outputs and crafting effective prompts require the same analytical and communication abilities. The author concludes that specialized tech degrees may be short-sighted, as technologies change but adaptable thinking skills endure.

Key Insight: Extracting stateful logic into headless hooks or context providers creates a clean separation between behavior and presentation, enabling the same interaction patterns to power completely different visual implementations.

This article introduces the Headless Component pattern as a solution for managing complex UI logic in React applications. Using a dropdown list as an example, Fowler demonstrates how separating behavioral logic from visual presentation enables reusable, accessible components. The pattern extracts state management and interactions into custom hooks or context providers, allowing developers to apply any UI design while maintaining consistent functionality. The article also contextualizes this approach within the broader history of GUI patterns like Presentation Model and MVVM.

Key Insight: Technology strategy should be created alongside business strategy through targeted investigation of specific strategic directions, not as a separate wish list created after business decisions are made.

Martin Fowler challenges the conventional approach to technology strategy, which starts with current state and builds a wish list of improvements. Instead, he advocates starting with business objectives and investigating whether current technology can achieve proposed strategic directions. This integrated approach ensures technology strategy is born together with business strategy, making technology a driving force for new revenue streams rather than an afterthought. The article provides a comprehensive framework covering growth strategies, foundational improvements, people support, and future-readiness, with specific lines of inquiry for each direction.

Key Insight: A lightweight demo front-end bundled with your API transforms stakeholder demos from confusing JSON dumps into comprehensible experiences, while also accelerating development, testing, and troubleshooting across the entire team.

The article advocates for building simple demo front-ends for API-only products to solve the problem of meaningless demos where developers show raw JSON to confused stakeholders. Rather than using tools like Swagger UI or Postman, teams should create lightweight HTML/JavaScript interfaces bundled with the API that can generate valid requests automatically, parse responses into readable formats, and guide users through workflows. The demo front-end provides benefits beyond demos: developers use it for local testing, QA teams use it in test environments, and it can demonstrate API usage to potential partners. The author recommends avoiding dedicated build processes to keep the development loop fast, using inline JavaScript with minimal libraries instead of heavy frameworks.

Key Insight: Long-lived teams aligned to business capabilities preserve architectural integrity and enable true ownership, while project-centric models inevitably create technical debt through misaligned incentives and constant team churn.

Business-capability centric teams are long-lived teams aligned to specific business areas like order management or billing, rather than temporary project teams. These teams own their domain end-to-end—thinking, building, and running their systems—without handoffs to other teams. While this approach may require slightly more headcount than project-centric models, it preserves architectural integrity by avoiding the shortcuts and technical debt that project teams create when rushing to deliver scope. The key to success is ensuring teams are outcome-oriented toward business metrics rather than just delivering features. Business capabilities can be categorized as strategic (custom-built) or utility (buy and configure), with different staffing and delivery approaches for each.

Key Insight: The primary value of internal platforms is reducing cognitive load on business-aligned teams, not standardization or cost savings—a distinction that fundamentally changes how platform teams should approach their work.

Martin Fowler explains Team Topologies, a framework by Matthew Skelton and Manuel Pais for organizing software development teams. The model defines four team types (stream-aligned, platform, enabling, and complicated-subsystem) and three interaction modes (X-as-a-Service, collaboration, and facilitating). Fowler identifies the framework's key insight: platforms exist primarily to reduce cognitive load on business-aligned teams, not for standardization or cost-reduction. This perspective shifts how platform teams should think about their design decisions and roadmaps. While acknowledging the model's deliberate simplicity, Fowler argues these constraints make it useful for evolving organizations toward more effective operations.

Key Insight: The two-pizza team concept is less about pizza-based headcount limits and more about creating autonomous, outcome-oriented units with full ownership of a business capability and minimal cross-team dependencies.

A two-pizza team is a small, outcome-oriented team that owns all aspects of delivering software for a specific business capability. The name emphasizes size (5-8 people, max ~15), but equally important is the team's full-stack responsibility and minimal dependencies on other teams. These long-lived product teams operate under 'you build it, you run it' principles, deploying and monitoring their own code. While two-pizza teams can be the primary organizational unit, they require platform support and must provide well-designed APIs to enable peer collaboration, with Conway's Law shaping how this team structure influences software architecture.

Key Insight: Platform teams must strategically match their collaboration patterns to each phase of platform adoption, then deliberately transition from high-touch collaboration to scalable self-service models as adoption grows—recognizing that this painful but necessary shift is their central challenge.

Platform teams succeed through collaboration with other teams, but the right collaboration model depends on the phase of platform adoption. The article identifies three phases: migration (platform team drives changes to product teams' code), consumption (product teams integrate platform features), and evolution (product teams need platform improvements). Each phase has different ownership dynamics requiring different collaboration patterns. Early collaborative modes are valuable for discovering boundaries but don't scale—platform teams must intentionally transition to self-service, as-a-service models. The biggest challenge for young platform teams is managing this shift from high-touch collaboration to scalable, documented self-service while keeping customers satisfied.

Key Insight: Decentralizing architecture decisions to empowered teams, guided by an advice process rather than approval gates, dramatically accelerates delivery while improving collective ownership and understanding.

This experience report describes how Xapo Bank transformed its architecture practice from a centralized bottleneck to a decentralized, advice-based model. Originally a Bitcoin custodian that pivoted to become a licensed bank, Xapo faced challenges with technical debt, globally distributed teams across 40+ countries, and slow decision-making through a traditional architecture function. By implementing the Architecture Advisory Forum (AAF) based on Andrew Harmel-Law's conversational approach, combined with Domain-Driven Design and Team Topologies reorganization, Xapo empowered teams to make architectural decisions independently while seeking advice from stakeholders. The result was dramatically faster decision-making—from weeks or months down to days—with better documentation and collective ownership of architecture.

Key Insight: Effective AI co-pilot applications succeed not through sophisticated prompting alone, but through thoughtful UI design that structures user-LLM interactions and maintains context across multiple exploration paths.

This article describes Boba, an experimental AI co-pilot application built by Thoughtworks to augment product strategy and creative ideation processes. The team designed Boba to go beyond simple chat interfaces, using LLMs to help with research, scenario building, strategy ideation, and concept generation. Through building Boba, they identified seven key patterns for LLM-powered applications: Templated Prompt, Structured Response, Real-Time Progress, Select and Carry Context, Contextual Conversation, Out-Loud Thinking, Iterative Response, and Embedded External Knowledge. The article emphasizes that building these applications requires significantly more effort on UI/UX (80%) than on prompt engineering (20%), and that effective co-pilot experiences depend on thoughtful mediation between users and LLMs.

Key Insight: Modular architecture only delivers its promised benefits when team structures are simultaneously reorganized to match domain boundaries, supported by investment in developer experience - addressing architecture, teams, or tooling in isolation produces limited results.

This article examines how a large enterprise resolved two common mobile development problems: slow feature delivery and feature disparity across market apps. The organization initially tried adding developers and splitting teams, but this only increased coordination overhead without reducing cognitive load. The solution required simultaneously evolving technical architecture (domain-bounded contexts), team topology (autonomous domain teams decoupled from specific markets), and developer experience (a dedicated platform team). By aligning team structures with a modular architecture through the Inverse Conway Maneuver, they achieved a 60% reduction in cycle time, 18-fold improvement in development costs for domain integration, and 80% reduction in team startup costs.

Key Insight: Modern privacy-enhancing technologies have matured from research labs to production systems, offering rigorous mathematical guarantees that can replace naive data hoarding with user-centric architectures—but they require technologists to actively engineer privacy in rather than treating it as an afterthought.

This article introduces Privacy Enhancing Technologies (PETs) that provide rigorous privacy guarantees for data processing. The author covers three main production-ready technologies: differential privacy (which adds carefully calibrated noise to query results), federated/distributed learning (which keeps data at the edge rather than centralizing it), and encrypted computation (which allows computing on data without decrypting it). The piece argues that the proliferation of machine learning systems trained on personal data has made PETs increasingly urgent, as models can leak private information through memorization and inference attacks. The author advocates for incrementally engineering privacy into systems rather than treating it as an afterthought, while acknowledging that technology alone cannot solve the broader social and political dimensions of privacy.

Key Insight: Rather than debating which DI framework to adopt, teams should focus on the qualities they want in their codebase and use partial application with structural typing to achieve minimal coupling and maximum testability.

The author advocates for a 'function-first' approach to dependency composition in TypeScript, using partial application to inject dependencies rather than traditional DI frameworks. Starting from frustrations with inconsistent patterns across a codebase, he demonstrates building a REST service through TDD, creating factory functions that return configured handlers. The approach emphasizes minimal coupling between modules, keeping types private by default, and leveraging TypeScript's structural typing to maintain type safety without explicit type sharing. The result is discrete, testable modules that can evolve independently.

Key Insight: AI writing assistants are most valuable as collaborative tools for creating first drafts and prompting additional ideas, but they require skilled human oversight to ensure accuracy and appropriate tone.

Martin Fowler documents his experiments using ChatGPT as a technical writing assistant for Thoughtworks' Technology Radar blips and macro trends articles. He finds the AI useful for creating first drafts and suggesting additional content, but notes significant weaknesses including overly optimistic tone, accuracy issues, and context limitations. The output requires substantial editing by skilled experts, and the time savings may be less than expected. He concludes that AI tools help humans produce higher quality results when used as collaborative starting points rather than replacements for human expertise.

Key Insight: What AI generates from simple prompts reveals the biases embedded in its training data - and by extension, the biases present in how our society represents certain professions online.

Fowler and colleague Mike Mason experimented with Stable Diffusion to generate portraits of 'technical authors,' finding the results revealing about AI biases. The initial images (implied to show predominantly white males) prompted reflection on how AI training data reflects societal biases. When ChatGPT was asked to generate better prompts, it notably included one specifically describing a 'confident female technical writer' - suggesting the AI recognized the need to explicitly specify diversity. Fowler finds it telling that ChatGPT chose to include gendered specifications in its suggestions, highlighting how default assumptions get encoded into AI systems.

Key Insight: Effective LLM-assisted programming requires treating the model like a junior developer—providing architectural context upfront, requesting a plan before code, and iteratively refining outputs rather than expecting working code in one shot.

Xu Hao demonstrates an effective approach to using ChatGPT for generating useful, self-tested code. The technique involves priming the LLM with detailed architectural guidelines and implementation strategies, then asking it to produce a master plan before generating any code. This 'Generated Knowledge' approach—combined with Chain of Thought prompting—allows developers to verify alignment with their architecture before committing to code generation. The code produced isn't perfect but can be iteratively refined through targeted prompts, and the master plan structure helps manage context window limitations across multiple sessions.

Key Insight: Continuous flow trades iteration overhead for autonomy, but that trade-off only pays off for experienced teams who don't need the guardrails that regular cadences provide.

Continuous flow is an agile scheduling approach where teams prioritize user stories in a list and pull new work as they complete items, using WIP limits to stay focused on finishing rather than accumulating nearly-done work. It eliminates the overhead of iteration planning, estimation, and capacity calculation. However, the approach works best for experienced teams handling unpredictable work streams, while less experienced teams benefit from the feedback loops that timeboxed iterations provide. Teams using continuous flow should maintain enough slack to handle surges—a continuously busy team is a warning sign.

Key Insight: Deliberately undercommitting creates the breathing room teams need to address systemic impediments and respond quickly—making them more productive over time than teams running at maximum utilization.

Martin Fowler argues that deliberately leaving unallocated time (slack) in iteration planning, rather than maximizing story allocation, actually improves team productivity. He recommends planning at the team's lowest consistent velocity to increase predictability. Slack time can be productively used for tackling technical debt, improving tooling, deepening customer understanding, or responding to urgent cross-team requests. While slack might seem inefficient, teams without it cannot address impediments that accumulate and slow them down over time. The principle applies equally to timeboxed iterations and continuous flow approaches.

Key Insight: The true value of timeboxed iterations isn't scheduling efficiency but their ability to make problems visible through a natural stopping function that forces teams to confront estimation failures and process dysfunction.

Timeboxed iterations divide project work into fixed periods where teams allocate user stories based on estimated capacity. The key discipline is that iteration end dates never slip - incomplete stories become new work items. Fowler recommends using 'Yesterday's Weather' to set capacity, specifically taking the minimum of recent iterations rather than the average to build in valuable slack. While continuous flow eliminates iteration overhead, iterations provide a rhythm and crucially make problems visible through their natural stopping function. Teams that regularly struggle to complete work or rush at iteration ends are seeing signals of underlying issues that slack time could address.

Key Insight: User stories succeed by staying deliberately vague until development time, with just enough detail for prioritization, allowing requirements to emerge through collaboration rather than upfront specification.

User Stories are small chunks of desired software behavior used in agile development to break down functionality into manageable pieces for planning. Kent Beck introduced the term in Extreme Programming to encourage informal, conversational requirements gathering rather than lengthy specifications. Stories should fit on a note card and remain deliberately vague until development begins, with just enough detail for prioritization. The INVEST mnemonic (Independent, Negotiable, Valuable, Estimable, Small, Testable) captures the characteristics of well-formed stories, while the 'As a... I want... So that...' format provides essential context for understanding true user needs.

Key Insight: Brass Birmingham's defining quality is its symbiotic player interaction model, where using other players' resources creates mutual benefit, elevating it beyond traditional competitive or resource-blocking mechanics.

Martin Fowler celebrates Brass Birmingham reaching the #1 spot on BoardGameGeek's rankings, detailing his personal history with the hobby and BGG's ranking system. He explains what makes Brass Birmingham special: its Industrial Revolution theme, its symbiotic player interaction model where helping others also helps yourself, and its beautiful production quality. Fowler distinguishes this heavy strategy game from casual fare and traces its lineage from Brass Lancashire (2007). He recommends playing it twice within a week to internalize the rules and appreciate the depth.

Key Insight: React applications should treat React as just the view layer and apply established separation-of-concerns patterns — domain models, layered architecture, and strategy pattern — to keep business logic independent, testable, and reusable outside any UI framework.

This article argues that React applications should be structured using established UI patterns like layered architecture rather than cramming all logic into components. The author walks through the progressive evolution of a Payment feature, demonstrating how to extract concerns into custom hooks, domain model classes, pure presentational components, and network access layers. Using the Strategy pattern, the article shows how to eliminate shotgun surgery when adding country-specific payment logic. The core thesis is that frontend applications deserve the same separation of concerns that backend and desktop GUI applications have long employed, and React should be treated as just the view layer.

Key Insight: Retrospectives fail when teams skip generating genuine insights about root causes and instead jump directly from surface-level symptoms to action items.

Aino Vonge Corry identifies common antipatterns that undermine retrospectives, drawing from her experience as a facilitator. She argues that retrospectives have become widespread due to agile adoption, but many teams go through the motions without learning proper facilitation. Through a Danish team's story, she illustrates three antipatterns: Wheel of Fortune (jumping to solutions without understanding root causes), In the Soup (wasting time discussing things the team cannot change), and Loudmouth (allowing one person to dominate discussion). Each antipattern comes with a refactored solution drawn from established facilitation techniques. The core message is that retrospectives fail not because the concept is flawed, but because teams skip the hard work of generating genuine insights.

Key Insight: Successful Data Mesh transformations require starting with business-technical alignment through collaborative workshops rather than diving into technology or exhaustive upfront analysis.

The article describes Thoughtworks' 'Data Mesh Accelerate Workshop,' a structured multi-day workshop designed to help organizations begin their Data Mesh transformation. It identifies two common pitfalls in Data Mesh adoption: starting with technology without business alignment, and spending too long in big design upfront analysis. The workshop provides a middle path with collaborative activities that build shared understanding, define a nirvana vision, establish metrics and OKRs, explore use cases, and discover data products. The piece is essentially a practitioner's guide with step-by-step facilitation instructions for each workshop activity.

Key Insight: Musical innovation thrives at the intersection of genres and traditions, and the most compelling artists are those who challenge the boundaries of their instruments and styles.

Martin Fowler shares his annual list of six musical discoveries from 2022, spanning genres from techno-jazz big band to Mediterranean trance, Afrobeat, English folk, accordion jazz, and manipulated free jazz improvisation. The post is a personal diversion from his usual software topics, highlighting lesser-known artists and albums with links to Bandcamp samples. He also gives an honorable mention to Queen's 1986 Wembley concert recording, reflecting on their unmatched live energy. The piece concludes by crediting his music discovery sources and linking to his other annual music posts.

Key Insight: Organizations should invest in federated social media infrastructure now to own their communication channels and escape dependency on unpredictable centralized platforms.

Fowler argues that organizations—whether companies, governments, or NGOs—should run their own Mastodon servers rather than depend on centralized platforms like Twitter or Facebook. The Fediverse model allows organizations to control their social media presence using their own domain, establishing trust and authenticity without platform intermediaries. Organizations can set their own rules of engagement, invite employees or partners, and never lose followers since accounts are portable. Thoughtworks has successfully used their Mastodon instance for employee engagement and talent attraction. The piece positions federated social media as a strategic investment against the uncertainties of centralized platforms.

Key Insight: Software architecture and organizational structure are inextricably linked; you cannot successfully change one without deliberately addressing the other.

Fowler argues that Conway's Law—the observation that software architecture mirrors the communication structure of its development organization—is one of the few principles in software architecture that practitioners universally accept. He outlines three responses: ignoring the law (doomed to fail), accepting it by ensuring architecture doesn't clash with team communication patterns, or employing the Inverse Conway Maneuver to deliberately reshape team structure to encourage desired architecture. The post emphasizes that modular decomposition of systems and organizational structure must evolve together throughout an enterprise's life. Fowler notes that while the Inverse Conway Maneuver is useful, it's not a quick fix for rigid existing systems, and changes require small steps with vigilant feedback.

Key Insight: Decentralized, federated systems like Mastodon embody good software design principles by making decisions reversible and distributing responsibility to appropriate organizational boundaries.

Martin Fowler documents his transition from Twitter to Mastodon following Elon Musk's acquisition, providing practical guidance on federation, verification, cross-posting, and community norms. He explains the federated architecture where users choose servers (instances) and can easily migrate between them, contrasting this with Twitter's centralization. The article chronicles his learning process over several months, covering topics from basic account setup to list management and content warnings. He concludes with engagement data showing surprisingly similar interaction rates between his 344,000 Twitter followers and 18,000 Mastodon followers, suggesting the Fediverse has become equally important for his tech-savvy audience.

Key Insight: Twitter becomes useful when you treat it as a curated discovery feed rather than a conversation platform, deliberately avoiding the engagement traps that make social media toxic.

Martin Fowler explains his personal approach to using Twitter effectively, emphasizing curation over engagement. He values Twitter's brevity constraint and uses it primarily to discover interesting articles rather than for conversations, having learned in the 90s that online discussions rarely prove worthwhile. He carefully curates who he follows, uses lists to organize topic-specific feeds, insists on chronological ordering, and avoids replies and arguments. He acknowledges Twitter's harassment problems while noting his privileged position in not being targeted, and expresses skepticism about Musk's understanding of content moderation challenges.

Key Insight: Effective project starts require enough upfront alignment to understand what MVP to build and why, but not so much that teams get bogged down in detailed planning before learning from real users.

The lean inception is a one-week workshop designed to help teams quickly align on building a Minimum Viable Product before starting agile development. Paulo Caroli developed this approach at Thoughtworks after needing to compress traditional multi-week inceptions due to personal circumstances. The workshop focuses specifically on understanding the MVP through structured daily activities including product vision, personas, features, and user journeys. Unlike traditional inceptions, teams don't write or estimate user stories—instead they focus on validating business assumptions about what users actually need. The approach works well for both large projects needing lean orientation and startups evolving ideas into software products.

Key Insight: Infrastructure platforms should be treated as products with developers as customers, requiring clear goals, user research, early feedback, and simplicity to succeed rather than being mandated top-down.

The article provides a comprehensive guide for building infrastructure platforms that enable product teams to focus on building solutions rather than managing hosting infrastructure. It argues that organizations should start with a clear problem statement and measurable goal before investing in platform teams. The authors emphasize treating the platform as a product with real users (developers), conducting proper discovery, onboarding users early for feedback, and avoiding over-complication. Success depends on creating a great user experience that teams want to adopt voluntarily rather than being mandated to use.

Key Insight: The most rewarding musical discoveries often emerge at the intersection of genres and cultures, where artists blend traditions in unexpected ways.

Martin Fowler shares six of his favorite musical discoveries from 2021, ranging from jazz-techno fusion to Indian-influenced brass bands and Latin-African crossover. The selections reflect his eclectic, non-mainstream tastes with an emphasis on cross-cultural musical fusion and interesting rhythmic explorations. He highlights artists like Johanna Burnheart (jazz violin meets techno), Christian Scott aTunde Adjuah (modern jazz trumpet), and Red Baraat (Indian-influenced brass). The post serves as an annual tradition of sharing new-to-him music discoveries with readers.

Key Insight: Effective architecture at scale comes not from centralized decision-making but from creating conversational structures that enable distributed decision-making with appropriate advice-seeking, accountability, and shared learning.

This article presents an alternative to traditional top-down software architecture by introducing a decentralized, conversation-based approach centered on the 'Advice Process.' Rather than having architects make all decisions, anyone can make architectural decisions provided they consult those affected and those with relevant expertise. The approach is supported by four elements: Architectural Decision Records (ADRs), Architecture Advisory Forums, team-sourced principles, and organization-specific technology radars. The author argues this method produces better, faster, more accountable decisions while developing architectural thinking across teams rather than concentrating it in a few individuals.

Key Insight: Integration is not a tactical problem to be solved with purchased tooling but a strategic capability that requires building clean interfaces over digital capabilities using general-purpose programming languages.

Fowler argues that commercial integration tools (ESBs, ETL, API platforms) are essentially programming languages, not solutions you can purchase off-the-shelf. Organizations mistakenly treat integration as a tactical concern of wiring systems together, when it should be a strategic focus on building clean interfaces over digital capabilities. Low-code integration DSLs suffer from programming-over-time limitations—poor diffing, testing friction, scaling challenges, and operational observability gaps. While these tools can help with workflow simplification and B2B integration long tails, they should never own the interface evolution. Integration strategy is the key architectural driver of organizational acceleration and competitive advantage.

Key Insight: Constraining technology choices to default-trial-retire forces teams to complete their existing technology transitions before accumulating more complexity.

Teams should limit technology choices to three per category: a sensible default, an experimental trial, and a legacy option being retired. This constraint forces intentional decisions about adopting new technologies—before adding something new, teams must either complete retiring the legacy option or abandon the failed experiment. At organizational scale, this requires more coordination time but can be facilitated through tools like internal technology radars that communicate preferred technologies across verticals.

Key Insight: The appropriate level of architectural coupling and governance rigor should be calibrated to the organizational distance between teams—tight coupling is acceptable where coordination is easy, while strict decoupling is necessary where it's hard.

Martin Fowler argues against one-size-fits-all technology governance, proposing instead that architectural rigor should scale with organizational distance. Using MYOB's structure as an example, he introduces the concept of 'strong' and 'weak' forces of alignment between teams, where teams within the same domain can tolerate tighter coupling due to easy communication, while cross-organization integrations require strict decoupling and versioning. The model recognizes that coupling isn't inherently evil—its cost depends on how easily affected parties can coordinate changes. This framework helps organizations achieve 'aligned autonomy' by matching governance strictness to the actual blast radius of decisions.

Key Insight: Effective compliance at scale requires progressively decomposing both architectural and compliance units into smaller, reusable quanta—ultimately separating measurement from validation to return pipeline ownership to teams while maintaining audit integrity.

The article examines how organizations can implement compliance processes within DevOps cultures while maintaining agility. It traces an evolution from manual compliance checklists through pipeline-embedded fitness functions to composition-based approaches using pre-certified container images. The most sophisticated pattern—Point-of-Change Compliance—separates measurement from validation, uses cryptographically signed evidence, and enforces policies at deployment time. Each progressive approach shrinks the unique compliance work per team while reducing bottlenecks and second-order effects like shadow IT. The key architectural insight is that separating concerns in compliance architecture positions organizations to evolve their processes as they scale.

Key Insight: Mandatory code review approval is often a trust band-aid rather than a quality mechanism, and teams can ship faster while maintaining feedback culture by merging PRs immediately and treating reviews as post-hoc conversations.

Ship/Show/Ask is a branching strategy that reconciles Pull Requests with Continuous Integration by categorizing changes into three approaches: Ship (merge directly to mainline), Show (open a PR but merge immediately without waiting for approval), and Ask (open a PR and wait for feedback). The strategy addresses how Pull Requests have eroded the 'ready to ship' mentality of CI, causing delayed integration, stale PRs, and rubber-stamp approvals. The key innovation is the 'Show' option, which captures CI's speed while preserving PR tooling benefits for asynchronous feedback. Teams naturally fall somewhere on the Ship-to-Ask continuum, and the framework encourages consciously choosing the right approach for each change based on novelty, risk, and team trust levels.

Key Insight: A gateway contains foreign API awkwardness to a single place, allowing your application code to work entirely in its own vocabulary while gaining significant testing and maintainability benefits.

Martin Fowler explains the Gateway pattern, which creates a single point of interaction between your code and external systems by translating foreign APIs into terms native to your application. The gateway wraps external services, libraries, or databases, converting their awkward interfaces into convenient ones while containing translation logic in one place. He distinguishes the gateway from similar GoF patterns (Facade, Adapter, Mediator) and connects it to Domain-Driven Design's Anticorruption Layer concept. The pattern provides significant testing benefits by allowing test doubles to be inserted at the connection layer, eliminating slow remote calls during testing.

Key Insight: Professional success and public visibility don't immunize you from anxiety, and reaching a point where you can decline work that makes you miserable is a privilege worth exercising.

Martin Fowler announces his retirement from public speaking, revealing that despite being a successful conference keynote speaker with hundreds of thousands of YouTube views, he experiences severe anxiety and panic attacks before every talk. He describes physical symptoms including racing heart, chest tightness, and overwhelming urges to flee. While he's managed these feelings professionally for years, the COVID pandemic's break from speaking made him realize he doesn't want to return to that stress. He plans to redirect his energy toward writing and helping colleagues communicate their ideas through articles on his website.

Key Insight: The pyramid vs honeycomb testing debate is largely a semantic argument caused by inconsistent terminology, and teams should focus on writing high-quality tests rather than debating their distribution.

Martin Fowler addresses the debate between test pyramid vs honeycomb/trophy approaches to testing portfolios. He argues that the debate is largely muddled because terms like 'unit test' and 'integration test' have no agreed-upon definitions. He traces the history of these terms from waterfall-era isolation testing through Kent Beck's XP usage to the modern sociable/solitary distinction. Fowler suggests that honeycomb advocates criticizing 'unit tests' are specifically targeting solitary (heavily mocked) tests, making the debate somewhat moot since pyramid proponents include both styles. He concludes that the entire discussion is a distraction from what really matters: writing expressive, reliable tests with clear boundaries.

Key Insight: The gap between platform enthusiasm and successful execution can only be bridged by starting small with voluntary adoption, treating platform services as products that must earn developer trust, and never compromising on execution quality even while limiting initial scope.

Internal developer productivity platforms promise to reduce cognitive load and accelerate time to market, but there's a significant execution gap between platform hype and successful implementation. The author argues that building effective platforms requires foundational competencies in business value articulation, product thinking, operational excellence, software engineering, and healthy team structures. Rather than mandating platform adoption, organizations should start small with voluntary adoption, treating platform services as products that must earn developer trust through quality and customer focus. Success depends on maintaining a modest scope while executing with high quality, planning for eventual deprecation, and keeping cognitive load manageable for platform teams.

Key Insight: Numbers only become meaningful when visualized with appropriate context, and muted-spaghetti charts provide an elegant way to show how a single data series compares against many related series.

This post explains how to create muted-spaghetti line charts in R using ggplot2, a visualization technique that shows one highlighted data series against a background of related comparison series. Fowler demonstrates the technique using COVID-19 death rates, showing how Massachusetts data becomes more meaningful when contextualized against all other US states. The key insight is that raw numbers need context to be interpretable. The post includes practical R code for both single charts and faceted grids, with a clever trick of renaming the grouping column to make facets work correctly with background spaghetti lines.

Key Insight: Bitemporal history separates what actually happened from when we learned about it, enabling systems to handle retroactive changes while maintaining an auditable record of how knowledge evolved over time.

Bitemporal history addresses the complexity of tracking property changes over time when retroactive updates occur. The concept distinguishes between 'actual' history (when something truly changed) and 'record' history (when we learned about it). The author uses a payroll example where an employee's salary raise is communicated retroactively, creating discrepancies between what was recorded at the time of payroll and what was actually true. While bitemporal modeling adds significant complexity, it becomes necessary when actions are based on past states that later change retroactively. The pattern can be implemented through bitemporal data structures or event sourcing, with the latter offering more flexibility for different query needs.

Key Insight: Pull requests are valuable for managing untrusted contributions but their popularity has led many teams to adopt them by default when alternative review mechanisms like pair programming would better support continuous integration.

Pull requests are a mechanism designed to implement feature branching and pre-integration reviews, popularized by GitHub for open-source contribution workflows. While they provide convenient tooling for code review and managing contributions from untrusted sources, they come with significant costs including reduced integration frequency, complicated merges, and integration friction. Fowler argues that their value depends heavily on team social structure, and many teams use them by default when they would be better served by alternatives like pair programming or post-integration review. The key insight is that pull requests are not the only way to do code reviews, and for many teams, pre-integration review isn't the best choice.

Key Insight: Code review should be reconceived as an ongoing team practice of refinement triggered by reading code, not just a gate at integration time.

Fowler challenges the narrow view that code review only happens through pull requests, arguing that the most powerful form of code review is perpetual refinement by the entire team. He contends that software's defining characteristic is its malleability, making continuous improvement both possible and necessary. The approach triggers review each time code is read rather than only when it's added, naturally concentrating attention on frequently-used areas. While acknowledging exceptions like security concerns that need targeted review, Fowler argues that teams with self-testing code, continuous integration, and refactoring skills can rely on ongoing refinement as their primary code review strategy.

Key Insight: Developer effectiveness is determined by the speed and simplicity of feedback loops at every level, and organizations must treat developer experience with the same product thinking they apply to customer-facing products.

This article argues that engineering organizations undergoing digital transformations often fail because they neglect developer effectiveness, introducing too many new processes and tools that create friction. Fowler contrasts highly effective environments where developers make incremental progress with low effectiveness environments characterized by blockers, bureaucracy, and 'death by 1,000 cuts.' The key to improvement lies in optimizing feedback loops—both large cycles like deploying to production and micro-feedback loops like running unit tests. Organizations must measure these loops, empower developers to improve them, and eventually scale solutions through platform thinking. Case studies from Spotify and Etsy demonstrate how leading companies have embedded developer effectiveness into their culture with measurable results.

Key Insight: Lies spread by elites and amplified by social media algorithms pose an existential threat to democracy, and society must find ways to impose consequences on those who spread them while protecting legitimate speech.

Written in response to the January 6th Capitol insurrection, Fowler argues that the event was a direct consequence of sustained political lies, particularly Trump's baseless claims about election fraud. He draws historical parallels to the Beer Hall Putsch and early Ku Klux Klan to warn that farcical-seeming events can lead to serious consequences if not confronted. While acknowledging Trump as a symptom rather than root cause, Fowler emphasizes that the broader 'ulceration of lies' in American society poses an ongoing threat to democracy. He calls for consequences for those who spread disinformation, including holding social media platforms to publisher-level responsibility, while acknowledging the difficulty of balancing free speech protections.

Key Insight: Bandcamp has become the ideal platform for music discovery because it combines ethical artist compensation with the ability to sample before committing to a purchase.

Martin Fowler shares his six favorite musical discoveries of 2020, reflecting on his longtime habit of buying four albums per month and his recent shift to purchasing through Bandcamp. He highlights artists spanning jazz, world, and roots music, including GoGo Penguin, You Are Wolf, and Somi. Fowler emphasizes Bandcamp's appeal for both supporting artists directly and sampling music before purchase. The post serves as a personal music recommendation list while acknowledging the sources that led him to these discoveries.

Key Insight: Scaling analytical data requires distributing ownership to domain teams who serve data as products, connected through a self-serve platform that computationally enforces federated governance standards.

Data mesh is a paradigm for managing analytical data at scale through four core principles: domain-oriented decentralized ownership, treating data as a product, self-serve data infrastructure, and federated computational governance. The approach addresses the failures of centralized data lakes and warehouses by distributing data ownership to domain teams closest to the data, while maintaining interoperability through global standards. Rather than extracting data into a central repository, each domain becomes responsible for serving its own analytical data products with quality guarantees. The architecture introduces the 'data product' as its quantum—a self-contained unit combining code, data, and infrastructure that domains can independently deploy and maintain.

Key Insight: Computational notebooks are powerful tools for exploration and documentation, but their strength in encouraging interactivity becomes a liability when mistakenly used as production system components.

Computational notebooks are environments that combine prose documentation with executable code, making them ideal for data science exploration and analysis. Fowler explains how they allow researchers to keep notes, code, and results together in a single document, facilitating iterative exploration. He traces their history from Mathematica in the 1980s through modern tools like Jupyter and R Markdown. While notebooks excel at exploration and report generation, Fowler cautions against using them in production systems, as their structure encourages interactivity at the expense of modularity.

Key Insight: The push to productionize notebooks is a symptom of organizational dysfunction between data science and engineering teams—the solution is cross-functional collaboration and proper software practices, not better notebook tooling.

Fowler argues against deploying data science notebooks directly into production codebases. Notebooks excel at interactive exploration and demos but conflate concerns that should be separated in production systems—storage, visualization, and business logic. The real problem isn't technical but organizational: data scientists and software developers often don't understand each other's needs. The solution is embedding data scientists within delivery teams where they can learn software development practices while developers learn data science basics. Rather than productionizing notebooks, teams should extract the relevant domain logic into structured, testable codebases while building experimentation capabilities into the pipeline itself.

Key Insight: Nature's cycle of predator and prey operates indifferently to human attachments, and sometimes the only way to process loss is through storytelling that gives meaning to meaningless violence.

Martin Fowler recounts the death of his wife Cindy's cat, Goldman Sachs (named for her impressive girth), who was killed by coyotes in their garden. Rather than a straightforward account, Fowler weaves an elaborate fantasy narrative where the cat's demise was orchestrated revenge by a widowed cardinal whose mate Goldie had killed. The piece blends genuine memoir about pet ownership, suburban wildlife, and loss with whimsical storytelling that anthropomorphizes the local animals into conspirators. It's a meditation on nature's violence—how predators become prey—wrapped in dark humor and delivered with Fowler's characteristic wit.

Key Insight: When facing unverified but potentially damaging stories, social media platforms should embrace uncertainty by temporarily dampening spread rather than making premature binary decisions about blocking or allowing.

In response to social media platforms blocking an unverified political story during the 2020 election, Fowler proposes a middle ground between full blocking and unrestricted sharing: temporary dampening. He argues that sensational stories spread faster than investigations can verify them, creating asymmetric harm. Rather than asking 'is this true,' platforms should ask 'can we tell yet if this is a damaging lie?' This approach acknowledges uncertainty rather than demanding binary decisions, and weighs short-term virality against long-term truth.

Key Insight: Google Sheets scripts deserve consideration as a legitimate deployment platform for simple automation tasks, especially when your users aren't programmers—the familiar interface and built-in sharing outweigh the crude development environment.

Fowler describes writing a Google Apps Script for a non-programmer friend to correlate data from Slack and Patreon. He argues that despite programmers' disdain for spreadsheets, Google Sheets provides an excellent deployment platform for simple scripts because users already know the interface, sharing is built-in, and no installation is required. The main technical challenges were OAuth authentication (which he mostly sidestepped) and poor documentation. He advocates for treating spreadsheet scripts with the same design discipline as regular code, separating data sheets from logic and avoiding cell-level manipulation in favor of JavaScript data structures.

Key Insight: Democratic institutions require active defense through voting, and the 2020 election represents a critical moment to repudiate authoritarianism with an undeniable margin.

Martin Fowler makes a direct political appeal urging Americans to vote against Donald Trump in the 2020 election. He argues that Trump's pattern of lies, blocking of oversight, and authoritarian tendencies pose a fundamental threat to democracy. Fowler emphasizes that victory must be by a substantial margin to be undeniable and to signal to the Republican Party that supporting demagogues is electorally catastrophic. He points to the COVID-19 death toll as concrete evidence of the cost of incompetent leadership, comparing U.S. deaths unfavorably to Germany's. The post concludes with a call to vote against both Trump and his enablers as a repudiation of authoritarianism.

Key Insight: Always visualize the underlying distribution before comparing groups by averages, because summary statistics can mask critically important patterns like outliers, bimodal distributions, and inconsistent performance.

The post argues that comparing groups of data using only averages (means) is dangerously misleading because it hides crucial information about the underlying distribution. Using a sales bonus decision as an example, Fowler demonstrates how one executive's seemingly superior 7.9% average actually stems from a single 80% outlier while all other accounts shrank. The article presents several visualization alternatives—strip charts, histograms, density plots, box plots, and violin plots—that reveal the true shape of data distributions. Fowler advocates for always examining distributions before drawing conclusions and suggests median is often more appropriate than mean for central tendency.

Key Insight: The 1953 Iranian coup, though not widely known in the West, established a pattern of American covert intervention that shaped Middle Eastern politics for generations and continues to fuel hostility today.

Fowler reviews 'Coup 53,' a documentary about the 1953 CIA-backed coup that overthrew Iran's democratically elected Prime Minister Mohammad Mosaddegh. The film combines historical narrative with a meta-documentary about finding a lost interview with British intelligence officer Norman Darbyshire, who claimed Britain played the leading role in the coup. While Fowler notes the documentary's reluctance to question Darbyshire's potentially ego-driven account, he finds the core historical story compelling and important. The review emphasizes the coup's lasting consequences: Iran lost a democratic leader and gained decades of autocracy, while America gained lasting hostility and established a pattern of supporting covert regime change.

Key Insight: When you use a tool all day every day, investing significantly more money for genuine comfort improvements is a sound economic decision.

Martin Fowler reviews the Kinesis Advantage2 ergonomic keyboard after three and a half years of daily use. He explains that while the keyboard is marketed for RSI prevention, he bought it purely for typing comfort rather than to address any current injury. The standout features include thumb clusters replacing the spacebar, foot pedals for modifier keys, and extreme customizability. Despite a steep learning curve in the first week, he found the transition worthwhile and can still switch between the Kinesis and regular keyboards without difficulty. He considers the $300+ investment well worth it for something used all day.

Key Insight: The frequency of integration is the most critical decision in branching strategy - higher frequency reduces merge risk, enables refactoring, and correlates with better software delivery performance.

This comprehensive article examines source code branching patterns, arguing that while branching is easy, merging is the hard part that teams must plan for carefully. Fowler presents two main categories of patterns: integration patterns (how developers combine work) and production path patterns (how code reaches deployment). He contrasts Feature Branching with Continuous Integration, presenting research evidence that high-frequency integration correlates with higher software delivery performance. The article advocates for understanding trade-offs in context rather than following any single approach dogmatically, while noting that teams using Continuous Integration typically achieve better outcomes through smaller merges and faster conflict detection.

Key Insight: Feature branches trade early problem detection and refactoring opportunities for deferred merge risk, making their impact directly proportional to how long features take to complete.

Feature branching is a source code pattern where developers work on isolated branches until a feature is complete before merging. While popular in open-source development, this isolation prevents early problem detection and discourages refactoring, which can deteriorate codebase health. The impact depends heavily on feature completion time—teams finishing features in days avoid most problems, while those taking weeks or months face significant integration difficulties. Fowler positions this as a trade-off between merge risk deferral and the benefits of continuous integration.

Key Insight: Dark launching provides a risk-mitigation strategy for assessing real production impact of new features by executing them invisibly alongside existing user flows before public release.

Dark launching is a deployment technique where new back-end functionality is called from production user flows without exposing results to users, allowing teams to assess performance and load impacts before public release. The approach integrates with Keystone Interface patterns to build features invisibly in production, while Feature Flags enable quick rollback if problems emerge. Dark launching also enables parallel running of reimplemented features to verify correctness before switching. The technique works best for features that enhance existing interactions rather than user-initiated actions, where Canary Releases are more appropriate.

Key Insight: Untestable code becomes safer when you minimize its logic, pushing complexity into testable components where bugs can be caught.

The Humble Object pattern addresses the challenge of testing program elements that are inherently difficult or impossible to test automatically. By moving as much logic as possible out of hard-to-test elements into more testable parts of the codebase, developers reduce the risk of bugs hiding in untestable code. User interfaces are a prime example where this pattern applies, as UI controls often lack testing hooks or require complex setup. Patterns like Presentation Model (MVVM) and Passive View implement this principle by keeping UI controls behavior-minimal.

Key Insight: By treating the user interface as the final keystone that reveals a feature, teams can continuously integrate and test complex back-end functionality without exposing incomplete work to users.

The Keystone Interface technique addresses the tension between frequent integration/deployment and not exposing incomplete features to users. Teams build and integrate all back-end code through multiple production releases while withholding only the user interface element that reveals the feature. This approach requires architecture that supports subcutaneous testing, allowing thorough validation without the UI. When the UI can't be reduced to a simple keystone, feature flags can be used, but should be limited to the UI layer to reduce complexity. The technique works best within an overall approach of building products through thin vertical slices.

Key Insight: Eric Evans's lasting contribution to software development was not inventing domain modeling, but creating a shared vocabulary and conceptual framework that moved domain models from paper artifacts into living, evolving code.

Domain-Driven Design is a software development approach that builds rich domain models embedding business processes and rules directly into code. Originated by Eric Evans in his 2003 book, DDD provides a vocabulary for discussing domain modeling, including concepts like Ubiquitous Language, Bounded Contexts, and the Evans Classification of objects. While domain modeling existed before, Evans's contribution was creating a systematic framework and emphasizing that models should live in software and evolve over time, not just exist on paper. The approach is particularly valuable for complex domains and aligns naturally with Extreme Programming practices.

Key Insight: Refactoring large classes requires moving in tiny incremental steps that keep tests passing, starting by analyzing method relationships and extracting from the bottom of the call hierarchy upward.

Clare Sudbery walks through a real-world refactoring of a personal accounting application where the ReconciliationIntro class had grown too large to reason about. The article demonstrates how to break a bloated class into smaller, focused classes (FileLoader, BudgetingMonthService, Communicator, PathSetter, DebugModeSwitcher) using tiny, incremental steps that keep tests passing at all times. The key insight is that refactoring neglect creates a vicious cycle where code becomes increasingly difficult to modify, and the solution is methodical extraction following Kent Beck's advice to 'make the change easy, then make the easy change.'

Key Insight: Pair programming's value lies in accelerating understanding and decision-making, not doubling typing speed.

Pair Programming involves two developers working together at a single workstation, discussing each step as they write code. Fowler argues that the practice only seems wasteful if you believe typing is the hard part of programming. In reality, programming requires constant understanding-building and decision-making, where two minds work faster than one. While the intensive social contact may not suit everyone, many who expected to dislike it have come to appreciate it. The practice is a skill that can be done poorly, best learned from experienced practitioners.

Key Insight: The primary value of video calls over audio is seeing the reactions of all participants, not just the speaker, which requires gallery view and individual connections rather than conference room setups.

Martin Fowler shares practical guidelines for effective video calls based on Thoughtworks' transition from telephone to video meetings around 2011-2012, prompted by the Covid-19 pandemic forcing more people into remote work. The post emphasizes that audio quality matters more than video quality, and that seeing participants' faces and reactions is the key advantage of video over audio-only calls. He advocates for gallery view over speaker view, proper camera positioning, muting when not speaking, and using chat as a parallel communication channel. The advice balances professionalism with humanity, welcoming brief appearances by children and pets while maintaining meeting effectiveness.

Key Insight: Organizational resilience in crisis comes from decentralized decision-making empowered by trust and communication networks built during stable times.

Martin Fowler provides an update on how Thoughtworks is responding to the Covid-19 pandemic, outlining their governing priorities: employee health, client support, slowing community spread, and empowering regional teams. He describes the reopening of Chinese offices with safety measures like masks, temperature checks, and reduced capacity. The piece details how the company is adapting to remote work, including moving major events online and helping clients transition. Fowler reflects on the economic uncertainty ahead and how organizational resilience depends on decentralized decision-making and trust built during good times. He closes with cautious optimism that the world is finally taking the virus seriously enough to prevent worse outcomes.

Key Insight: Architectural decisions about resilience, flexibility, and system decomposition cannot be made soundly without understanding the business value each component generates and the cost of its failure.

The authors argue that software architects consistently overlook business value when making technical decisions, creating a major blind spot in architectural assessments. Through multiple case studies, they demonstrate how understanding revenue flows, failure costs, and business priorities should drive decisions about fault tolerance, microservice decomposition, and cross-functional requirements. They advocate for value stream mapping that extends into IT systems, tiered service levels based on business impact, and monitoring that captures business metrics alongside technical ones. The piece concludes that technical leaders must develop business acumen through ongoing interaction with business stakeholders, not just technical training.

Key Insight: Organizations built around agile principles—embracing uncertainty, decentralized decision-making, and trust—are better equipped to handle crises that force rapid operational changes like remote work.

Martin Fowler reflects on Thoughtworks' experience responding to the early Covid-19 outbreak, sharing practical lessons from their China offices which were forced into remote-first operation. The company found that most teams adapted well, with 80% reporting equal or improved productivity when working from home. Fowler emphasizes that successful remote work requires proper infrastructure—good equipment, high-speed internet, collaboration tools, and security access. He argues that Thoughtworks' agile culture of embracing uncertainty and decentralized decision-making helped them cope effectively. The piece concludes with hope that the crisis will encourage more organizations to seriously adopt remote work and digital tools.

Key Insight: Product-service partnerships optimize for output metrics and risk management rather than customer outcomes, and the rise of cloud computing makes navigating these arrangements an unavoidable concern for all software organizations.

Product-service partnerships between software vendors and service providers are ubiquitous arrangements where vendors build products while service providers handle installation, configuration, and customization. Product vendors avoid building their own services divisions due to lower margins, delivery risk, and revenue recognition complications. These partnerships involve dedicated organizational structures, certification requirements, and sometimes commissions, though they raise conflict-of-interest concerns when service providers give advisory recommendations. The rise of cloud computing has made such partnerships unavoidable even for custom software developers, creating new financial incentive complexities around usage-based pricing models.

Key Insight: Focusing teams on outcomes rather than output fundamentally changes what people think about and optimize for, which matters more than precise measurement.

Fowler argues that software teams should be evaluated by outcomes (like increased sales or reduced support calls) rather than output (features delivered or code written). He contends that unused features represent not just wasted effort but actively harm the codebase by adding bloat. While acknowledging that outcomes are harder to apportion to specific teams, he maintains that measuring output is equally problematic and more importantly leads to optimizing for the wrong thing. The key insight is that focusing on outcomes changes what people think about and prioritize, regardless of measurement precision.

Key Insight: Product-mode organizations must deliberately adapt their operating model and leadership approach when programs require cross-team coordination, accepting temporary constraints on team autonomy to deliver holistic customer value.

Product-mode organizations with autonomous teams face unique challenges when initiatives require cross-team coordination (programs). Using a fictional fintech example, the article illustrates how preserving team autonomy at all costs led to unmanaged dependencies, poor communication, and missed delivery targets. The authors argue that programs require deliberate changes to operating models, including upfront kickoff workshops, adapted leadership styles, proactive dependency management through techniques like walking skeletons, and strong communication strategies. While this may temporarily challenge the autonomous culture, having a dedicated 'solution champion' role focused on strategic coordination—distinct from tactical delivery—is essential for program success.

Key Insight: Pair programming's challenges—exhaustion, power dynamics, vulnerability—are not reasons to avoid it but opportunities to build the communication and collaboration skills that distinguish highly effective teams.

This comprehensive guide argues that pair programming—two developers working together at one machine—is a crucial practice for creating high-quality, maintainable software. The authors trace the practice from the ENIAC programmers through Kent Beck's formalization in Extreme Programming, then provide detailed guidance on styles (driver-navigator, ping pong, strong-style), logistics (time management, rotations, remote setup), and the broader concept of 'pair development' that extends beyond just coding. They acknowledge significant challenges including exhaustion, power dynamics, and organizational resistance, but argue these difficulties are worthwhile because working through them builds the very skills—communication, feedback, vulnerability, empathy—that make teams effective.

Key Insight: Quality media communities around niche hobbies can provide both practical value through in-depth content and social value through positive community spaces.

Martin Fowler recommends Heavy Cardboard, a media channel dedicated to complex board games run by Edward Uhler. The channel offers in-depth podcast reviews and live-streamed gameplay videos on YouTube, with Edward's rule teachings being particularly valuable for learning new games. Fowler became a patron and enjoys the patron-only Slack community. When Edward moved near Fowler's home in Massachusetts, Fowler began participating in the game group and appearing in videos and podcast episodes, including teaching Brass Birmingham and reviewing several games.

Key Insight: Automated testing, despite its power, shares a fundamental limitation with all scripted testing: it can only catch bugs you already know to look for, making exploratory testing an essential complement.

Exploratory testing is a testing approach that emphasizes learning, discovery, and rapid iteration rather than following pre-written test scripts. While Fowler strongly advocates for automated testing, he argues that scripted testing—whether manual or automated—can only verify known conditions and cannot discover unknown behaviors. Exploratory testing complements automated tests by probing the boundaries of what's tested, finding failures that can be added to scripts and uncovering unexpected behaviors. The practice requires skilled, curious testers who can generate hypotheses and new tests during time-boxed sessions. Fowler considers it a red flag when teams rely solely on automated testing without any exploratory testing.

Key Insight: Waterfall's fatal flaw is not sequential phases per se, but the predictive planning mindset it enforces—assuming stable requirements in a domain where delivering working software is the primary mechanism for discovering what's actually needed.

Fowler examines the origins and meaning of 'waterfall' in software development, tracing it to Winston Royce's 1970 paper while noting the term itself never appeared there. He defines waterfall's essential characteristic as decomposing effort into phases based on activity (analysis, design, coding, testing) rather than iteratively building features. Fowler argues waterfall is problematic because testing and integration—the hardest phases to predict—come last, forcing a predictive planning style that doesn't accommodate the inevitable requirement changes. He clarifies that while agile requires iteration, iterative development alone isn't sufficient for agility—adaptive planning and focus on business value are essential.

Key Insight: Continuous Delivery for Machine Learning requires treating code, data, and models as three distinct but interconnected axes of change, each needing specialized versioning, testing, and deployment strategies while maintaining the core CD principle that software should always be in a releasable state.

This article extends Continuous Delivery principles to Machine Learning systems, addressing the unique challenges of managing code, data, and models as three axes of change. The authors define CD4ML as a software engineering approach where cross-functional teams produce ML applications in small, safe increments that can be reproduced and reliably released at any time. Using a sales forecasting application as an example, they walk through technical components including data versioning, reproducible model training with DVC, model serving patterns, testing strategies, experiment tracking with MLflow, deployment orchestration with GoCD, and production monitoring. The article emphasizes that while ML model outputs may be non-deterministic, the release process itself should be reliable and automated, creating feedback loops for continuous improvement.

Key Insight: Strategic hobby board games represent a rich, serious intellectual pursuit distinct from mass-market games, worthy of detailed analysis and critical evaluation of their design mechanisms.

Martin Fowler introduces his passion for strategic hobby board games, distinguishing them from mass-market games like Monopoly. He maintains an active blog on BoardGameGeek called 'Martin's Seventh Decade' where he writes detailed reviews, session reports, and analytical pieces about modern board games. The page serves as an index to his extensive BoardGameGeek writing, covering topics from game reviews to theoretical discussions about game design concepts. His interests center on economic and route-building games like Brass, Age of Steam, and Power Grid, with particular attention to game mechanisms and design philosophy.

Key Insight: Lock-in decisions should be evaluated using simple models that weigh switching cost against unique utility, and the cost of reducing lock-in against the probability-weighted cost of the lock-in itself - the goal is optimizing total cost, not eliminating lock-in.

Martin Fowler argues that lock-in is not a binary evil to be avoided at all costs, but a nuanced trade-off that architects must carefully evaluate. He identifies multiple dimensions of lock-in (vendor, product, version, architecture, platform, skills, legal, and mental) and demonstrates that open source is not a magic cure since it only addresses vendor lock-in. Using simple two-by-two matrices, he shows that lock-in can be acceptable when it provides unique utility, and that the cost of avoiding lock-in (complexity, effort, underutilization, new lock-ins) often exceeds the expected cost of the lock-in itself. The key insight is finding the optimal investment point where total cost is minimized, rather than striving for zero switching cost.

Key Insight: True content value lies not in launch-day traffic spikes but in becoming evergreen—consistently useful reference material that maintains readership over years.

This post is an internal review of martinfowler.com's traffic analytics for 2014, examining which content performs best over time. Fowler introduces the concept of 'evergreen' articles—those that maintain consistent readership long after publication—and analyzes 86 URLs meeting this criteria. The microservices article he co-authored with James Lewis stands out as having catalyzed industry-wide interest in the term. Notably, infodecks (a content format he invested significant effort in) failed to produce any evergreen content, while long-form articles showed better staying power than short posts. The analysis reveals that word count shows no correlation with popularity, countering assumptions about modern attention spans.

Key Insight: The true measure of technical writing success is not initial traffic but sustained readership over years, and collaborative publishing with other authors can be more impactful than solo writing.

Martin Fowler presents a comprehensive traffic analysis of martinfowler.com for 2018, examining overall site growth, the concept of 'evergreen' articles that maintain sustained readership, and the relative success of articles written by guest authors versus himself. The site shows steady growth to over 8 million page views annually, with clear weekday/weekend traffic patterns. However, he notes a troubling plateau in new popular articles since 2016, coinciding with his focus on the refactoring book. The analysis reveals that guest-authored articles actually outperform his own on average, validating his editorial collaboration strategy. Many of the site's most popular pages are over a decade old, demonstrating the long-term value of quality technical content.

Key Insight: Micro frontends enable frontend scalability through independent deployability and team autonomy, but require organizational maturity to manage the inherent tradeoffs of distributed architectures.

Micro frontends extend the microservices pattern to frontend development, allowing organizations to decompose monolithic frontend codebases into smaller, independently deployable applications that can be developed by autonomous teams. The article defines micro frontends as 'independently deliverable frontend applications composed into a greater whole' and explores various integration approaches including server-side composition, build-time integration, iframes, JavaScript runtime integration, and Web Components. Fowler emphasizes that the key benefits mirror those of backend microservices: incremental upgrades, simpler codebases, independent deployment, and team autonomy. However, the pattern comes with tradeoffs including potential dependency duplication, environment consistency challenges, and increased operational complexity that organizations must be mature enough to handle.

Key Insight: Elite software delivery teams achieve both speed and stability—deploying many times daily with lower failure rates than teams that deploy monthly, proving that velocity and quality are complementary rather than competing goals.

The State of DevOps Report is an annual survey-based study by Nicole Forsgren, Jez Humble, and Gene Kim that uses statistical analysis to identify effective software delivery practices. The report surveys tens of thousands of developers using carefully designed questions that measure constructs indirectly rather than asking direct questions that would yield unreliable answers. A key finding is that organizations cluster into four performance tiers (elite, high, medium, low), with elite performers deploying multiple times daily while low performers take months. Crucially, high throughput does not sacrifice stability—elite teams have lower failure rates and faster recovery times than their slower counterparts.

Key Insight: Internal software quality doesn't trade off against cost—it reduces cost, because cruft accumulates so quickly that the 'payback period' for quality investments is measured in weeks, not years.

Fowler argues that the conventional trade-off between quality and cost doesn't apply to internal software quality (code architecture, modularity, naming). While external quality (UI, defects) follows normal economics, internal quality actually reduces long-term costs because cruft accumulates rapidly and slows development. He explains that even the best teams create cruft since software projects involve constant learning and uncertainty, but skilled teams minimize and remove it through practices like refactoring, automated testing, and continuous integration. The key insight is that poor internal quality slows developers within weeks, not months or years, making the 'trade-off period' remarkably short.

Key Insight: The true power of the technical debt metaphor lies not in justifying shortcuts but in providing a framework for prioritizing cleanup—focus ruthlessly on frequently-changed code while leaving stable cruft alone.

Technical debt is a metaphor coined by Ward Cunningham that frames software cruft—deficiencies in internal quality—as a financial obligation where extra effort on features represents interest payments. The metaphor helps teams decide which cruft to address by considering how often code areas are modified; frequently-changed code demands zero tolerance for cruft while stable ugly code can be ignored. Fowler warns against using debt as justification for neglecting quality, noting that teams often 'max out their credit cards' while still delivering late. The best approach is gradual principal repayment: spending extra time on each feature to remove some cruft, naturally focusing effort where it matters most.

Key Insight: Applying domain-driven design to data architecture - where domains own and serve their data as products rather than feeding a centralized platform - solves the scalability and organizational failures that have plagued three generations of enterprise data platforms.

The article argues that centralized, monolithic data lake architectures have consistently failed enterprises across three generations of data platforms. Fowler proposes 'data mesh' as a paradigm shift: distributing data ownership to domain teams who treat their datasets as products, supported by self-serve infrastructure. The key insight is applying domain-driven design principles that succeeded in operational microservices to the data domain. Rather than flowing data into a central lake owned by specialized data engineers, domains should host and serve their own data products with clear ownership, discoverability, and quality guarantees.

Key Insight: Observability code should be treated as a first-class architectural concern that speaks the domain's language, not as low-level plumbing scattered throughout business logic.

The article argues that while observability is critical for modern distributed systems, adding instrumentation directly to domain code creates cluttered, hard-to-maintain codebases. The solution is Domain-Oriented Observability, implemented through the Domain Probe pattern—a class that presents a high-level, domain-focused instrumentation API while encapsulating the low-level details of logging, metrics, and analytics systems. This separation keeps domain code clean and readable while making observability testable. The pattern also addresses how to inject contextual metadata (request IDs, user identifiers) without polluting domain classes with technical concerns.

Key Insight: Vendor lock-in decisions should factor in the opportunity cost of slower delivery, not just the future migration cost—sometimes lock-in is the profitable choice.

The author challenges the common fear of vendor lock-in by reframing how we should calculate its true cost. Rather than viewing lock-in purely as migration cost, the formula should subtract opportunity gain—the business benefits from faster time to market that vendor-specific services provide. The post argues that fully portable solutions often sacrifice speed and managed services that could give competitive advantage. Using event-driven architecture as an example, the author shows how vendor-specific services like Kinesis offer immediate productivity gains versus vendor-agnostic alternatives like Kafka that require more setup time. The key is to focus on making systems adaptable to reduce future migration cost rather than avoiding lock-in entirely.

Key Insight: The second edition modernizes refactoring concepts by generalizing them beyond strict object-orientation and updating terminology to reflect how software development has evolved since the original 1999 publication.

Martin Fowler details the changes between the first and second editions of his seminal book Refactoring. The second edition maintains the same overall structure but updates the opening example domain, overhauls the principles and smells chapters, and rewrites the testing chapter for JavaScript instead of Java. The catalog of refactorings has been significantly revised: of the original 68, many were kept, some replaced with generalized versions (reflecting less object-centric thinking), and several dropped entirely. Fifteen completely new refactorings were added. Tangential chapters and 'big refactorings' were dropped in favor of web essays.

Key Insight: Successfully extracting a service from a monolith requires breaking up the shared database, not just the code, and the organizational challenge of migrating all clients is often harder than the technical work.

This article presents a systematic nine-step pattern for extracting a data-rich service from a monolith while minimizing disruption to consumers. Using a catalog system example where product pricing is separated from core product functionality, Fowler's colleague outlines how to identify boundaries, create logical separations within the monolith first, migrate data to new tables, build the new service, migrate clients, and finally clean up the monolith. The approach emphasizes two guiding principles: maintaining a single write copy of data throughout the transition to avoid write conflicts, and completing all steps atomically to avoid leaving the architecture in a worse state than before.

Key Insight: True agile requires teams to choose and evolve their own processes while maintaining technical excellence - imposing standardized 'agile' methods from outside fundamentally betrays the movement's core values.

Fowler argues that while agile has achieved mainstream acceptance, much of what passes for agile today is 'faux-agile' that betrays its core values. He identifies three major problems: the Agile Industrial Complex imposing standardized methods on teams, neglect of technical excellence at agile conferences and in practice, and the continued use of project-based thinking over product-oriented organization. Drawing on Frederick Taylor's harmful legacy of separating planning from execution, Fowler emphasizes that teams must choose and evolve their own processes. He finds hope in how the original manifesto authors refused special authority, allowing the community to grow more diverse and tackle unforeseen challenges.

Key Insight: When automating workflows with unfamiliar tools, minimize exposure to problematic technologies by delegating as much logic as possible to languages you know well.

Martin Fowler shares a practical solution for batch-exporting OmniGraffle diagrams to web-friendly formats using a combination of AppleScript and Ruby. He explains that while exporting one or two diagrams manually is manageable, having a dozen or more makes scripting worthwhile. The post documents his approach of keeping AppleScript minimal (just the export functionality) while handling file iteration and update logic in Ruby. He notes that Omni Group is developing a JavaScript automation environment, but export functionality wasn't available there yet. The solution works around a permission error quirk by opening files via command line rather than AppleScript.

Key Insight: A book's true value isn't measured by immediate reception but by whether it continues to help people learn the craft years and decades later.

Martin Fowler announces the second edition of his influential Refactoring book, explaining the two-year writing process and key changes from the original 1999 edition. The new edition shifts away from a purely class-centered view of code structure to accommodate modern programming practices including first-class functions. Examples are rewritten in JavaScript rather than Java to better demonstrate refactoring outside class contexts. The book is published as a 'web-first' work, where the canonical version is a website with additional material, while the print and ebook versions contain a curated subset. Fowler candidly acknowledges that most readers familiar with the first edition will likely be disappointed due to loss aversion and mismatched expectations.

Key Insight: Serverless architectures trade operational control for reduced costs and faster iteration, making them most valuable when the economics of automatic, fine-grained scaling outweigh the costs of vendor dependency and distributed system complexity.

Serverless architecture encompasses two overlapping concepts: Backend as a Service (BaaS), where applications rely on third-party cloud services for server-side logic, and Functions as a Service (FaaS), where custom code runs in ephemeral, event-triggered containers managed entirely by cloud providers. The article argues that while Serverless offers compelling benefits—reduced operational costs, automatic scaling, faster time to market, and simplified deployment—it comes with significant trade-offs including vendor lock-in, testing complexity, cold start latency, and the loss of in-server state. Fowler emphasizes that Serverless is not a universal solution but rather another tool in the architectural toolkit, best suited for event-driven workloads, inconsistent traffic patterns, and teams prioritizing rapid experimentation over operational control.

Key Insight: Successful monolith decomposition requires atomic evolutionary steps that always leave the system in a better state, prioritizing operational readiness and data decoupling over premature service granularity.

This article provides a comprehensive guide for decomposing monolithic systems into microservices, emphasizing that the journey requires careful planning and operational readiness. Fowler and co-author Zhamak Dehghani recommend starting with simple, decoupled edge services to build operational maturity before tackling core capabilities. The key strategies include minimizing dependencies back to the monolith, splitting sticky capabilities early, decoupling data along with services, and prioritizing capabilities that matter most to the business. The authors strongly advocate for rewriting capabilities rather than extracting existing code, and warn against creating too-small services prematurely. Every migration step should be atomic and leave the architecture in a better state.

Key Insight: Agile fluency is not about reaching the highest level but about choosing the right zone for your context and making the organizational investments required to actually achieve it.

The Agile Fluency Model describes four distinct zones teams progress through as they develop agile capabilities: Focusing (business value awareness), Delivering (technical excellence enabling frequent releases), Optimizing (market understanding and autonomous decision-making), and Strengthening (organizational contribution). Unlike maturity models where more is always better, each zone represents a valid choice with specific benefits, investments, and trade-offs. The authors emphasize that fluency is a team trait developed through deliberate practice over months or years, and that organizational support and investment are critical—teams cannot achieve fluency without proper backing from management. The model serves as a diagnostic tool to align expectations, identify systemic blockers, and guide conversations about agile adoption.

Key Insight: Effective platforms reduce backlog coupling through genuine self-service while remaining compelling enough that teams choose to use them rather than building alternatives.

Fowler argues that effective digital platforms must be self-service, compelling internal products that reduce 'backlog coupling' - the coordination overhead that occurs when delivery teams depend on centralized operations teams. He contrasts a failed 'superficial private cloud' approach (where self-service was limited to provisioning locked-down VMs while everything else required tickets) with successful autonomous approaches. However, he notes that full autonomy creates technology diversification drag, requiring teams to research and maintain their own infrastructure choices. The solution is treating platforms as compelling internal products that teams choose to use rather than mandated standards.

Key Insight: A well-structured test pyramid with many fast unit tests, targeted integration tests, and minimal end-to-end tests enables teams to move quickly with confidence while keeping maintenance costs low.

This comprehensive guide explains the test pyramid metaphor for structuring automated test suites, arguing that teams should write many fast unit tests, fewer integration tests, and minimal end-to-end tests. The article walks through practical implementations of each test type using a Spring Boot microservice example, covering unit tests with mocks, database and API integration tests, consumer-driven contract tests with Pact, and UI/end-to-end tests with Selenium. It emphasizes that automated testing enables continuous delivery and fast feedback loops, while warning against common pitfalls like test duplication, over-reliance on slow end-to-end tests, and getting too attached to terminology debates.

Key Insight: Stable, long-lived teams organized around business capabilities and empowered to solve problems iteratively will outperform temporary project teams optimized for delivering predefined scope.

The article argues that organizing software development around long-lived product teams rather than temporary projects leads to better business outcomes. Product-mode teams are funded continuously to solve business problems rather than deliver predefined scope, combining ideate-build-run responsibilities in a single unit. This approach enables faster response to market changes, better knowledge retention, improved architectural integrity, and true iteration based on real feedback. While challenges exist around staff utilization and potential new silos, the benefits of responsiveness and higher benefits realization make product-mode more effective for modern digital businesses.

Key Insight: Integration testing is most effective when narrowly scoped to test only the integration code against faithful test doubles, rather than requiring full end-to-end system tests with live services.

Martin Fowler clarifies the confused terminology around 'integration testing,' distinguishing between two fundamentally different approaches. Historically, integration tests meant combining separately developed modules and testing them together as a system. However, the 2010s perspective separates two concerns: testing that modules work together correctly, and testing that a complete system behaves as expected. Fowler advocates for 'narrow integration tests' that use test doubles to verify integration behavior without requiring live services. This approach, combined with contract tests, can eliminate the need for broad end-to-end testing while providing faster feedback in deployment pipelines.

Key Insight: As AI systems increasingly make consequential judgments, we face a critical gap: Machine Learning can teach systems to find answers, but we haven't developed Machine Justification to make them explain their reasoning.

Fowler reflects on the gap between AI's ability to produce answers and its inability to explain reasoning. While Machine Learning has advanced impressively—exemplified by AlphaGo teaching itself to play Go better than humans—these systems cannot articulate their strategies. Fowler argues that 'Machine Justification' (explaining AI reasoning) is a critical unsolved problem, especially as AI makes consequential decisions in areas like legal judgments and credit scoring. He predicts a new role will emerge for programmers who deduce the theory underlying AI decisions, and emphasizes that the best use of computers lies in human-AI collaboration that leverages each party's strengths.

Key Insight: Two games sharing common ancestry can coexist in a collection when they serve different accessibility needs despite similar core mechanics.

This post compares San Juan and Race for the Galaxy, two card games that share a common origin as card game adaptations inspired by Puerto Rico. Both games use hand management and tableau building mechanics where players build cards by discarding others, gaining special powers and victory points. The key difference is that Race is deeper and more complex, using an icon system that some find efficient once learned but others find off-putting. Fowler concludes that both games have merit: Race offers greater depth while San Juan is more accessible for teaching new players.

Key Insight: Feature toggles are not a monolithic technique but a family of patterns requiring different management strategies based on their longevity and dynamism, and teams who fail to recognize these distinctions will accumulate technical debt.

Feature toggles are a powerful technique for modifying system behavior without changing code, enabling teams to ship alternative codepaths and choose between them at runtime. The article categorizes toggles into four types based on longevity and dynamism: Release Toggles for trunk-based development, Experiment Toggles for A/B testing, Ops Toggles for operational control, and Permissioning Toggles for user-specific features. Fowler emphasizes that different toggle categories require different management approaches and that teams should treat toggles as inventory with carrying costs. The piece provides detailed implementation patterns including decoupling decision points from decision logic, using inversion of control, and avoiding scattered conditionals through strategy patterns.

Key Insight: Architecture in the agile era must evolve continuously through small changes and feedback loops rather than being fixed upfront, making adaptability itself an architectural goal.

Fowler introduces the concept of evolutionary architecture as a necessary response to agile development's embrace of changing requirements. He argues that the traditional approach of completing architecture before coding, inspired by construction, is incompatible with modern software development's need for flexibility. Instead, architecture should be a continuous effort that works alongside programming, reacting to both changing requirements and feedback. The book by Ford, Parsons, and Kua provides a roadmap for this approach, emphasizing fitness functions, Continuous Delivery, and Conway's Law as key enablers.

Key Insight: A company built on unconventional values can grow and thrive, but the real test comes when those values must survive under conventional ownership.

Martin Fowler announces that Thoughtworks founder Roy Singham has sold the company to Apax Funds, a London-based private equity firm. Roy's increasing focus on activist work and the impossibility of creating a tax-efficient post-Roy ownership structure made the sale inevitable. Fowler reflects on Thoughtworks' unique culture of hiring capable technologists who embrace open source and agile methods, contrasting it with traditional IT services firms. He expresses cautious optimism that Apax recognizes what makes Thoughtworks unique and wants to preserve its people-centered approach. The post frames the acquisition as the next phase of 'Roy's social experiment' to prove a company can succeed with unconventional values under conventional ownership.

Key Insight: Test Impact Analysis transforms the testing bottleneck by using code coverage data to create intelligent maps between production code and tests, enabling teams to run only the tests that matter for each change.

Test Impact Analysis (TIA) is a technique for reducing test execution time by identifying which tests are affected by code changes, rather than running all tests. The article traces TIA's evolution from Microsoft's decade-long development efforts to DIY solutions using code coverage tools. By mapping production code to the tests that exercise it, teams can run only relevant tests per commit, dramatically reducing CI times while maintaining confidence. The author presents both enterprise solutions like Microsoft's TFS integration and a simpler approach using standard code coverage tools that any team can implement.

Key Insight: The modern architect's value lies not in making technical decisions but in bridging the gap between executive strategy and technical reality, requiring continuous movement between organizational levels to align technology with business goals and remove systemic blockers.

Fowler argues that the traditional architect role of making design decisions and drawing diagrams is obsolete—those tasks belong to developers and tools. Modern architects must instead 'ride the elevator' between the technical engine room and executive penthouse, translating between business strategy and technical implementation. This requires engaging with organizational change, selling architecture as 'options' that defer decisions, and ensuring feedback loops validate architectural choices. The architect's unique value lies in combining deep technical understanding with the ability to influence organizational structures and remove systemic blockers at the appropriate management level.

Key Insight: Strong thematic integration in game design makes rules more coherent and memorable, and a game's true depth can only be judged through extensive repeated play rather than first impressions.

Fowler compares two Eurogames—Viticulture and The Gallerist—that share a strong business production theme but differ significantly in weight and randomness. Both use worker-placement-style mechanics on shared boards centered around long production chains (winemaking and art dealing respectively). Viticulture is lighter with more card-driven randomness, while The Gallerist is heavier with interlocking multi-step mechanics that reward repeated play. Both feature outstanding production quality and strong thematic integration that makes rules more coherent. Fowler argues The Gallerist's depth reveals itself over many plays, and he values both games for scratching the same thematic itch at different levels of mental effort.

Key Insight: Production systems reveal quality issues that no amount of pre-release testing can anticipate, making production monitoring not a substitute for testing but an essential complement that grounds QA in real-world behavior.

The article argues that QA should extend beyond pre-release testing to include systematic monitoring of production systems. Teams should identify critical success indicators tied to business outcomes and build feedback mechanisms using logging, metrics, and alerting to detect and respond to real-world issues. The author illustrates this through a job application system where iterative improvements to monitoring revealed email delivery problems that were impossible to predict through testing alone. While production QA can replace some expensive pre-production testing, it requires a foundation of automated testing and continuous delivery practices to be effective.

Key Insight: A single line of weak configuration code can create an attack chain from dictionary-crackable secrets through session forgery to full remote code execution, making secure defaults and clear documentation essential framework responsibilities.

This article demonstrates how a weak session secret in a Sinatra web application can be exploited to gain complete server access. The author traces the full attack chain: cracking a dictionary-based session secret using Hashcat on AWS GPU instances (43 seconds to crack 'super secret'), forging admin session cookies, and ultimately achieving remote code execution through Ruby's Marshal deserialization. The post concludes with practical prevention advice for both application developers (use CSPRNGs, environment variables, secret management tools) and framework authors (secure defaults, clear documentation, input validation).

Key Insight: Self-encapsulation is usually unnecessary overhead for small classes, but becomes valuable when setters contain logic or inheritance requires override hooks—and often the need for it signals you should extract a new class instead.

Self-encapsulation extends the principle of data encapsulation by requiring that even internal access to object fields go through accessor methods, not just external access. Fowler explains the concept with Java examples showing the difference between standard encapsulation and self-encapsulation. While some organizations have mandated self-encapsulation, Fowler takes a pragmatic stance: most of the time it adds unnecessary ceremony since classes are typically small and accessors are simple. However, he acknowledges specific cases where self-encapsulation proves valuable, particularly when setters contain logic or when working with inheritance hierarchies where accessors serve as override hooks.

Key Insight: First-class functions and closures can emulate classical objects through the Function As Object pattern, but having explicit class syntax alongside first-class functions gives developers the best of both paradigms.

Martin Fowler explains how first-class functions and closures can be used to create objects without explicit class syntax, a pattern called Function As Object. The constructor function returns a hashmap of methods that capture state in closures, providing data encapsulation. He walks through a JavaScript example showing how fields become local variables, methods become nested functions, and the returned hashmap defines the public interface. While acknowledging this pattern demonstrates classes aren't strictly necessary, Fowler personally prefers having both first-class functions and first-class classes, favoring ES6's class syntax.

Key Insight: The term 'event-driven' conflates four fundamentally different patterns—Event Notification, Event-Carried State Transfer, Event Sourcing, and CQRS—and this confusion is the root cause of many failed implementations.

Martin Fowler clarifies that 'event-driven' architecture actually encompasses four distinct patterns that are often conflated: Event Notification, Event-Carried State Transfer, Event Sourcing, and CQRS. Event Notification provides loose coupling but can obscure logical flows. Event-Carried State Transfer improves resilience and reduces latency by distributing state copies. Event Sourcing treats the event log as the source of truth, similar to version control systems. Fowler notes that confusing these patterns leads to misdiagnosis when projects fail, and cautions that each pattern has appropriate contexts where it excels and others where it causes problems.

Key Insight: When production complexity exceeds what pre-production environments can replicate, extending automated testing into production via synthetic monitoring becomes essential for detecting real business failures.

Synthetic monitoring runs automated tests against live production systems on a regular schedule to detect business requirement failures in real-time. The technique addresses the challenge of testing microservices environments where pre-production cannot replicate exact production version combinations. By shifting focus from Mean-Time-Between-Failures to Mean-Time-To-Recovery, teams can extend testability into production. The article illustrates this with a car marketplace example running Selenium tests every 5 minutes against production, using parameters to exclude test traffic from analytics. Broad stack tests from the top of the test pyramid are well-suited for this approach.

Key Insight: True Continuous Integration is a discipline about keeping all developers synchronized on a shared mainline, not a category of tooling—and most teams who think they practice it actually don't.

Fowler presents Jez Humble's simple three-question test for genuine Continuous Integration, revealing that most teams who claim to practice CI actually don't. The test asks: does everyone commit daily to a shared mainline, does each commit trigger automated builds/tests, and when builds fail, are they fixed within ten minutes? At conferences, most hands go up initially but only a few remain after all three questions. Fowler argues that running CI tools on feature branches is 'CI theater' that misses the point—true CI is about keeping everyone's code synchronized, not about tooling.

Key Insight: Security is not a feature to be bolted on later but a fundamental discipline requiring systematic distrust of all external input and rigorous application of defensive coding practices at every layer of the stack.

This comprehensive guide covers fundamental web security practices that every developer should implement. Fowler and colleagues argue that security is often deprioritized until breaches occur, yet most vulnerabilities stem from predictable, preventable mistakes. The article walks through essential defensive techniques: validating and rejecting unexpected input, properly encoding output to prevent XSS, using parameterized queries to prevent SQL injection, enforcing HTTPS everywhere, hashing passwords with proper salts and slow algorithms, implementing secure session management, and building robust authorization systems. The core philosophy is 'trust nothing'—every input from browsers, users, and even upstream services should be treated as potentially malicious.

Key Insight: If you own or are buying Dominion, be aware of the second edition upgrade and grab the update packs while they're still available.

Martin Fowler shares news about the second edition of the Dominion board game, which updates the base game and Intrigue expansion with replacement cards. He recommends new buyers get the second edition and existing owners purchase the $12 update packs while they're still available. The post provides practical purchasing advice and links to Amazon for the various editions and update packs.

Key Insight: Extract functions not based on length or reuse, but whenever there's a gap between what code does and how it does it—then name the function after the 'what'.

Fowler argues that the right question about function length isn't about line counts or reuse, but about separating intention from implementation. If you need to spend effort figuring out what code does, extract it into a well-named function. He advocates for very small functions—typically just a few lines—noting that half the methods in his own codebase are two lines or less. Performance concerns about function calls are largely outdated, and the approach only works with careful attention to naming.

Key Insight: When APIs provide more precision than their names suggest—dates that are really instants, decimals that are really approximations—the hidden precision creates subtle bugs that only surface at the worst times.

Hidden precision occurs when data contains more precision than expected, leading to subtle bugs. The post illustrates this with two common examples: date/time handling where creating a 'date' actually creates an instant at midnight, causing range checks to fail unexpectedly, and floating point arithmetic where values like 0.10 don't represent exactly, causing sums to miss expected thresholds. Fowler argues these issues stem from poor naming and modeling in APIs. The solution for money is to use integers representing the smallest currency unit, while floating point comparisons generally require explicit precision tolerances.

Key Insight: A graphic novel about computing pioneers can be both genuinely entertaining and historically informative, making it an ideal diversion for technically-minded readers.

Fowler breaks his rule against book reviews to recommend 'The Thrilling Adventures of Lovelace and Babbage' by Sydney Padua. The graphic novel combines entertaining steampunk alternate history with genuine Victorian-era computing history. After depicting the real collaboration between Ada Lovelace and Charles Babbage, the book enters a pocket universe where Lovelace survives and they complete the Analytical Engine. Fowler particularly praises the extensive footnotes that connect the fictional adventures to real history, and notes this is a book that works best in physical form.

Key Insight: The key to avoiding aliasing bugs is distinguishing between reference objects (where sharing is intentional) and value objects (which should be immutable to prevent unexpected shared mutations).

Martin Fowler explains aliasing bugs, which occur when multiple references point to the same memory location and unexpected mutations affect all references. He demonstrates the problem with a date example where modifying a party date accidentally changes a retirement date. Fowler distinguishes between reference objects (where sharing is intentional) and value objects (where sharing causes bugs). He advocates making value objects immutable to prevent aliasing bugs, while acknowledging that immutability introduces its own complexity when changes are genuinely needed.

Key Insight: Value objects—immutable compounds compared by their properties rather than identity—are deceptively simple yet serve as powerful refactoring leverage points that can dramatically simplify complex codebases.

Martin Fowler explains the concept of value objects—compound objects whose equality is determined by their property values rather than memory references. He contrasts them with reference objects (entities), demonstrates implementation across JavaScript, Java, and Clojure, and emphasizes that value objects should be immutable to avoid aliasing bugs. The post argues that while small objects like points and money are obvious candidates, larger structures can also benefit from value object treatment. Fowler concludes that value objects are often overlooked but can dramatically simplify codebases when properly identified and implemented.

Key Insight: Before dismissing a technique as fundamentally flawed, investigate whether it was applied correctly, in the right context, and with all necessary supporting practices in place.

Fowler argues that techniques and tools are often unfairly blamed for failures when the real problem is improper application. Using the metaphor of his mother's overcooked carrots, he explains how stored procedures blamed for version control problems or TDD blamed for brittle designs are examples of misuse rather than inherent flaws. He acknowledges the tension between this view and the 'no methodology has ever failed' defense, noting that techniques require skill and judgment rather than rigid adherence. The key is to dig deeper into reported failures to understand whether the technique itself was flawed or simply misapplied.

Key Insight: Quality and speed are not trade-offs—high quality is actually a prerequisite for rapid innovation, making Bimodal IT's core premise fundamentally wrong.

Martin Fowler critiques Bimodal IT, a Gartner-promoted approach that divides systems into fast-moving 'systems of engagement' and slow, reliable 'systems of record.' He argues this distinction is fundamentally flawed for two reasons: first, rapid innovation in front-office systems inevitably requires changes to back-office systems too. Second, the approach falsely assumes quality must be traded for speed, when in fact Thoughtworks' experience shows high quality enables faster delivery with fewer defects. Fowler recommends instead organizing around business capabilities and distinguishing between utility and strategic functions.

Key Insight: Serverless architectures trade traditional server management for new complexities around service composition, testing, and third-party dependency management—operations shift but don't disappear.

This post defines serverless architectures as internet-based systems that replace traditional server processes with third-party services, client-side logic, and Functions as a Service (FaaS). The architecture shifts control flow from server-side controllers to rich client applications that coordinate multiple services via API calls. Custom code components have much shorter lifecycles, activating per-request rather than running continuously. While serverless offers cost savings for bursty traffic and easier scaling, it introduces conceptual overhead from service composition, harder local development and testing, and new operational challenges when third-party services experience outages.

Key Insight: The explosion of 'as a Service' terminology in tech has become so pervasive that it warrants its own self-referential meta-term.

This brief, humorous post coins the term 'YAaaS' (Yet Another as a Service) as a meta-term for the proliferation of 'as a Service' terminology in the tech industry. Fowler credits colleague Birgitta Böckeler with the coinage. The post playfully demonstrates the term's usage by applying it to FaaS (Function as a Service).

Key Insight: Serverless architecture's greatest value lies not in cost savings but in dramatically reducing the feedback loop for deploying new application components, enabling continuous experimentation and lean product development.

This comprehensive article defines Serverless architecture as the combination of Backend as a Service (BaaS) and Functions as a Service (FaaS), where organizations reduce server management by leveraging third-party services and ephemeral, event-triggered compute containers. Fowler examines how Serverless shifts responsibility from central server orchestration to choreographed, distributed components, drawing parallels to microservices patterns. The piece methodically weighs benefits—including reduced operational costs, automatic scaling, faster time to market, and environmental efficiency—against significant drawbacks like vendor lock-in, cold start latency, testing complexity, and loss of server-side state. Fowler concludes that while Serverless isn't universally applicable, its reduced feedback loop for delivering new features represents its most compelling advantage for lean development approaches.

Key Insight: Organizing teams around activities like development or testing creates local optimization that undermines the cross-functional collaboration and fast feedback loops essential to effective software delivery.

Activity-oriented teams organize around functions like development, testing, and UX design, promising benefits like standardization and skill development. However, this structure causes teams to optimize for their own metrics rather than delivering useful software. It also increases batch sizes between handoffs, lengthens feedback loops, and limits team autonomy. The post argues that outcome-oriented teams with cross-functional membership are more effective for modern software development, where market responsiveness matters more than cost efficiency. Communities of practice can provide the mentoring and standardization benefits without the organizational downsides.

Key Insight: True outcome delivery requires cross-functional teams with both the mandate and capability to iterate on solutions, which traditional activity-oriented and project-centric structures inherently prevent.

Outcome-oriented teams are mandated and equipped to deliver business outcomes rather than just completing activities or delivering scope. Unlike activity-oriented teams that can only perform single specialized functions, outcome-oriented teams are cross-functional and self-sufficient. True outcome realization requires iterative collaboration between problem-understanders and solution-builders, which fails when product management is separated from development. While outcome orientation works better than activity orientation for large projects, the project-centric funding model limits its effectiveness by disbanding teams before outcomes fully materialize.

Key Insight: Different programming styles (functional, OO, transformational) are often observably equivalent implementations of the same computation - understanding what unites them (small well-named functions, explicit common context, clear separation of concerns) matters more than dogmatic style preferences.

Martin Fowler revisits the video store example from his 1999 refactoring book, this time implementing it in modern JavaScript ES6. He demonstrates how to break down a single long function into smaller, well-named functions, then explores four different architectural approaches for organizing the code to support multiple output formats (text and HTML): parameter dispatch, top-level functions, classes, and data transformation. The article shows that refactoring is about improving code in a direction that suits your team's coding style, and JavaScript's flexibility allows multiple valid approaches where Java would naturally push toward OO.

Key Insight: The programmer stereotype of antisocial male geniuses was manufactured by flawed 1960s hiring practices, not natural selection, and continues to filter out talented people who don't match this arbitrary image.

This article traces how the programmer stereotype—antisocial, mathematically-inclined, white males—was artificially constructed rather than natural. Beginning with the ENIAC 'Computer Girls' who were the first programmers, the piece examines how 1960s hiring practices, particularly the IBM Programmer Aptitude Test and SDC's personality profiles emphasizing 'disinterest in people,' created a self-fulfilling prophecy. The author explores how this stereotype, combined with the 1980s home computer boom that favored boys, continues to filter out talented people who don't match the narrow image. Drawing from Nathan Ensmenger's 'The Computer Boys Take Over' and Margolis and Fisher's 'Unlocking the Clubhouse,' the article argues that the 'born to code' myth damages diversity and that teams should actively challenge these assumptions.

Key Insight: When industry buzzwords become meaningless through overuse, returning to authoritative definitions like NIST's can restore clarity to technical discussions.

Fowler addresses the overuse and vagueness of the term 'cloud' by pointing readers to NIST's authoritative definition. He notes that overhyped terms typically lack clear definitions, making meaningful discussion difficult. The NIST document defines cloud computing as access to rapidly provisionable computing resources with minimal overhead. Fowler highlights the definition's clarity and brevity as notable, given the typical opacity of standards documents.

Key Insight: True readiness for production deployment—not just developer sign-off—is the only believable measure of software progress and the key to reducing both technical and business risk.

Continuous Delivery is the practice of building software that can be released to production at any time through extensive automation and collaboration. It requires maintaining deployable software throughout its lifecycle, using deployment pipelines, and fostering DevOps culture. The post distinguishes Continuous Delivery from Continuous Deployment—the former means you can deploy frequently, while the latter means every change automatically goes to production. Key benefits include reduced deployment risk through smaller changes, more believable progress metrics, and faster user feedback loops.

Key Insight: Treating infrastructure configuration as version-controlled, testable code eliminates the configuration drift and manual errors that plague traditional server management, making it essential for cloud-native and microservices architectures.

Infrastructure as code defines computing and network infrastructure through source code that can be version-controlled, tested, and delivered continuously. Fowler contrasts the old 'Iron Age' of months-long hardware provisioning with the 'Cloud Age' where servers spin up in seconds. The approach treats infrastructure configuration files as first-class software artifacts, eliminating manual server adjustments that create snowflake configurations. Key practices include using definition files exclusively, versioning everything, continuous testing, making small incremental changes, and maintaining service availability. This methodology becomes essential when adopting microservices at scale.

Key Insight: Reproducible builds aren't just for supporting old releases—they're essential debugging tools that let you verify bug understanding and use bisection to isolate when regressions were introduced.

Reproducible builds are a foundational but often unstated assumption of Continuous Integration. While frequent releases with solid Continuous Delivery might seem to eliminate the need for reproducible builds, they remain essential for debugging scenarios where bugs cannot be reproduced on the current codebase. The ability to recreate past builds enables proper bug verification, ensures no tests are missing, and facilitates diff debugging to track down regressions. Even in modern release environments, reproducible builds provide critical debugging capabilities that forward-only releases cannot replace.

Key Insight: Effective stand-ups focus on progressing work items rather than reporting individual busyness, requiring patterns that shift attention from runners to the baton and empower teams to self-organize.

This comprehensive guide explores daily stand-up meetings as more than a simple ritual, documenting patterns that distinguish effective stand-ups from wasteful ones. Fowler presents stand-ups as solutions to team coordination problems: sharing goals, coordinating efforts, surfacing problems, and building team identity. The article organizes patterns around key questions—who attends, what to discuss, speaking order, timing, energy management, and autonomy. It emphasizes that stand-ups should serve the team rather than management, with work items being the true focus rather than individual status reports. The piece concludes that while following patterns matters, the ultimate measure is whether teams are energized, sharing, focused, and working together.

Key Insight: Database schema evolution becomes manageable when every change is captured as a small, versioned migration script that travels through the same continuous integration pipeline as application code.

The article argues that database design must evolve alongside application development in agile methodologies, rather than being fixed upfront. Fowler and Sadalagi describe techniques developed over a decade at Thoughtworks for managing database schema changes through small, versioned migration scripts that are treated like application code. The approach treats every database change as a refactoring—combining schema modifications, data migration, and access code changes into atomic units. Key enablers include close DBA-developer collaboration, individual database instances for each developer, continuous integration of database changes, and automation tools. The techniques have scaled to projects with 600+ tables, 100+ developers, and 24/7 uptime requirements.

Key Insight: Your code's internal data structures should reflect what you actually need to process, not mirror the shape of incoming documents - encapsulate serialization decisions and declare only what you use.

Fowler examines different strategies for loading and processing JSON documents in Java, arguing against the common practice of creating full object hierarchies when only partial data is needed. He demonstrates through progressive refactoring examples how to encapsulate JSON handling, use sparse object structures, store raw JSON alongside needed objects, and enrich documents without full databinding. The key principle is that code should only declare and process the data structures it actually uses, creating more resilient and maintainable systems.

Key Insight: Web articles should be treated as living resources that evolve through revision and extension, not as static artifacts constrained by print-era conventions.

Fowler argues that web publishing should embrace iterative revision rather than mimicking print magazine conventions. Despite the web's ability to update content, most sites still treat articles as static, time-stamped artifacts. He advocates publishing articles in installments, then consolidating them into single evolving resources that improve over time. Using his microservices and collection pipelines articles as examples, he demonstrates how articles can be extended and revised as understanding deepens. The key shift is viewing web articles as living information resources rather than fixed publications.

Key Insight: While list-and-hash composites have become the lingua franca of data representation across programming languages, we should remember that schemaless flexibility always comes with implicit schemas, and richer tree abstractions still have their place.

Fowler examines the ubiquitous pattern of representing data structures as composites of lists and hashmaps, noting their presence across virtually all modern programming languages. He explains how these structures enable flexible, schemaless data representation while acknowledging the implicit schemas that exist in practice. The post highlights the power of generic operations and collection pipelines for manipulating these structures without knowing specific keys. Fowler also discusses serialization options, favoring JSON over XML, while noting that richer tree representations with XPath-style navigation sometimes offer advantages these simpler structures lack.

Key Insight: Collection pipelines enable complex data transformations through simple, composable operations—their power lies not in any single step but in how naturally the steps chain together.

Martin Fowler explains the collection pipeline pattern, a powerful technique for processing data through a sequence of operations where each step takes a collection as input and emits a collection as output. He traces its origins from Unix pipes through Smalltalk to modern languages like Ruby and Clojure, demonstrating how pipelines enable clear, composable code for filtering, transforming, and aggregating data. The article covers key operations (map, reduce, filter, group-by, flat-map), compares pipelines to loops and comprehensions, and addresses practical concerns like debugging, laziness, parallelism, and immutability. Fowler argues that while functional programmers often claim collection pipelines as their domain, Smalltalkers used them widely, and the pattern only declined in OO because popular languages like Java lacked lambdas until recently.

Key Insight: In agile organizations, enterprise architects derive their effectiveness from influence earned through partnership and collaboration, not from authority to mandate decisions.

This post addresses enterprise architects facing organizational transitions to lean/agile practices, arguing that their role must shift from centralized decision-making to influence and enablement. Fowler contends that EAs should stop making technology choices for teams and instead help teams make informed choices themselves. The article outlines practical approaches: establishing and sharing an architectural vision, building partnerships with development teams rather than mandating compliance, finding strategic opportunities for gradual change, and fostering learning communities. The core message is that EAs remain essential but must earn influence through collaboration rather than authority.

Key Insight: When business logic must be portable across platforms, refactoring it from imperative code into a data-driven adaptive model traded off code simplicity for a single, shareable source of truth—but this transformation should be incremental, reversible, and justified by real needs.

Fowler demonstrates how to refactor imperative conditional logic into an Adaptive Model—a data-driven approach where business rules are encoded in JSON and executed by a simple interpreter engine. The motivating problem is cross-platform duplication: the same recommendation logic must run on Node.js servers, iOS, and Android apps, making synchronized changes painful. By extracting the logic into a portable JSON structure using a Production Rule System pattern, the same rules can be loaded and interpreted anywhere. The refactoring proceeds incrementally, converting one conditional at a time while keeping tests passing, and introducing patterns like Range Picker to handle numeric thresholds elegantly.

Key Insight: The productivity question isn't whether remote or co-located is better in isolation, but whether the talent advantages of remote work outweigh the communication advantages of co-location for your specific situation.

Fowler argues that remote versus co-located work isn't a simple binary choice, but rather a spectrum of distribution patterns including single-site, multi-site, satellite workers, and remote-first teams. While he believes most people are more productive when co-located due to richer communication, he contends that remote teams can often be more productive overall because they can draw from a wider talent pool. The key is understanding the trade-offs of each pattern and investing in communication accordingly. He concludes that organizations able to make remote working effective will have growing competitive advantage as top developers increasingly resist relocation and commuting demands.

Key Insight: The fundamental goal of module dependency refactoring is separating service configuration from service use, which enables both testability and clean component boundaries regardless of whether you use service locator or dependency injection patterns.

This article demonstrates how to refactor a monolithic codebase into well-separated modules using presentation-domain-data layering. Fowler walks through a practical example of extracting calculation logic (Gondorff number) from both UI code and data access code, then explores different approaches for managing dependencies between these modules. He compares linker substitution, passing dependencies as parameters, service locator pattern, and dependency injection, showing the trade-offs of each approach. The key insight is that splitting service configuration from service use enables both testability through substitution and cleaner code organization. He also introduces the Split Phase refactoring pattern as a general technique for separating computation into distinct stages with intermediate results.

Key Insight: Better interfaces emerge when you design from the client's perspective, defining what they require rather than what suppliers choose to expose.

A required interface is defined by the client of an interaction, specifying what a supplier component needs to provide to participate. Unlike typical interfaces where suppliers decide what to expose, required interfaces flip this relationship by letting clients specify their needs. The Comparable interface in Java exemplifies this pattern, where sort functions define what objects must implement to be sortable. When integrating independently-developed modules, adapters bridge the gap between a supplier's actual interface and a client's required interface, even when method signatures happen to match but types don't align.

Key Insight: Software components are defined not by their technology but by their property of independent replaceability—enabling customers to upgrade and mix pieces on their own terms.

Martin Fowler explores the enduring but elusive goal of building software through component assembly rather than hand-crafted code. He adopts Ralph Johnson's customer-centric definition: components are things that are independently replaceable and upgradeable, allowing users to mix, match, and upgrade on their own schedule. Fowler identifies two modern forms of components: libraries (code linked into processes) and services (separate processes accessed via interprocess communication). The key distinction from ordinary modules is that components must allow independent replacement without forcing coordinated upgrades across the system.

Key Insight: The primary value of presentation-domain-data layering is cognitive—it narrows the scope of attention—and this benefit alone justifies the pattern even without substitutability or testability gains.

Martin Fowler advocates for the classic presentation-domain-data layering pattern as an effective way to modularize information-rich applications. The primary benefit is reducing cognitive scope—allowing developers to focus on one concern at a time without being overwhelmed by the entire system. While the pattern supports substitutability and testability, Fowler emphasizes that the cognitive benefit alone justifies the approach. He warns against organizing development teams along these layer boundaries, arguing that while individual developers need not be full-stack, cross-functional teams are essential for effective collaboration.

Key Insight: An antipattern's defining characteristic is not that it's bad, but that it's deceptively attractive—it looks like a good solution until you've invested heavily in it.

Martin Fowler traces the origin of the term 'antipattern' to Andrew Koenig's 1995 JOOP article, clarifying its precise meaning. The key distinction is that an antipattern isn't merely a bad idea, but something that appears to be a good solution initially before leading to trouble. This deceptive quality makes antipatterns particularly dangerous—sensible people adopt them because they look reasonable. Fowler also notes that context matters: the same solution can be a pattern in one situation and an antipattern in another.

Key Insight: Making the connection between daily technical work and business outcomes visible through shared visualization prevents teams from optimizing for the wrong goals and enables meaningful conversations about whether IT investments are actually paying off.

Alignment maps are organizational information radiators that visualize how day-to-day IT work connects to business outcomes. The technique emerged from observing projects that failed because teams lost sight of their original objectives—like developers who literally implemented 'search-in-one' instead of focusing on the actual goal of improving search performance. The maps trace connections from business outcomes through IT outcomes, initiatives, owners, and action items across teams. Organizations gain value both from the collaborative process of creating the map and from using it for ongoing alignment validation through regular red-amber-green status reviews with both IT and business stakeholders.

Key Insight: Collection pipelines make the logical flow of list processing visible and declarative, allowing you to read code as a series of transformations rather than deciphering mutable state and control flow.

Martin Fowler demonstrates how to refactor traditional loops into collection pipelines using functional operations like filter, map, and reduce. Through six progressively complex examples in C#, Java, JavaScript, and Ruby, he shows how pipelines can make collection processing more readable by expressing logic as a series of transformations. The key insight is that pipelines allow developers to see the flow of data through operations, making the intent clearer than imperative loops with mutable state and control variables.

Key Insight: DevOps succeeds through cultural transformation that eliminates silos and creates shared ownership, not through tooling or by creating dedicated DevOps roles that merely relocate the boundaries.

Fowler argues that DevOps is fundamentally about cultural change rather than tooling adoption. While new operations tools and agile engineering practices have made DevOps possible, the real benefits come from breaking down silos between development and operations through shared responsibility and collaboration. He identifies key cultural shifts needed: eliminating handovers and sign-offs, creating autonomous teams, building quality into the development process, and embracing feedback loops. Critically, he warns against the anti-pattern of creating dedicated 'DevOps teams' or roles, which perpetuates the very silos DevOps aims to eliminate.

Key Insight: Microservices trade the discipline required for monolithic modularity against the inherent complexity of distributed systems, a bargain that only pays off when system complexity exceeds a threshold that makes the distribution costs worthwhile.

This article presents a balanced analysis of microservices architecture by examining three key benefits (strong module boundaries, independent deployment, technology diversity) against three significant costs (distribution complexity, eventual consistency, operational complexity). Fowler argues that while microservices enforce modularity through service boundaries that are harder to circumvent than monolithic module boundaries, they introduce the inherent difficulties of distributed systems including latency, failure handling, and consistency challenges. He emphasizes that microservices impose a 'premium' that only pays off in sufficiently complex systems, and cautions that the industry lacks long-term experience with microservice architectures to fully assess their outcomes. The conclusion stresses that architectural choices matter less than team quality, collaboration, and fundamental software practices.

Key Insight: Great television doesn't require completist viewing - strategic cherry-picking of standalone episodes can provide an excellent introduction to a long-running series.

Martin Fowler offers a guide for newcomers to Doctor Who, explaining that the show's episodic nature allows viewers to cherry-pick excellent standalone episodes rather than watching chronologically. He recommends starting with New Who (2005 reboot) rather than Classic Who due to quality inconsistency in the older series. The guide walks through each series, highlighting standout episodes by writer Steven Moffat and others, while noting which episodes require prior viewing context. Fowler emphasizes that 'Blink' is the ideal starting point for newcomers, being widely considered one of the greatest episodes ever made.

Key Insight: Tor's security comes not from trusting individual components but from its architectural design where no single relay has enough information to compromise anonymity, making it resilient even when some relays are malicious.

This article provides a comprehensive technical explanation of how Tor works and its practical applications for technologists. Fowler explains the onion routing mechanism where traffic is encrypted in three layers and passed through volunteer relays, ensuring no single node knows both the source and destination. He covers the Tor Browser Bundle, hidden services (which enable anonymous server hosting), and addresses common misconceptions about Tor being 'broken.' The piece concludes by encouraging technologists to adopt Tor both for practical uses like testing and SSH access, and to contribute to the broader anonymity network that protects vulnerable users worldwide.

Key Insight: The ease of refactoring within a monolith is precisely what creates the tight coupling that makes extracting microservices later nearly impossible.

Stefan Tilkov challenges the popular advice that microservices architectures should always start as monoliths. He argues that once you build a monolith, the tight coupling between parts makes it extremely difficult to later extract services. The ideal approach is to start with separated subsystems from the beginning, provided you know your domain well—ideally when building a second version of an existing system. He acknowledges this adds complexity that smaller projects may not need, but emphasizes that microservices' main value is establishing hard boundaries that prevent unintended coupling.

Key Insight: Start with a monolith to discover correct service boundaries through experience, because the cost of wrong boundaries in a microservices architecture far exceeds the cost of later decomposing a well-understood monolith.

Fowler argues that teams should start new projects as monoliths rather than microservices, based on his observation that successful microservice architectures almost always evolved from monoliths, while greenfield microservice projects often end in serious trouble. The microservices premium—the overhead of managing distributed services—slows teams down when speed and feedback cycles matter most. Starting with a monolith lets teams discover correct service boundaries through experience rather than guessing upfront, where mistakes are costly to fix. He outlines several migration paths: careful modular design, gradual peeling of services, sacrificial replacement, or starting with a few coarse-grained services. While acknowledging counterarguments about building microservice discipline early, Fowler concludes that without prior microservices experience, monolith-first is the safer approach.

Key Insight: Microservices trade the implicit coupling of monoliths for explicit service boundaries, but this architectural choice only succeeds when component boundaries align well with business capabilities—otherwise you merely relocate complexity to harder-to-manage inter-service connections.

This foundational article defines microservices as an architectural style where applications are built as suites of small, independently deployable services organized around business capabilities. The authors contrast microservices with monolithic architectures, explaining that while monoliths work well initially, they create frustrations as applications scale—coupling change cycles, making modular structure difficult to maintain, and requiring full-application scaling. The piece systematically covers nine characteristics of microservice architectures, from componentization via services to evolutionary design. While clearly favorable toward microservices, the authors maintain cautious optimism, acknowledging that insufficient time has passed to fully judge how these architectures mature and warning that poor component boundaries simply shift complexity rather than eliminate it.

Key Insight: XP's integration of technical practices with management practices makes it a more complete foundation for agile development than Scrum, which risks becoming ineffective without the technical discipline.

This post provides an overview of Extreme Programming (XP), a software development methodology created by Kent Beck that served as a primary catalyst for the agile movement. Fowler traces XP's origins from Beck's Smalltalk consulting through the C3 project where it was first fully implemented. He emphasizes XP's unique value in combining both technical and management practices, contrasting it favorably with Scrum which focuses only on management. The post recommends Jim Shore's book as the best modern guide to learning XP, while acknowledging Kent Beck's 'white book' as the definitive description. Fowler notes that most Thoughtworks projects operate in a style primarily influenced by XP, though he considers it unimportant to judge teams on strict XP adherence.

Key Insight: Building features before they're needed incurs four compounding costs—build, delay, carry, and repair—that almost always outweigh the perceived savings of early implementation.

Yagni (You Aren't Gonna Need It) argues against building presumptive features before they're actually needed. Fowler identifies four costs of ignoring yagni: the cost of build (wasted effort if the feature is never needed), cost of delay (revenue lost by not building something more immediately valuable), cost of carry (added complexity slowing down other work), and cost of repair (technical debt from building features before you understand them properly). Research suggests only one-third of carefully planned features actually improve their target metrics. Crucially, yagni is not an excuse to neglect code health—it requires and enables malleable code through refactoring, testing, and continuous delivery practices.

Key Insight: Microservices are a solution for managing complexity, but they introduce their own complexity premium—so most systems should remain well-modularized monoliths unless genuinely too complex to manage that way.

Fowler argues that microservices have become overhyped, leading teams to adopt them prematurely without recognizing the inherent complexity costs. He contends that microservices introduce their own substantial overhead—automated deployment, monitoring, failure handling, eventual consistency—that acts as a premium on project cost and risk. The core decision factor should be whether your system is too complex to manage as a monolith. Most software systems, he asserts, should remain monolithic with good internal modularity. Many problems attributed to monoliths, like inability to do continuous delivery, aren't actually inherent to that style. Teams should only embrace microservices when facing genuine complexity that justifies the premium.

Key Insight: Simple, prioritized design rules—tests pass, intention is clear, duplication is eliminated, and nothing unnecessary remains—provide concrete, evaluable guidance that cuts through subjective debates about design quality.

Martin Fowler explains Kent Beck's four rules of simple design from Extreme Programming: passes the tests, reveals intention, no duplication, and fewest elements. The rules are prioritized in order, with testing being paramount. Fowler emphasizes that eliminating duplication is a powerful driver of good design, while the final rule guards against over-engineering. He notes that despite some tension between rules 2 and 3, they feed off each other in practice. These simple, memorable rules remain applicable across languages and paradigms.

Key Insight: Good modularity means separating code by concern—connection, data translation, and domain logic—so that changes to external services don't require understanding business rules, and vice versa.

Fowler demonstrates how to refactor code that mixes external service access with domain logic by progressively extracting responsibilities into separate objects. Starting with a single method that reads local data, calls YouTube's API, parses responses, and calculates metrics, he systematically introduces a Connection object (handling raw API calls), a Gateway object (translating external data structures into the application's vocabulary), and a Domain object (encapsulating business logic). The refactoring doubles the code size but dramatically improves comprehension by ensuring each module handles only one concern. The key insight is that separation of concerns enables developers to work on one aspect without understanding the others.

Key Insight: Data lakes succeed where data warehouses failed by accepting that unified schemas are impractical and that skilled data scientists can handle raw, messy data better than opaque cleansing processes.

A data lake is a storage repository that holds raw data in its native format, distinct from data warehouses that impose schemas and cleanse data upfront. The approach emerged because traditional data warehouse initiatives often failed due to schema disagreements and data quality disputes. By storing raw data, data lakes shift responsibility to data scientists who have the skills to handle messy, questionable data using sophisticated statistical techniques. The model works best when a small group of skilled analysts curates useful views into 'lakeshore marts' that serve broader organizational needs, while the lake itself remains a historical, immutable record with clear provenance.

Key Insight: Diversity doesn't trade off against quality—it trades off against convenience, requiring deliberate effort to find qualified candidates who exist but aren't in the usual places.

Fowler addresses the common objection that increasing diversity in hiring or conference speaking will lower quality standards, calling this fear an illusion. Using a marble analogy, he demonstrates that finding qualified candidates from underrepresented groups isn't impossible—it simply requires more effort. The real cost of diversity isn't mediocrity but additional work: actively seeking out talent in different places, creating welcoming environments, and ensuring diverse interview panels. He argues this effort is worthwhile both for professional reasons (expanding the talent pool) and moral ones (correcting historical discrimination). Fowler shares Thoughtworks' practical approaches and acknowledges they still have far to go, particularly in senior technical roles.

Key Insight: The fastest path to implementing a feature is often not direct - first refactoring code to create the right structure makes the actual change trivial and keeps you in a safe, test-passing state throughout.

Martin Fowler demonstrates preparatory refactoring through a real example from his publication toolchain. He needed to add a feature to highlight ranges of code lines, but instead of diving straight into implementation, he first refactored the existing code to create a place for the new functionality. By introducing no-op functions that preserve existing behavior, he gradually broke down the code while keeping tests green. The actual feature addition became trivial once the structure was in place, illustrating Kent Beck's principle: 'make the change easy, then make the easy change.'

Key Insight: Build languages are most powerful when implemented as internal DSLs within full programming languages, because build automation frequently requires general-purpose programming capabilities that external DSLs cannot elegantly provide.

This article explores Rake, a Ruby-based build language that serves as an internal DSL for dependency-based programming. Fowler explains how Rake differs from make and ant by leveraging Ruby's full programming capabilities while maintaining readable build syntax. He covers file tasks, synthesizing dependencies, platform-specific XML processing, and debugging techniques. The article demonstrates how Rake's flexible dependency specification and Ruby integration enable cleaner, more maintainable build scripts than external DSLs can provide.

Key Insight: APIs are the connective tissue of software ecosystems, and allowing their copyrightability would balkanize computing into incompatible islands while undermining the competitive markets and interoperability that benefit both developers and users.

Martin Fowler argues against API copyrightability, explaining that while copyright appropriately protects software source code, extending it to interfaces would harm innovation, competition, and interoperability. He draws parallels to physical interfaces like camera lens mounts and third-party car parts, showing how the ability to reverse-engineer interfaces benefits consumers and markets. The post highlights how open interfaces enabled the growth of the internet, Unix derivatives like Linux, and competitive tools like Samba. Fowler emphasizes that programmers routinely need to implement external interfaces for adapters and test doubles, making API copyright restrictions a practical impediment to everyday development work. The 2021 Supreme Court addendum notes that Google ultimately won on Fair Use grounds, effectively protecting the ability to reimplement APIs.

Key Insight: Validation failures are expected behavior, not exceptional conditions, so they deserve their own pattern (Notification) that collects all errors for a better user experience rather than failing fast with exceptions.

Martin Fowler demonstrates how to refactor validation code that throws exceptions into code using the Notification pattern. He argues that exceptions should be reserved for truly unexpected events, not validation failures which are expected behavior. The Notification pattern collects all errors rather than failing on the first one, providing better user experience. He walks through a step-by-step refactoring of a booking request validator, emphasizing the importance of taking small behavior-preserving steps and working backwards through the validation chain to avoid breaking code.

Key Insight: Despite smartphone ubiquity, dedicated GPS devices retain practical value for outdoor activities, but manufacturers' restrictive licensing practices on maps undermine customer loyalty and upgrade incentives.

Martin Fowler reviews the Garmin Oregon 600 handheld GPS device as a replacement for his aging 60CSx. He explains why dedicated GPS units still have value despite smartphone capabilities—better durability in poor weather and preserved phone battery. The touchscreen represents a significant improvement over button-based navigation, and battery life proved excellent on a Swiss hiking trip. The major frustration is Garmin's map licensing that locks purchased maps to single devices, though open-source maps provide an excellent free alternative. Overall, he recommends the Oregon 600 as a solid choice for hikers and cyclists.

Key Insight: Equipment matters less than being in the right place and having good compositional skills, so optimize for what helps you actually take more photos.

This is an informal camera gear review, not a technical software post. Fowler reviews the Sony a6000 mirrorless camera paired with the Sony-Zeiss 16-70mm lens, explaining his switch from a Canon DSLR system primarily motivated by weight concerns. He finds the combination satisfying for his travel photography needs while acknowledging the Canon still has advantages for certain situations like informal portraits and wildlife photography.

Key Insight: The software industry needs more documented examples of real architectures - both successes and failures - to learn from, treating them as 'show homes' for ideas rather than prescriptive standards.

Martin Fowler introduces the concept of 'expositional architectures' - documented examples of real software systems that serve as learning tools for the industry. He argues that software professionals suffer from a lack of visible examples compared to other disciplines, where practitioners learn by studying existing work. These architecture descriptions are meant to share interesting ideas and approaches, not prescribe best practices. Fowler emphasizes that both successes and failures are valuable learning material, and that architectural choices depend heavily on context.

Key Insight: The best architectural decision for today may be building something you consciously plan to throw away tomorrow, because premature optimization for longevity can prevent you from learning what you actually need.

Fowler challenges the notion that throwing away code represents failure, arguing that deliberately building systems you plan to replace can be the right architectural choice. Using eBay's multiple rewrites as an example, he shows how successful businesses are often built on discarded software because exponential growth invalidates early architectural decisions. He advocates for consciously accepting that current systems may need replacement while maintaining internal quality and good modularity. The key is recognizing that short-lived software can still deliver tremendous value, and the team that wrote the code should be the one deciding when to sacrifice it.

Key Insight: Tools designed for enterprise-scale infrastructure management often lack documentation and affordances for simpler single-server use cases, forcing practitioners to piece together solutions from scattered sources.

Fowler documents his experience setting up a Vagrant VM with Chef provisioning and rbenv to provide collaborators a ready-to-use development environment for his website toolchain. After collaborators wasted hours trying to install dependencies like Nokogiri, he decided to create a reproducible VM setup. The process proved more difficult than expected due to poor documentation for single-server Chef scenarios and complications with rbenv installation. He ultimately had to abandon pure Chef provisioning for Ruby, resorting to a manual bootstrap script. The article serves as practical breadcrumbs for others attempting similar setups.

Key Insight: Cloud synchronization, while convenient, can actively work against data recovery, and applications without built-in versioning force users into convoluted workarounds that shouldn't be necessary.

Fowler recounts accidentally deleting a note from Apple's Notes app and discovering there's no built-in version control or easy restore mechanism. Despite having Time Machine and rsync backups, iCloud synchronization overwrote restored files. He solved the problem by using an old laptop disconnected from the internet to restore the backup and extract the text. The post serves as both a practical how-to and a critique of applications that lack versioning features.

Key Insight: Microservices require operational maturity that most organizations lack—master rapid provisioning, monitoring, and deployment with a DevOps culture before adopting this architectural style.

Fowler argues that organizations should not adopt microservices without first establishing essential operational capabilities. The three prerequisites are rapid provisioning, basic monitoring, and rapid application deployment. These capabilities require a DevOps culture with close developer-operations collaboration. He advises starting small with a handful of services, learning from production experience, and scaling up gradually. Importantly, he notes these capabilities benefit monolithic systems too and should be priorities regardless of architectural style.

Key Insight: Maturity models are valuable for prioritizing learning, not for ranking or certification—the moment levels become competitive metrics, their core purpose is corrupted.

A maturity model is a tool for assessing current effectiveness and prioritizing what capabilities to learn next, structured as sequential levels of increasing competence. Fowler argues that the true value lies not in determining your current level, but in identifying what skills to acquire to improve. While maturity models have gained a bad reputation in software circles—largely due to the Capability Maturity Model's association with document-heavy processes and corrupted certification schemes—they can still be useful when applied properly. The key danger is using levels to compare or judge groups rather than to guide learning, which ruins the model's informational value. Any maturity model is a simplification that may not fit all contexts, and users should carefully evaluate fitness before applying one.

Key Insight: Effective learning follows a progression from precise imitation of one master, through understanding principles from multiple sources, to self-directed innovation based on personal practice.

Shu-Ha-Ri is a Japanese martial arts concept, introduced to software development by Alistair Cockburn, that describes three stages of learning a technique. In the Shu stage, students follow one master precisely without questioning theory. In Ha, they branch out to learn underlying principles and integrate teachings from multiple sources. In Ri, students innovate independently based on their own practice. The model emphasizes tailoring teaching style to the learner's current level of understanding.

Key Insight: Microservices don't violate the First Law because they explicitly design for distribution rather than hiding it, but distribution remains a complexity cost that should make monoliths the default choice absent compelling empirical evidence.

Fowler addresses the apparent contradiction between his 'First Law of Distributed Object Design' (don't distribute your objects) and his interest in microservices. He clarifies that distributed objects from the late 90s/early 00s attempted to make remote calls transparent to developers, which fails because you cannot encapsulate the remote/in-process distinction. Microservices, by contrast, explicitly acknowledge distribution through coarse-grained APIs and messaging. While Fowler's default preference remains monolithic design due to distribution's complexity costs, he respects empirical evidence from successful microservices adopters like Netflix. He concludes that the matter remains unsettled and that writers should communicate lessons clearly while acknowledging uncertainty.

Key Insight: Canary releases provide an early warning system for production problems by treating a small subset of real users as the proverbial canary in the coal mine, enabling safe rollback before issues affect everyone.

Canary release is a deployment technique that reduces risk by gradually rolling out new software versions to small user subsets before full production deployment. The approach starts with deploying to infrastructure with no user traffic, then progressively routing more users as confidence builds. Key benefits include production capacity testing with safe rollback, and the ability to detect problems before they impact the entire user base. The technique differs from A/B testing despite technical similarities—canaries detect regressions quickly while A/B tests measure hypotheses over days. Challenges include managing multiple concurrent versions and handling database schema changes during rollout.

Key Insight: The decision to embrace or isolate from a framework should be driven by whether you're in its sweet spot, not by architectural dogma - embrace your platform but isolate from truly external systems.

This post captures a video conversation between Martin Fowler and Badri Janakiraman exploring Hexagonal Architecture in the context of Ruby on Rails applications. They discuss when to use Active Record versus Data Mapper patterns, concluding that Data Mapper is warranted when you don't control the database or have complex domain logic, but Active Record is simpler and preferable otherwise. The conversation also examines whether frameworks like Rails should be treated as platforms (embraced fully) or suites of components (selectively used). They conclude that teams should make informed choices based on whether they're in the framework's sweet spot, while still isolating from truly external systems like version control or chat integrations.

Key Insight: Unit testing is not merely a technique for catching bugs but a cultural practice that transforms development teams by eliminating the fear of change and enabling sustainable productivity at scale.

This comprehensive article uses the 2014 'goto fail' and Heartbleed security vulnerabilities as case studies to argue for universal adoption of unit testing in software development. Fowler demonstrates through proof-of-concept tests that both catastrophic bugs could have been prevented with basic unit testing practices. He traces how Google's Testing Grouplet transformed a resistant development culture into one where unit testing became the norm, emphasizing that the benefits—reduced fear of change, faster feedback loops, improved code quality, and executable documentation—far outweigh the startup costs. The article concludes with detailed guidance on changing development cultures, drawing from the author's experience driving adoption across a large organization.

Key Insight: Backward-incompatible changes become safe and manageable when decomposed into expand, migrate, and contract phases that allow incremental client migration while maintaining a releasable codebase throughout.

Parallel change (or expand and contract) is a three-phase pattern for making backward-incompatible interface changes safely: expand the interface to support both old and new versions, migrate all clients to the new version, then contract by removing the old version. The post illustrates this with a Grid class example where x,y coordinates are refactored to a Coordinate object. This pattern is essential for continuous delivery because code can be released at any phase. It applies broadly to refactoring, database migrations, deployments (canary/blue-green), and REST API evolution.

Key Insight: The critical API design distinction isn't what's visible to code, but what's visible to codebases you don't control—published interfaces constrain evolution in ways that mere public interfaces do not.

Fowler distinguishes between 'published' and 'public' interfaces, arguing that a published interface is one used outside its defining codebase, making it fundamentally different from merely public code. The key insight is that public interfaces within a single codebase can be freely refactored since all callers are accessible, while published interfaces require special handling because you cannot update external consumers. Fowler contends this distinction matters more than the traditional public/private divide.

Key Insight: TDD remains valuable but must be applied thoughtfully based on context - the real goal is self-testing code that gives developers confidence, and achieving that matters more than adherence to any particular workflow.

This article documents a series of public conversations between Martin Fowler, Kent Beck, and David Heinemeier Hansson about whether TDD is 'dead.' Sparked by DHH's provocative RailsConf keynote, the discussions explore TDD's value, costs, and appropriate contexts. The participants find substantial common ground: all value self-testing code highly, agree TDD works well in some contexts, and emphasize that developers must thoughtfully adapt techniques to their situations rather than following dogma. The conversation serves as a 'reboot' to first principles after years of accumulated interpretations and misapplications of TDD practices.

Key Insight: The value of unit testing lies not in rigid definitions of isolation or unit boundaries, but in enabling frequent test runs that catch bugs while the code changes are still fresh in mind.

Fowler examines the surprisingly ill-defined term 'unit test,' tracing its evolution through XP and xunit frameworks. He identifies common elements—small scope, programmer-written, and fast execution—while noting significant disagreements about what constitutes a 'unit.' The central distinction he explores is between 'solitary' tests (using test doubles for collaborators) and 'sociable' tests (using real collaborators), representing classic versus mockist schools. He argues there's no absolute right answer on test speed or isolation, emphasizing that the real goal is running tests frequently enough to catch bugs while the context is fresh.

Key Insight: Self-testing code's primary value lies not in catching bugs before production, but in providing the confidence to continuously improve and refactor the codebase without fear.

Self-Testing Code refers to writing comprehensive automated tests alongside functional software, enabling developers to invoke a single command that illuminates any bugs in the codebase. Fowler traces the concept from an OOPSLA talk through his collaboration with Kent Beck and the creation of JUnit. The practice forms a foundational pillar of Continuous Integration and Continuous Delivery. While Test-Driven Development is one excellent way to achieve self-testing code, the key outcome is having the tests regardless of when they're written. The greatest benefit isn't avoiding production bugs but gaining confidence to change and refactor code safely, breaking the cycle of fear that paralyzes legacy codebases.

Key Insight: Enterprise applications are defined not by the size of the company using them but by their technical characteristics: persistent data, concurrent access, complex integrations, and business rules that accumulate irrationality for good commercial reasons.

Martin Fowler reflects on his choice to use 'enterprise application' as terminology for a specific class of software systems—those dealing with persistent data, concurrent access, complex integrations, and business logic. He identifies key characteristics: heavy reliance on databases, concurrent multi-user access, numerous UI screens, integration with legacy systems across decades of technology, conceptual dissonance between systems, and complex business rules that defy logical simplification. While acknowledging the term has acquired unfortunate connotations associating it with large corporations rather than the technical characteristics he intended, he concludes it remains the best available terminology.

Key Insight: Separating reporting from operational databases isn't just a performance optimization—it's an architectural boundary that enables independent evolution of both systems while acknowledging that most analytical thinking benefits from slightly stale data anyway.

Fowler argues that enterprise applications should separate their reporting needs from operational databases into dedicated reporting databases. The operational and reporting requirements differ significantly in schema design and data access patterns, making a unified approach suboptimal. A reporting database can be denormalized, use different technology, and store derived data without impacting operational performance. The main tradeoff is keeping data synchronized, though overnight batch updates often suffice since most reporting doesn't require real-time data.

Key Insight: Treating book writing like software development—with text-based source files, semantic markup, automated builds, and version control—solves the unique challenges technical authors face with code examples and collaboration.

Martin Fowler describes his text-based book writing toolchain, developed over two decades of technical authorship. He moved from WYSIWYG tools like Framemaker to a custom XML-based system that uses semantic markup and transforms to Docbook for multiple output formats. The approach enables automatic code import from live programs, eliminating error-prone copy/paste. While non-geeks might find it primitive, the system integrates well with version control and collaborative workflows, including his publisher's production staff working directly in the repository.

Key Insight: Circuit breakers transform unpredictable remote call failures into predictable, fast-failing responses that protect system resources and provide operational visibility into service health.

The Circuit Breaker pattern prevents cascading failures in distributed systems by wrapping remote calls in a monitoring object that trips after a failure threshold is reached. When open, the breaker fails fast without attempting the call, protecting both client resources and struggling servers. The pattern can self-reset by periodically attempting trial calls in a 'half-open' state. Fowler demonstrates the implementation in Ruby, progressing from a simple breaker requiring manual reset to a self-resetting version with three states: closed, open, and half-open. The pattern is valuable not just for fault tolerance but also as a monitoring and alerting mechanism for operational awareness.

Key Insight: Creating an inclusive tech community requires those in positions of privilege to actively care about and address behaviors that alienate others, even when those behaviors seem harmless from the majority perspective.

Fowler examines the alienating atmosphere in the tech community that contributes to diversity imbalance, particularly affecting women and historically discriminated-against groups. He acknowledges that as a middle-class white man, he rarely experiences this alienation, while accomplished women colleagues still feel unwelcome at tech gatherings. The post explores how sexual jokes, online harassment, and the accumulation of small slights create a hostile environment. Fowler argues that individuals can choose whether to care about offending others, and that the tech community should actively work to combat this atmosphere through awareness, codes of conduct, and speaking up against inappropriate behavior.

Key Insight: The burden of proof lies with those claiming diversity imbalance is natural—absent evidence, we must assume it results from systemic barriers that harm both individuals and the profession.

Fowler argues that the software industry's diversity imbalance—particularly the underrepresentation of women—cannot be explained by 'natural' differences in aptitude or inclination. He systematically dismantles this 'natural balance hypothesis' on two grounds: lack of evidence and its troubling historical use to deny equal rights. The post contends that diversity imbalance matters for moral reasons (equal opportunity), practical reasons (wasted talent and missed innovation), and professional credibility. Fowler concludes that software's diversity problems undermine its potential to be a forward-thinking model for human collaboration.

Key Insight: Treating DOM manipulation as a Gateway between bounded contexts enables cleaner separation of concerns and dramatically improves testability by allowing application logic to be tested without browser dependencies.

Martin Fowler addresses the common problem of 'jQuery soup' in single-page web applications, where application logic, DOM manipulation, and server access become tangled together. He proposes Segregated DOM as a modularization tactic that isolates all DOM manipulation into dedicated JavaScript objects. Using his eurogames catalog page as an example, he demonstrates how a controller class can manage application logic while communicating with DOM gateway classes through DOM-independent interfaces. This separation improves code reasoning, maintainability, and crucially enables testing the controller logic without a browser or mock browser environment.

Key Insight: Large systems require multiple bounded contexts with explicit interrelationships because the precision software demands cannot accommodate the natural polysemy of language across organizational boundaries.

Bounded Context is a central pattern in Domain-Driven Design that addresses the challenge of building unified models across large systems. Rather than attempting total unification—which DDD recognizes as neither feasible nor cost-effective—the pattern divides large systems into distinct contexts, each maintaining its own internally consistent model. Different contexts may share concepts like 'Customer' or 'Product' but represent them differently, with explicit mapping mechanisms handling integration. The boundaries between contexts are typically drawn along human cultural lines, since models serve as a Ubiquitous Language that changes across organizational groups.

Key Insight: Large-scale system changes can be made safely and incrementally by introducing an abstraction layer that allows old and new implementations to coexist, enabling continuous delivery throughout the migration.

Branch by Abstraction is a technique for making large-scale changes to software systems incrementally while maintaining continuous delivery capability. The approach involves creating an abstraction layer between client code and a component you want to replace, gradually migrating all clients to use this abstraction, then building a new implementation behind it. This allows the old and new implementations to coexist during migration, with the system remaining deployable throughout. The technique is particularly valuable as an alternative to long-lived version control branches when replacing frameworks or major dependencies.

Key Insight: Data you collect but don't need isn't a free asset—it's a liability that creates privacy risks, security vulnerabilities, and potential legal exposure.

Martin Fowler introduces Datensparsamkeit, a German privacy concept meaning 'data minimization' that opposes the prevailing Big Data mentality of capturing everything possible. He argues that the 'capture-it-all' approach creates serious privacy risks, as every data store becomes a target for criminals or surveillance agencies. Germany's history with government surveillance led to strong privacy laws embodying this principle. Fowler advocates that companies should only capture data they genuinely need, be transparent about their practices, and bear the burden of demonstrating necessity. He concludes that even from a pure risk management perspective, holding unnecessary data creates liability exposure.

Key Insight: Success in enterprise REST integration depends far less on understanding HATEOAS and far more on deployment strategies, consumer-based testing, bounded contexts, and epic-level coordination.

This article argues that successful enterprise REST integration depends far more on engineering practices than on REST's technical nuances. The author contends that large legacy replacements are among IT's hardest challenges, and organizations often underestimate integration complexity. The piece advocates for logical environment isolation, disciplined deployment pipelines with consumer-based testing, domain-driven bounded contexts for data modeling, and epic-level program management. The conclusion emphasizes that scaling RESTful integration requires addressing social and organizational issues rather than obsessing over hypermedia mechanics.

Key Insight: Underrepresentation of historically-discriminated-against groups should be treated as evidence that systemic wrongs remain uncorrected, not as a neutral statistical anomaly.

Martin Fowler explains why Thoughtworks uses the term 'historically-discriminated-against' to focus diversity efforts on groups that have faced systemic oppression. He argues that underrepresentation of such groups—like women in tech—signals that historical wrongs haven't been corrected, unlike imbalances affecting groups without discrimination histories. The post rejects 'color-blind' or 'gender-blind' policies as inadequate, noting that centuries of discrimination cannot be undone in years. Fowler dismisses biological explanations for women's underrepresentation as both unsupported and historically weaponized to justify discrimination.

Key Insight: When choosing between tablet sizes, occasional strong needs for a larger screen outweigh the frequent mild preference for smaller, lighter devices.

Martin Fowler shares his experience with the Google Nexus 7 tablet after several months of use. He purchased it to replace an aging iPad and to experiment with both Android and the smaller 7-inch form factor. While he finds Google's base UI slightly superior to Apple's and appreciates Android's keyboard completion approach, he has mixed feelings about the smaller screen size. He concludes that despite using the 7-inch more at home, he would choose a 10-inch tablet if limited to one device due to the screen size requirements for certain content.

Key Insight: Board gaming as a hobby involves strategic depth and thoughtful design analysis that mass-market games simply cannot provide.

Martin Fowler shares his enthusiasm for strategic hobby board games, particularly Eurogames, which are distinct from mass-market games like Monopoly. He maintains an active blog on BoardGameGeek called 'Martin's Seventh Decade' where he documents his gaming experiences. The page serves as an index to his board game writings, covering play reports, game reviews, and analytical pieces about game design concepts. His interests center on economic and route-building games like Brass, Age of Steam, and Power Grid, with recent exploration into the 18xx genre.

Key Insight: Most JavaScript code isn't inherently asynchronous, just async-compatible, which means unit tests can stub dependencies and execute synchronously rather than requiring complex async test infrastructure.

The post argues that most JavaScript code isn't intrinsically asynchronous—it merely supports async behavior through callbacks or promises. This distinction matters for testing because async-supporting code can be tested synchronously by stubbing external APIs. The author demonstrates testing patterns for both callback and promise-based code, strongly advocating for promises as they produce cleaner, more readable tests. Truly asynchronous tests should be aggressively limited because they're hard to maintain and often indicate code smell. The key technique is flattening potentially async operations into synchronous execution during tests.

Key Insight: Deployment pipelines resolve the fundamental tension between fast feedback and comprehensive validation by structuring builds as progressive stages of increasing confidence.

A deployment pipeline addresses the tension between fast feedback and comprehensive testing in automated build environments by breaking the build into sequential stages. Each stage provides increasing confidence at the cost of additional time, with early stages catching most problems quickly while later stages perform more thorough validation. The pipeline's broader purpose is to detect any changes that could cause production problems, including performance, security, and usability issues. Fowler recommends modeling your current delivery process as a pipeline to identify bottlenecks and automation opportunities.

Key Insight: Threshold tests transform silent, gradual degradation into visible, actionable failures at the moment problems are introduced.

A threshold test is a deployment pipeline test that compares a measurable value in the current build against a defined threshold, failing the build if the threshold is exceeded. Performance testing is a common use case, where teams time representative operations and fail builds that show significant degradation. The key benefit is catching problems at the commit that introduced them, making issues easier to diagnose and preventing gradual accumulation of problems. Threshold tests can be combined with ratcheting to progressively improve values over time. Teams may sometimes consciously decide to relax a threshold, but the test ensures this is a deliberate decision rather than silent degradation.

Key Insight: Page objects apply encapsulation to UI testing by hiding structural details behind an application-meaningful API, making tests both more maintainable and more expressive of their actual intent.

Page objects are a design pattern that wraps HTML pages or UI fragments with an application-specific API, shielding tests from brittle dependencies on UI implementation details. The pattern allows test code to interact with pages at a meaningful abstraction level—using strings for text fields, booleans for checkboxes, and action-oriented methods for buttons—rather than manipulating HTML directly. Fowler advocates for assertion-free page objects that provide access to page state while leaving assertion logic to test scripts. The pattern applies beyond web testing to any UI technology and represents a classic application of encapsulation that improves both maintainability and test readability.

Key Insight: While Tell-Don't-Ask usefully reminds us to co-locate data and behavior, treating it as an absolute rule leads to unnecessarily convoluted code - good design requires balancing multiple trade-offs.

Tell-Don't-Ask is a principle that encourages moving behavior into objects rather than extracting data and acting on it externally. The principle helps programmers remember that object-orientation bundles data with functions that operate on that data. While many find it useful for improving code design by co-locating tightly coupled elements, Fowler personally doesn't emphasize it because it can lead to extreme positions like eliminating all query methods. He notes that sometimes objects collaborate effectively by providing information, and good design requires balancing multiple trade-offs rather than following any single principle dogmatically.

Key Insight: Software development is fundamentally a design activity where construction is essentially free, making traditional engineering's separation of design and construction inapplicable and requiring adaptive, people-centered processes instead.

Fowler traces the evolution of software process from chaotic 'code and fix' through rigid plan-driven methodologies to agile approaches. He argues that agile methods differ fundamentally from traditional approaches in two ways: they are adaptive rather than predictive, and people-oriented rather than process-oriented. The essay explains why software development cannot follow the civil engineering model of separating design from construction, since in software the source code itself is the design document and construction (compilation) is essentially free. Fowler concludes that while agile requires committed teams and collaborative customers, it offers superior control over inherently unpredictable software projects through iterative development and continuous feedback.

Key Insight: Given-When-Then is not unique to BDD but rather a communication-focused reformulation of established test structuring patterns that can be applied across any testing context.

Given-When-Then is a structured approach to writing tests developed by Daniel Terhorst-North and Chris Matts as part of Behavior-Driven Development (BDD). The pattern breaks tests into three sections: Given (pre-conditions), When (the behavior being tested), and Then (expected outcomes). While popularized through Cucumber and BDD, the pattern is essentially a reformulation of existing testing conventions like the Four-Phase Test and Arrange-Act-Assert. The approach works for both formal business-facing tests and informal unit test comments.

Key Insight: Specification By Example succeeds not despite its incompleteness but partly because of it—forcing teams to maintain ongoing collaboration rather than treating written specs as the end of communication.

Fowler argues that Specification By Example—using concrete tests as specifications—is a powerful and practical alternative to formal pre/post conditions and traditional requirements documents. While examples don't cover all cases like general specifications, they're much easier to create, especially for non-technical stakeholders. The approach provides a valuable double-check mechanism by expressing requirements differently in tests versus code. Fowler acknowledges this technique is incomplete and must be combined with other practices like conversation and Domain Driven Design, but sees this incompleteness as a feature that prevents teams from thinking communication is 'done' after writing specs.

Key Insight: When fluent interfaces clash with clean domain object design, introduce a separate Expression Builder object to host the DSL methods and translate them to conventional API calls.

The Expression Builder pattern solves a key problem with Fluent Interfaces: methods designed for fluent chaining look awkward on domain objects. Methods like 'with', 'skippable', and 'priorityRush' make sense in a DSL context but violate expectations of standard Command-Query APIs, where each method should make sense individually. An Expression Builder is a separate object that hosts the fluent interface and translates those calls into regular API calls on the underlying domain objects. This separation keeps domain classes clean while still enabling expressive DSL-style code.

Key Insight: Fluent interfaces are internal DSLs that prioritize readable, flowing code over conventional API patterns, requiring more design effort but yielding more expressive results.

Martin Fowler introduces the concept of 'fluent interfaces,' a term coined during a workshop with Eric Evans, describing an API design style that reads like a domain-specific language. The approach prioritizes readability and natural flow over conventional method patterns, using techniques like method chaining and carefully chosen return types. While fluent APIs require significantly more design effort than simple constructor/setter approaches, they create code that expresses intent more clearly. Fowler acknowledges the style violates conventions like CommandQuerySeparation but argues the fluency benefits justify the exception. He notes the pattern is most commonly applied to value object configurations and calls for more experimentation given limited real-world experience.

Key Insight: Privacy protection matters not for those with nothing to hide, but because democracy depends on journalists and activists being able to challenge power without surveillance-enabled retaliation.

Fowler argues that privacy protection isn't primarily about individuals with 'nothing to hide,' but about safeguarding those who challenge power in a democracy. Journalists investigating corruption and activists pushing for social change require privacy to do their work effectively. Those in power can exploit surveillance data to identify sources, discredit opponents, and suppress dissent. While acknowledging privacy isn't absolute and surveillance has legitimate uses against criminals, Fowler contends that without protecting the privacy of 'bothersome people,' democracy loses a vital pillar.

Key Insight: While in-memory user-defined fields are trivial to implement, the persistence layer—particularly with relational databases—requires choosing between querying convenience and schema flexibility, with dynamic schema being an underappreciated option that provides both.

Martin Fowler explores the challenge of allowing users to define their own fields in data structures, a common need in applications like address books. He explains that in-memory solutions using hashmaps (Variable State pattern) are straightforward, but persistence presents the real challenge. The article surveys five database approaches: Serialized LOB (storing fields as JSON/XML in a text column), attribute tables (key-value pairs in a separate table), pre-defined custom fields (schema columns like custom_field_1), and dynamic schema (using ALTER TABLE to add columns at runtime). Fowler notes that schemaless databases handle this naturally, while relational databases require tradeoffs between querying ease and flexibility.

Key Insight: Estimation techniques should account for the gap between focused work time and actual elapsed time, but simpler abstractions like Story Points achieve this without the complexity of calculating load factors.

Ideal time was an early Extreme Programming estimation technique where developers estimated focused work time without interruptions, then applied a 'load factor' to convert to actual elapsed time. The load factor was determined empirically by measuring velocity across iterations. The approach acknowledged that developers face many interruptions (meetings, interviews, support) that reduce productive coding time. However, the technique has largely been replaced by Story Points, which proved easier to calculate, harder to misuse, and equally accurate for planning purposes.

Key Insight: When story point estimates prove no more accurate than simple counts over time, the estimation effort may not be worth the overhead for experienced teams.

Story counting is an alternative to story points for agile planning, where teams simply count the number of stories delivered per iteration rather than estimating relative sizes. Fowler explains that some experienced teams have found their story point estimates are no more accurate than raw story counts over time, making the estimation effort unnecessary. The technique works because larger and smaller stories tend to cancel each other out statistically. Teams should still ensure stories are within an order of magnitude of effort and watch for distribution imbalances. Fowler notes this may be better suited for more advanced teams who have already mastered story points.

Key Insight: Story points succeed not by measuring absolute effort but by enabling relative comparison between work items, with past velocity translating those abstract units into actionable forecasts.

Story points are a relative sizing technique for estimating work in agile projects, used in combination with velocity to forecast when stories can be completed. Fowler explains that teams struggled with traditional staff-hour estimates, finding relative comparison more effective. The technique involves comparing new stories to previously estimated ones of similar size, using a small range of values like Fibonacci sequences. The process should be quick, with discussion only arising when team members have contrasting views, which often reveals unclear requirements. Fowler notes that story counting is an equally valid alternative, leaving the choice to individual teams.

Key Insight: Velocity exists purely to help teams forecast their own delivery timelines based on past performance, and corrupting it into a productivity metric destroys its usefulness and undermines agile principles.

Velocity is a planning calibration tool that measures how much work a team completes in a time period, typically determined by averaging recent iterations following the 'Yesterday's Weather' principle. Originally from Extreme Programming, it's now used widely across agile methodologies. The post emphasizes that velocity should only be used for forecasting, not as a productivity measure, since different teams use different baselines making comparisons meaningless. Using velocity as a productivity metric undermines the very agility it's meant to support.

Key Insight: NoSQL is best understood not through a rigid definition but as a label for a particular wave of databases sharing common characteristics, with the 'Not Only SQL' interpretation reserved for the broader polyglot persistence ecosystem.

Fowler tackles the surprisingly difficult task of defining what constitutes a NoSQL database, noting the term emerged from a 2009 San Francisco meetup without any formal definition, trademark, or standards body behind it. He argues that interpreting NoSQL as 'Not Only SQL' for individual databases renders the term meaningless, preferring to reserve that interpretation for the broader ecosystem (which he calls Polyglot Persistence). Rather than a strict definition, he proposes NoSQL refers to a particular wave of recent databases sharing common but non-definitional characteristics: non-relational, open source, cluster-oriented, web-scale focused, and schema-free. Despite his frustration with another blurry industry term, he concludes that these databases represent an important addition to application development regardless of definitional clarity.

Key Insight: Configuration management tools cannot practically achieve complete drift prevention, making short-lived Phoenix or Immutable Servers a more effective strategy than fighting entropy through synchronization.

Martin Fowler examines the limitations of automated configuration management tools like Chef, Puppet, and CFEngine. While these tools promise to prevent configuration drift by continuously synchronizing server state to specifications, in practice they cannot manage every configurable element of a system. The work required to specify, test, and maintain recipes grows non-linearly with complexity, and managing unwanted elements is even harder than managing desired ones. Teams typically apply the 80/20 rule, automating only the most critical 5-20% of configuration. This practical limitation leads Fowler to recommend Phoenix Servers or Immutable Servers as more effective approaches to preventing drift.

Key Insight: Treating servers as immutable artifacts that are replaced rather than modified eliminates configuration drift and brings the reliability benefits of continuous delivery to infrastructure management.

Martin Fowler explains the concept of Immutable Servers as a logical evolution from Phoenix Servers, where servers are never modified after deployment but simply replaced with new instances. The approach builds on automated configuration tools but shifts focus from managing running servers to managing base images. All changes are made to the base image, tested through automated pipelines, and deployed as fresh instances. This pattern aligns with Continuous Integration and Continuous Delivery principles, treating server instances like compiled artifacts that should be built once and deployed consistently. Per-instance configuration should be minimized and externalized through metadata or central registries.

Key Insight: Regularly destroying and rebuilding servers from scratch is the most thorough way to prevent configuration drift and ensure infrastructure remains reproducible.

Fowler introduces the concept of 'Phoenix Servers' - the practice of regularly destroying and rebuilding servers from scratch rather than maintaining long-running instances. He argues this approach combats configuration drift, where ad hoc changes accumulate and go unrecorded, eventually creating unique 'snowflake servers' that are difficult to reproduce. While configuration management tools like Puppet and Chef can re-apply known configurations, they only catch drift in areas they explicitly control. Phoenix servers, by starting fresh each time, ensure complete alignment with source configuration.

Key Insight: Server configurations should be defined as version-controlled, automated recipes rather than accumulated manual changes, because reproducibility without understandability still leaves you with a fragile system.

Martin Fowler describes the 'snowflake server' anti-pattern where production servers become unique, manually-configured systems that are difficult to reproduce, understand, or modify. These servers accumulate cruft and undocumented changes over time, making them fragile and resistant to upgrades. The solution is to define server configurations as automated recipes using tools like Puppet or Chef, stored in version control. This approach enables reproducibility, auditability, easier testing environments, and supports continuous delivery practices.

Key Insight: Don't build a mobile app—build one application with multiple device-appropriate presentations, designed from the user's perspective rather than the technology's.

Fowler argues that companies make a fundamental mistake when they set out to 'build a mobile application' as a separate project. Instead, organizations should think about building a single transmedia application that presents itself across multiple devices—phone, tablet, desktop, TV—each adapted to its usage context. The user experience should be seamless across these presentations, allowing users to switch between devices naturally. This isn't new thinking; it's basic systems analysis applied to the modern multi-device world, where software must meet users wherever they are.

Key Insight: NoSQL databases (excluding graph) share an aggregate-oriented model that aligns well with both cluster distribution and application programming, but sacrifices the flexible querying that relational databases provide.

Martin Fowler identifies a unifying concept across key-value, document, and column-family NoSQL databases: they all organize data around aggregates, which are rich structures of closely related data. This aggregate orientation emerged from the need to store data effectively on large clusters, where aggregates serve as natural units for sharding and distribution. While this model simplifies programming by avoiding the decomposition required for relational storage, it creates challenges when you need to access data in ways that cut across aggregate boundaries. Fowler argues this trade-off supports polyglot persistence—using aggregate-oriented databases for clear aggregates and relational or graph databases when flexible data access is needed.

Key Insight: Encapsulation doesn't require converting data to rich object graphs—wrapping generic data structures in thin objects provides the benefits of OO while avoiding unnecessary transformation overhead.

Fowler addresses the complaint that object-oriented languages create unnecessary overhead when flowing JSON data through servers. Rather than converting JSON to full object graphs and back, he proposes wrapping generic data structures (parsed JSON) inside thin object wrappers that provide encapsulated access methods. This 'embedded document' pattern preserves the efficiency of working with raw data structures while maintaining the benefits of object-oriented encapsulation. The approach works best when data is stored and served in similar formats but requires some server-side manipulation. As processing complexity increases, converting to a full object graph may become worthwhile.

Key Insight: The DIP is not about using interfaces or abstract classes, but about ensuring your code depends on abstractions that exist at the same conceptual level as your domain, hiding lower-level implementation details behind boundaries you control.

This article explores practical applications of the Dependency Inversion Principle (DIP) through real-world examples from production systems. The author distinguishes DIP from Dependency Injection and Inversion of Control, explaining that DIP is about raising the abstraction level of dependencies to match your domain. Through four examples—simplifying logging APIs, hiding database details behind repositories, abstracting away messaging infrastructure, and controlling time in tests—the article demonstrates how inverting dependencies toward higher-level domain concepts reduces risk, improves testability, and creates more maintainable systems.

Key Insight: Simple estimation based on past performance often matches the accuracy of sophisticated prediction systems while avoiding their complexity and cost.

Yesterday's Weather is an estimation principle from Extreme Programming that suggests planning to accomplish as much in the current iteration as was completed in the previous one. Fowler recounts the term's origin from his collaboration with Kent Beck on their XP book. The name derives from a story about an expensive weather prediction system that achieved only marginally better accuracy than simply predicting today's weather will match yesterday's. The post argues that this crude but effective heuristic rivals more sophisticated planning approaches in accuracy.

Key Insight: Broad-stack tests are valuable for catching integration bugs but should be used sparingly per the Test Pyramid, with remote dependencies replaced by test doubles verified through contract tests.

Broad-stack tests (also called end-to-end or full-stack tests) exercise most parts of a large application, in contrast to component tests that focus on isolated parts. The distinction between broad-stack and component tests exists on a continuum rather than as a clear boundary. Tests can be broad-stack even without UI manipulation if they exercise most of the software. Fowler recommends using test doubles for remote systems rather than calling them directly. While broad-stack tests excel at finding bugs in component interactions, they are slower and harder to maintain, leading to the Test Pyramid recommendation of using fewer of them.

Key Insight: Effective business-facing tests prioritize communication with stakeholders over technical implementation details, using domain language to ensure the system meets customer expectations.

Business-facing tests are designed to communicate with non-programming stakeholders like customers and business analysts, describing system behavior in domain terms rather than technical architecture. When automated, these tests often use domain-specific languages via tools like Cucumber to bridge the gap between programmers and business people. While commonly implemented as broad-stack black-box tests, component-level implementations offer maintenance and speed benefits. Fowler emphasizes that manual testing techniques like exploratory and usability testing remain essential complements to automation.

Key Insight: While story tests provide valuable traceability and acceptance criteria, their tendency toward duplication and slow execution makes a leaner approach combining user journey tests with component tests preferable.

Story tests are business-facing tests that verify software delivered as part of a user story, serving as acceptance criteria and forming a regression suite. While user stories offer a simple workflow where each story adds new tests, this approach often leads to problems. The accumulating tests create significant duplication, making updates painful when behavior changes in later iterations. Additionally, broad-stack story tests are slow to execute, violating the Test Pyramid principle. Fowler suggests using fewer user journey tests combined with business-facing component tests as a better alternative.

Key Insight: User-journey tests should be few in number, covering only happy paths for system integration, while other test styles handle comprehensive behavioral verification.

User-journey tests simulate a typical user's complete interaction with a system to achieve a goal, functioning as a single path through a use case. As broad-stack tests, they are slow and brittle, so teams should keep suites small rather than comprehensive. These tests exercise system integration with usually just one happy-path scenario per use case, leaving behavioral variations to more focused test styles. Unlike story tests, user-journey tests aren't tied to individual user stories but are modified incrementally as stories change system behavior.

Key Insight: Aggregates define transactional and consistency boundaries in your domain model, with a single root object controlling all access to ensure integrity.

This post defines the Aggregate pattern from Domain-Driven Design, explaining it as a cluster of domain objects treated as a single unit. Using the example of an order with its line-items, Fowler describes how aggregates have a root object through which all external references must pass, ensuring integrity. He emphasizes that aggregates are the basic unit for data storage operations and that transactions should not cross their boundaries. The post also clarifies the common confusion between DDD aggregates and generic collection classes.

Key Insight: Component tests trade completeness for speed and maintainability, but must be combined with broad-stack tests since bugs hide in component interactions.

A component test deliberately limits scope to a portion of a system, contrasting with broad-stack tests that exercise the full system. The distinction is one of degree rather than absolute difference, with component tests using internal interfaces and test doubles for isolation. While component tests are faster and easier to maintain, bugs tend to hide in component interactions. Fowler recommends combining many component tests with fewer broad-stack tests following the Test Pyramid approach.

Key Insight: Promises provide both a clean callback interface and composability for managing asynchronous JavaScript operations, though the ecosystem suffers from fragmented implementations.

This post introduces JavaScript promises as objects that represent pending results of asynchronous operations. Fowler explains how promises provide a clean interface for scheduling callbacks after async tasks complete, with handlers for success, failure, and either outcome. He highlights that promises compose well, allowing multiple async operations to be combined. The post acknowledges the fragmented landscape of promise implementations in JavaScript, noting jQuery's Deferred Object as the most common, and points readers to Trevor Burnham's resources for deeper learning.

Key Insight: C3's significance lies not in its ultimate success or failure, but in being the crucible where Extreme Programming practices were first combined—and its cancellation reminds us that no methodology guarantees project success.

C3 (Chrysler Comprehensive Compensation) was the payroll project at Chrysler that birthed Extreme Programming. Started in 1993 and rebooted under Kent Beck in 1996, it became the first project to combine all XP practices. The software went live in 1997 paying around ten thousand people, but new development stopped in 1999 and eventually reverted to COBOL. While C3's early success inspired XP's spread, its eventual cancellation demonstrates that XP is no guarantee of success. Fowler notes that most public analyses of C3 lack factual basis and contain misleading information.

Key Insight: The value of estimation depends entirely on whether it informs a meaningful decision—always ask what decision an estimate serves before investing effort in creating it.

Fowler addresses the debate within the agile community about whether estimation is valuable or harmful. He argues that estimation is neither inherently good nor bad—its value depends entirely on whether it informs a significant decision. He identifies legitimate uses including resource allocation decisions, coordination between teams, and as a forcing function for team discussions. However, he warns that estimates misused as fixed commitments lead to unrealistic expectations, feature devotion, and quality sacrifices. Teams at higher agile fluency levels often find they can work effectively without formal estimation.

Key Insight: Sharing a database between applications creates deep coupling that makes evolution difficult, and the convenience of synchronized data access rarely justifies the architectural costs.

An integration database serves as a shared data store for multiple applications, contrasting with application-specific databases. While this approach eliminates the need for separate integration services and keeps data synchronized across applications, it creates significant architectural problems. The shared schema must accommodate all client applications, becoming overly general or complex. Most critically, the database becomes a deep coupling point between applications, making changes risky and evolution difficult. Fowler concludes that respected software architects recommend avoiding integration databases entirely.

Key Insight: When developers choose technology to avoid organizational friction rather than for technical merit, the real problem—broken collaboration between teams—remains unsolved and often worsens.

Fowler examines the trend of development teams using NoSQL databases to bypass centralized DBA groups and their slow change-order processes. While acknowledging the legitimate frustrations with weeks-long waits to add a database column, he notes that choosing technology for social rather than technical reasons can lead to poor outcomes. He observes that many legacy databases are essentially brittle, untested applications at the center of complex dependencies, which explains DBA caution. Fowler advocates for a devops-style engagement approach where developers and data professionals collaborate rather than work around each other.

Key Insight: Modular presentation formats can preserve the spontaneity advantages of extemporary speaking while gaining the clarity benefits of prepared visual materials.

Martin Fowler describes his evolution in keynote speaking, moving from extemporary talks without slides to a new 'suite of talklets' format. He found keynotes awkward because broad audiences require broader topics than focused conference sessions. After being inspired by Neal Ford's effective use of slides as a visual channel rather than bullet points, Fowler developed a hybrid approach: three twenty-minute slide-backed segments that can be mixed and matched. This preserves his flexibility to customize talks for specific audiences while gaining the benefits of prepared visual materials.

Key Insight: Metrics should serve as instruments for understanding and improving systems, not as substitutes for thinking or as tools for pressuring individuals to hit arbitrary numbers.

Fowler argues that organizations misuse metrics by conflating targets, performance measures, and best practices into a single number, which drives counterproductive behavior. When metrics become disconnected from their underlying goals, people optimize for the number rather than the actual objective—leading to single-loop learning where teams work harder without questioning whether they're solving the right problem. The article proposes four guidelines: explicitly link metrics to goals, track trends rather than absolute numbers, use shorter tracking periods, and retire metrics when they stop driving meaningful change. True improvement comes from double-loop learning, where teams examine and change the system itself rather than just working harder within a broken system.

Key Insight: Transparent compilation succeeds not despite the constraint of readable output, but because that constraint forces a clear correspondence that makes both source and target code easier to understand.

Fowler distinguishes 'transparent' compilers like CoffeeScript and SCSS from other source-to-source compilers by their design intention: the output must remain readable and debuggable by developers. This constraint fundamentally shapes what the source language can do, requiring it to follow the target language's semantics and program structure. Despite these limitations, transparent compilation provides significant value through useful language features and improved code readability. The tradeoff is worthwhile because cleaner source code is easier to understand even when debugging the generated output.

Key Insight: Sometimes the most appealing destinations are defined not by what they offer, but by what they've avoided becoming.

This is a travel blog post about Saba, a small Caribbean island near St Martin that the author loves for its lack of typical tourist amenities. The island has no beaches, golf courses, or casinos, which has kept mass tourism away. The main attraction is excellent diving in the surrounding marine park, along with hiking trails including the tallest peak in the Netherlands. The author describes the island's quirky history, including a road built by locals after Dutch engineers said it was impossible, and one of the shortest airport runways in the world.

Key Insight: True software extensibility means users program their tools using the same mechanisms that built the core system, creating a fundamentally different and more empowering relationship between people and their software.

Fowler explores the concept of 'internal reprogrammability' - the ability to modify software from within its own environment without external toolchains or restarts, as exemplified by Emacs and Smalltalk. He contrasts this with modern plugin architectures that limit customization surface area. While acknowledging challenges like instance fragmentation and upgrade complexity, he argues this capability represents a fundamentally different relationship with tools - one where users craft software to fit their needs rather than accepting fixed products. He questions why this philosophy hasn't been extended more broadly, especially to non-programmers, noting it was central to Alan Kay's dynabook vision.

Key Insight: Infodecks deserve serious attention as a communication form because they're optimized for a single purpose - reading on screens - rather than being compromised slideuments that fail at both presentation and documentation.

Fowler introduces the concept of 'infodecks' - slide decks designed purely for reading rather than presentation, distinguishing them from the problematic 'slideuments' that try to serve both purposes. He argues that infodecks have legitimate advantages: spatial layout aids explanation, they discourage unread long prose, and diagrams become primary communication elements. While acknowledging that infodecks are often dismissed as unserious by both casual users and professional writers, Fowler advocates taking them seriously as communication vehicles, especially as tablet computing becomes more prevalent. He shares his experiments with both PDF and HTML formats, ultimately preferring HTML for its dynamic capabilities despite tooling challenges.

Key Insight: Slides and documents serve fundamentally different purposes, and trying to combine them into a single artifact means failing at both.

A slideument is a hybrid between a slide deck and a document that attempts to serve both as presentation visuals and standalone reading material. Fowler argues this approach fails because the two purposes have conflicting requirements: documents need enough context to stand alone, while good slides should be a visual channel that accompanies rather than duplicates spoken words. When audiences read dense slides while listening to a speaker, they concentrate properly on neither. Despite audience expectations for slide handouts, Fowler advocates providing separate, purpose-built documents alongside or instead of slide copies.

Key Insight: Understanding probability is essential for making sense of data, and software professionals must lead in both developing this literacy themselves and educating others to distinguish signal from noise.

Martin Fowler uses the 2012 US election and Nate Silver's probabilistic forecasting as a lens to examine widespread probabilistic illiteracy. He argues that people fundamentally misunderstand probability - conflating an 85% chance with certainty, believing single events can validate probabilistic models, and demanding binary answers rather than ranges. Fowler connects this to software development, where stakeholders want firm estimates rather than probability distributions. He contends that as data becomes more central to decision-making, software professionals must both understand statistics themselves and educate consumers of their data to distinguish signal from noise.

Key Insight: Sometimes we should follow practices that feel intellectually revolting if evidence suggests they work—though we must also update our beliefs when that evidence crumbles.

Fowler examines the practice of reading the Retrospective Prime Directive at the start of every retrospective, as recommended by Pat Kua. While his gut reaction is revulsion—associating it with empty rituals and motivational posters—he acknowledges that psychological research on priming suggests such rituals may genuinely help prime participants for the open mindset needed in retrospectives. He concludes that despite his distaste, the evidence suggests he should accept the practice. A 2017 update notes that priming research has faced serious replication problems, casting doubt on the scientific foundation for this advice.

Key Insight: As AI reshapes software development infrastructure and workflows, organizations must balance rapid adoption with vigilance against emerging antipatterns while ensuring AI amplifies entire teams rather than just individuals.

The Technology Radar is Thoughtworks' biannual publication that categorizes emerging technologies into four recommendation levels: Adopt, Trial, Assess, and Hold. Volume 33 (November 2025) focuses heavily on AI infrastructure and agentic workflows, highlighting how GPU orchestration has become essential for AI workloads and how the Model Context Protocol (MCP) is transforming how agents operate. The Radar also examines AI coding workflows and their impact on software development, while warning about emerging AI antipatterns that teams should avoid. This edition reflects the industry's rapid evolution around AI tools and practices, emphasizing that human judgment remains critical even as AI accelerates engineering work.

Key Insight: Industry progress depends on companies sharing their learnings openly, and developers must engage actively with emerging technologies rather than passively receiving requirements.

Fowler reflects on the 2012 goto conference in Aarhus, highlighting several emerging technology trends. He praises Netflix's openness in sharing their Cassandra learnings and tools, contrasting it with the secrecy that often hampers industry progress. The post focuses heavily on JavaScript's growing dominance despite its flaws, discussing TypeScript as a promising solution. He also notes Microsoft's significant shift toward open-source collaboration, marking a change from their historically hostile stance. Finally, he emphasizes SVG's potential to transform web visualization by making vector graphics accessible through the DOM.

Key Insight: NoSQL's real contribution isn't replacing relational databases but enabling polyglot persistence—matching storage technology to specific data needs while acknowledging the complexity tradeoffs involved.

This post presents the distilled key points from the book 'NoSQL Distilled' by Pramod Sadalage and Martin Fowler. It covers why NoSQL emerged as an alternative to relational databases, particularly for handling large data volumes on clusters. The content explains different data models (aggregate-oriented, graph), distribution patterns (sharding, replication), consistency tradeoffs, and practical concerns like schema migrations. The overarching message emphasizes polyglot persistence—using the right database technology for each specific need rather than one-size-fits-all. The authors caution that most applications should stick with relational databases until NoSQL matures further.

Key Insight: Powerful tools that remove friction from testing poorly-designed code may inadvertently short-circuit the learning feedback loop that drives developers toward better design.

Martin Fowler examines modern mocking tools like JMockIt that can bypass Java's language constraints to mock static methods and direct instantiations without modifying production code. While initially impressed by this capability for testing legacy code, he demonstrates that applying traditional refactoring techniques (instance delegators, method extraction, testing subclasses) produces cleaner, more maintainable tests. The article walks through testing a poorly-designed currency conversion method both ways, showing that the refactored approach yields simpler tests while also improving the production code. Fowler ultimately concludes that while powerful mocking tools have legitimate uses, they can short-circuit the feedback loop that drives developers to write better code in the first place.

Key Insight: BigQuery enables rapid experimentation with Big Data analytics at low cost, making it valuable both as a primary solution for organizations lacking infrastructure and as a sandbox for those with existing data warehouses.

Thoughtworks partnered with AutoTrader UK to test Google BigQuery's capability to analyze large datasets, using 750 million rows of historical car advertisement data. The proof-of-concept aimed to help dealers determine car pricing and selling timeframes. While data transfer from Amazon EC2 to Google Cloud Storage was slow (12 hours), once loaded, BigQuery delivered query results in 7-10 seconds. The team built a web frontend using Google App Engine and Charts for visualization. Overall, BigQuery proved viable for organizations wanting Big Data insights without expensive infrastructure investments.

Key Insight: Communal dashboards create organizational awareness and emotional connection to business operations, but require human facilitation to truly spark engagement and conversation.

Fowler introduces communal dashboards as a workplace practice where display monitors in semi-public spaces show live data visualizations to create organizational awareness. Unlike individual analytics tools, these dashboards aim to educate and create emotional engagement with business operations rather than drive specific decisions. He provides examples from Redbox showing rental counts, geographic expansion maps, and creative display mediums like floor projections. While acknowledging these are crude visualizations lacking detail or interactivity, Fowler notes they can connect office staff to distant day-to-day activities and serve as conversation starters with business partners. He concludes with a caution that dashboards alone may not trigger engagement without human facilitation.

Key Insight: Your initial mobile strategy should be viewed as an opening gambit in a longer evolution, requiring intentional trade-offs between platform coverage and experience quality while preparing hybrid technology paths for future growth.

Martin Fowler and colleagues present a framework for organizations entering mobile development, identifying a fundamental trade-off between platform coverage and user experience quality. They describe two strategic extremes: the Laser strategy (single platform, exceptional experience) and Cover-Your-Bases strategy (all platforms, simpler experience). The article argues that mobile's importance stems from user experience expectations, as exemplified by Apple's market success. Organizations should view their initial mobile approach as an 'opening gambit' that evolves toward supporting all platforms with high-quality experiences, with hybrid web technologies offering promising paths forward.

Key Insight: ORMs are imperfect solutions to a genuinely hard problem, and criticizing them without acknowledging the difficulty of the alternatives or the value of handling even 80% of the mapping work is intellectually dishonest.

Martin Fowler defends Object/Relational Mapping tools against widespread criticism, arguing that while ORMs are genuinely complex and provide leaky abstractions, the underlying problem they solve is inherently difficult. He contends that rolling your own ORM is typically worse than using established tools, and that the real issue is inflated expectations—ORMs handle 80-90% of mapping problems, which is valuable even if imperfect. The alternatives (using relational models in memory or switching to NoSQL) have their own significant limitations and aren't always viable. Fowler concludes that ORMs deserve more respect given the genuinely hard problem they address.

Key Insight: A well-balanced test portfolio should favor many focused unit tests over fewer broad end-to-end tests, with high-level tests serving as a safety net that reveals gaps in unit test coverage.

The test pyramid is a framework for balancing automated testing, advocating for many more unit tests than UI-based end-to-end tests. Fowler explains that while UI test automation seems attractive initially due to ease of recording, it quickly becomes problematic: slow, brittle, expensive, and prone to non-determinism. The pyramid recommends an intermediate layer of subcutaneous tests that operate through service/API layers, capturing end-to-end benefits without UI complexity. Fowler emphasizes that high-level tests should serve as a second line of defense, and any bug they catch should be replicated with a unit test before fixing.

Key Insight: When data access patterns differ significantly between use cases—like editing versus publishing—architectural separation into specialized modules yields better performance, scalability, and developer experience than the intuitive single-copy approach.

Fowler observes that content management systems have become problematic tools that hinder development, particularly due to their single-copy architecture. He argues that editing and publishing have fundamentally different data access patterns—editing involves few people doing frequent updates, while publishing serves many readers doing mostly reads. The solution is to separate these concerns into independent modules, with the editing module optimized for updates and workflow, and the publishing module optimized for serving content at scale. This separation enables benefits like different storage technologies, format transformations, staging previews, and independent scaling strategies.

Key Insight: Test coverage is valuable for discovering untested code, but chasing coverage percentages as a target inevitably produces low-quality tests that satisfy metrics without providing real confidence.

Martin Fowler argues that test coverage is a misunderstood metric that's useful for finding untested code but poor as a measure of test quality. He criticizes organizations that mandate specific coverage percentages, noting that high coverage is easily achieved with low-quality tests. Instead of chasing numbers, he proposes that sufficient testing means you rarely have production bugs and aren't afraid to change code. The post warns against both under-testing and over-testing, with the latter manifested in tests that slow down development or require excessive changes for simple code modifications.

Key Insight: Slides should serve as a visual channel that complements rather than competes with the speaker's words, but ultimately no amount of slide optimization can substitute for having something worthwhile to say.

Martin Fowler identifies common presentation anti-patterns that reduce the effectiveness of conference talks. He argues against putting sentences on slides, as they compete with the speaker's voice for the audience's attention. He criticizes repetitive elements like corporate logos on every slide, unnecessary pointer movements that should be built into slides, backtracking through slide decks, and mandatory slide titles. However, he concludes that content quality matters most—good content can overcome poor presentation technique, while great slides cannot save weak content.

Key Insight: The rise of NoSQL doesn't mean abandoning relational databases, but rather adopting polyglot persistence—strategically choosing different data storage technologies for different needs.

This brief post introduces a PDF infodeck co-authored with Pramod Sadalage that explains NoSQL databases to technical managers. The authors describe why relational databases dominated for so long and what forces disrupted that dominance. Rather than positioning NoSQL as a replacement, they emphasize that relational databases still have an important role, advocating for polyglot persistence—using different data storage technologies for different needs.

Key Insight: Regular volunteer code jams succeed through realistic expectations about contributor time, small completable tasks, dedicated organizers, and the motivating appeal of building software for meaningful causes rather than just other developers.

Martin Fowler describes how ThoughtWorks colleagues have organized code jam events where developers volunteer to build software for charitable organizations like RapidFTR and OpenMRS. Starting from a one-off event in New York in 2010, a small group began meeting weekly to contribute to open-source projects for NGOs. Fowler explains that while one-off events rarely produce much useful software, they generate awareness and can seed regular meetups. The post provides practical advice for organizing successful code jams, emphasizing the importance of champions, small tasks, easy setup, and shared food.

Key Insight: Copyright protection legislation must be crafted with engineering input and due process safeguards, otherwise it risks undermining the very internet infrastructure it seeks to protect.

Martin Fowler and Jez Humble wrote an open letter protesting Pearson's support for the SOPA/PIPA legislation, which they viewed as fundamentally flawed despite sympathizing with its copyright protection intent. They argued the bills lacked due process protections, proposed technically unsound approaches that would undermine internet security, and were crafted without adequate engineering input. The letter called on Pearson to reconsider its support and take responsibility as a technology education company. Over 100 prominent technical authors, including Joshua Bloch, James Gosling, Grady Booch, and Eric Evans, co-signed the letter in solidarity.

Key Insight: Investing in high-quality display hardware can unexpectedly reshape work habits by making certain environments more pleasant to use.

Fowler reviews his experience with Apple's Thunderbolt Display after purchasing it as a docking station solution for his MacBook Pro. While he encounters a persistent sleep/wake bug requiring cable reconnection and finds the glossy screen reflective, he concludes the display is worth the investment. The large, high-resolution screen has unexpectedly shifted his work habits, causing him to migrate from his Ubuntu desktop to the Mac for writing tasks. He particularly values the display for fitting multiple windows side-by-side and for improved video calls.

Key Insight: The dominance of relational databases was never really about data management—it was about integration—and the rise of HTTP-based integration finally frees applications to choose databases suited to their actual needs.

Martin Fowler argues that the long-standing dominance of relational databases is beginning to thaw, analogous to the earlier 'nuclear winter' in programming languages caused by Java's dominance. He attributes relational databases' grip not to their data management superiority but to their role in integration via SQL as a common query language. The rise of web services and HTTP-based integration is breaking this grip by enabling application databases rather than integration databases. This shift allows developers to choose data models suited to their specific needs rather than defaulting to RDBMS.

Key Insight: The question is no longer whether to use a relational database, but how you want to manipulate your data—and only then choosing the storage technology that best fits.

Martin Fowler argues that enterprises should move beyond the assumption that relational databases are the default choice for data persistence. Drawing on Neal Ford's concept of polyglot programming, he proposes that organizations should use different storage technologies for different types of data based on how that data will be manipulated. While acknowledging the complexity costs of managing multiple persistence technologies, he contends the benefits—reduced development drag and better scalability—make this shift worthwhile for strategic projects. Fowler predicts this 'database thaw' will progress steadily over the coming decade, though companies will adopt it conservatively.

Key Insight: The urgency to deliver faster by adding people often backfires because teams need time to absorb new members, and premature scaling destroys the codebase coherence and team communication that make productivity possible in the first place.

Fowler argues that adding people to software teams too quickly causes more harm than good, even when organizations are willing to pay for faster delivery. He explains that team productivity doesn't scale linearly with headcount—his rough estimate is that doubling a team yields only about 50% more productivity due to communication overhead. The real danger lies in ramping up before the codebase and team culture can absorb new members, leading to architectural inconsistency, code duplication, and broken communication patterns. He advises starting large projects with small teams who establish the design foundations, then growing carefully—never more than doubling at once—with settling periods between additions. The core message is that scaling teams is often not worth the cost and complexity it introduces.

Key Insight: Refactoring works best as an opportunistic habit woven into daily programming rather than as a planned activity, with small continuous improvements preventing the accumulation of technical debt.

Martin Fowler argues that refactoring should be an ongoing, opportunistic practice rather than a scheduled phase in the development lifecycle. He introduces the 'camp site rule' - always leave code better than you found it - as a guiding principle for continuous improvement. The post identifies several natural opportunities for refactoring: before implementing features, while adding functionality, and after getting something working. Fowler acknowledges the risk of falling down rabbit holes but emphasizes that good judgment and incremental improvement ultimately accelerate development rather than slowing it down. He warns against organizational practices like strong code ownership and long-lived feature branches that create friction for opportunistic refactoring.

Key Insight: The era of automatic reliance on relational databases is ending as distributed systems demand thoughtful selection of data storage solutions matched to specific use cases.

Martin Fowler recounts highlights from the 2011 goto conference in Aarhus, focusing on emerging technologies and architectural trends. He discusses Google's new Dart language as a cleaner replacement for JavaScript, noting its optional typing system. The post examines a case study of migrating Denmark's prescription system from MySQL to Riak for better scalability. Fowler observes that the 'DatabaseThaw' is gaining momentum, with organizations increasingly choosing NoSQL solutions when appropriate. He also highlights the Moose code analysis tool, praising its embodiment of the Lisp/Smalltalk philosophy of malleable, user-extensible tools.

Key Insight: Writing is not merely a way to communicate ideas you've already formed, but a tool for discovering and refining those ideas in the first place.

Fowler explains why he avoids creating video content despite its growing popularity and commercial viability. While acknowledging that video suits his public speaking abilities and that audiences clearly value it, he finds the medium personally unappealing for both learning and creating. His core objection is that writing serves as a thinking tool—he figures things out through the act of writing, whereas video feels like it requires pre-formed ideas. The essay format allows for exploration and discovery that video production doesn't seem to support.

Key Insight: The constraints of a fixed text make comparing different productions illuminating, as each interpretation reveals as much about the creative vision of its makers as about Shakespeare himself.

Martin Fowler describes his ongoing project with his wife and neighbors to watch every Shakespeare play in every available video version. For A Midsummer Night's Dream, they watched six versions chronologically, comparing the BBC's solid baseline, Hollywood's 1935 Busby Berkeley-style spectacle, Peter Hall's star-studded 1960s RSC production, Hoffman's lavish 1999 film, and Noble's imaginatively staged 1996 RSC version. The Noble production emerged as their clear favorite due to its creative staging (light bulbs for trees, a blank stage) combined with strong acting and direction. Fowler finds comparing different interpretations of the same fixed text to be as fascinating as Shakespeare's plays themselves.

Key Insight: Memory images offer a compelling alternative to databases by keeping all application state in memory and using event sourcing for persistence, trading database complexity for event management concerns.

Fowler explores 'memory image' as an alternative to traditional database persistence, where application state lives entirely in memory and is rebuilt from event logs rather than stored in a database. The approach uses event sourcing as its foundation—capturing every state change as a persistent event that can be replayed. He examines three implementations: LMAX's high-performance trading system, EventPoster architectures for analytics, and Smalltalk's development environment. While memory images offer performance gains and eliminate database mapping complexity, they require careful handling of event migration and concurrency. Fowler suggests that increasing memory sizes and the NOSQL movement may drive renewed interest in this historically niche pattern.

Key Insight: Software patents have been so thoroughly debased from their original purpose of rewarding genuine novelty that they now actively impede the innovation they were designed to encourage.

Fowler argues that while patents were historically one of humanity's most valuable inventions—enabling the Industrial Revolution by incentivizing innovation—software patents have become an 'unmitigated disaster.' He traces patents' original purpose through William Rosen's analysis of how they fueled unprecedented economic change in 18th century England. However, software patents have abandoned the core principle of novelty, routinely granting monopolies on obvious or already-existing techniques. The result is a system that stifles rather than encourages innovation, weaponized for legal battles and shakedowns against smaller companies, and Fowler concludes we'd be better off eliminating software patents entirely than continuing with the current broken system.

Key Insight: Quality podcasts that excel at storytelling and explanation provide valuable ways to stay informed across both professional and personal interests.

Martin Fowler shares his recommended podcasts across various genres, from storytelling and science to economics and software engineering. He highlights This American Life and Radio Lab as joint favorites with his wife, praising their storytelling craft and innovative audio design. For professional development, he recommends Software Engineering Radio as a way to stay current with industry developments. The post also covers educational podcasts on economics, history of ideas, and literature, reflecting Fowler's broad intellectual interests beyond software.

Key Insight: Version control tools can only solve textual conflicts; semantic conflicts require self-testing code and continuous integration to catch, making feature branching inherently risky regardless of tooling sophistication.

Fowler argues that while modern version control tools have made textual merging easier, they cannot solve semantic conflicts—situations where code merges cleanly but behaves incorrectly. He illustrates this with examples like method renaming and extracting side effects, where parallel development creates integration bugs that won't be caught by merge tools. The post advocates for self-testing code and frequent integration as the primary defenses against semantic conflicts, reinforcing his long-standing position against feature branching.

Key Insight: The choice of version control tool matters less than the practices and workflows teams adopt—Continuous Integration with any capable tool beats a powerful tool used poorly.

Fowler evaluates version control tools based on developer experience, recommending Subversion, Git, and Mercurial as the only tools that pass his 'recommendability threshold.' He criticizes ClearCase and TFS for poor capability, and Visual Source Safe as particularly dangerous. The choice between centralized (Subversion) and distributed (Git/Mercurial) depends on team skill and discipline, with DVCS requiring more maturity to avoid 'merge doom.' Between Git and Mercurial, Git offers more power but less usability, while GitHub's ecosystem gives Git a significant advantage. Ultimately, practices and workflows matter more than tools themselves.

Key Insight: APIs should make the distinction between reading and mutating state syntactically obvious, because these operations have fundamentally different consequences.

Fowler critiques the JavaScript/jQuery convention of using the same function name for both getting and setting values, a pattern borrowed from Smalltalk. He argues that retrieving data is fundamentally different from setting it, so methods should have distinct names. The overloaded approach creates ambiguity, especially when getters take arguments, making it unclear whether a call is reading or mutating state. He prefers languages like C# and Ruby that use property syntax with assignment operators to clearly signal mutation. For JavaScript, he recommends bare getters with prefixed setters (e.g., height() and setHeight()). While acknowledging the importance of following language conventions, he notes JavaScript lacks strong conventions, making this a case where deviation is justified.

Key Insight: Painful development activities often have exponential pain-to-delay relationships, so doing them more frequently transforms them from dreaded ordeals into routine non-events through decomposition, feedback, and practice.

Fowler explains his counterintuitive principle that painful activities become easier when done more frequently rather than avoided. Using integration as the primary example, he shows how the pain-to-time relationship is exponential, meaning frequent small integrations hurt far less than infrequent large ones. He identifies three mechanisms behind this effect: decomposition into manageable chunks, faster feedback loops for course correction, and practice leading to process improvement and automation. The principle applies broadly across agile practices including testing, refactoring, database migrations, and releases.

Key Insight: CQRS is a powerful pattern for specific complex domains and high-performance scenarios, but its overuse on systems that fit a simpler CRUD model has caused more harm than good in most real-world implementations.

CQRS (Command Query Responsibility Segregation) splits a system's conceptual model into separate models for updates (commands) and reads (queries), rather than using a single CRUD-based model for both. While this separation can be valuable for complex domains or high-performance applications with disparate read/write loads, Fowler strongly cautions that CQRS adds significant complexity and should only be applied to specific bounded contexts where the benefit justifies the cost. He notes that most systems fit a CRUD model well, and the majority of CQRS implementations he's encountered have caused serious difficulties rather than improvements.

Key Insight: Effective persuasive presentations for small groups require a fundamentally different approach than large-audience talks, using narrative tension cycles and detailed printed materials rather than projected slides.

Martin Fowler reviews 'The Presentation' by Andrew Abela, which advocates for a distinct approach to small-group persuasive presentations. The book distinguishes between 'ballroom' presentations for large audiences and 'conference room' presentations aimed at convincing small groups to take specific actions. The core technique uses a SCoRE narrative structure (Situation, Complication, Resolution, Example) that cycles through problems and solutions. Rather than projected slides, Abela recommends detailed printed materials that pass the 'squint test' for overall structure while containing supporting evidence. Fowler finds the approach valuable while noting it's one of many presentation styles, and compares it to a military approach using prose handouts read before meetings.

Key Insight: By understanding how modern CPUs actually work and following the single-writer principle, you can achieve massive throughput with simple single-threaded code that outperforms complex concurrent systems.

LMAX is a retail financial trading platform that processes 6 million orders per second on a single thread, defying conventional wisdom about concurrent programming. The architecture centers on a Business Logic Processor that runs entirely in-memory with no database, using Event Sourcing for durability and recovery. Input and output operations are handled by custom concurrent components called Disruptors, which avoid traditional queue bottlenecks through careful attention to CPU cache behavior. The team arrived at this design after discovering that actor-model approaches spent more time managing queues than processing business logic, leading them to embrace 'mechanical sympathy' with modern hardware.

Key Insight: Equipment upgrades often matter less than we convince ourselves they do, but the psychological satisfaction and workflow changes they enable can still be worthwhile.

Martin Fowler discusses his decision to add a Canon 70-300mm telephoto lens to his photography kit. After weighing options between upgrading his mid-range zoom or telephoto capabilities, he chose the 70-300 for its lighter weight, faster autofocus, and lower cost compared to alternatives. The purchase changed his shooting habits - he now typically carries the ultra-wide 10-22 and the 70-300, finding the mid-range gap less problematic than expected since he can crop wider shots. He keeps a compact camera as backup for spontaneous moments when lens changes would slow him down.