Rewilding Software Engineering: Debunking the Eight Myths That Shape Our Craft

Software engineering operates in a realm of invisible knowledge work, where progress, quality, and risks remain elusive compared to tangible disciplines like bridge construction or factory operations. This invisibility creates a vacuum that simple narratives fill with myths—the 10x engineer, the genius founder, "move fast and break things." In this chapter, Tudor Girba and Simon Wardley systematically dismantle eight pervasive myths about software engineering itself, revealing how these misconceptions hinder our evolution toward true engineering discipline.

Myth 1: Software Engineering is About Building Functionality

The first and most fundamental myth conflates software engineering with mere functionality creation—writing code that transforms inputs into outputs per specification. The authors challenge this through their calendar application experiment from Chapter 4, where seven teams produced functionally equivalent calendar systems with radically different internal structures. This demonstrates that structure evolves independently of functionality.

Why does structure matter? Because systems exist within evolving economic and technological landscapes. Consider how supermarket bar codes revolutionized inventory management in the 1970s—systems had to adapt not through new functionality but through structural changes to accommodate this new concept. The difficulty of adapting a system depends entirely on its existing structure, not its functionality.

When the authors ask teams to split their monolithic calendar applications into scalable components, the effort required varies dramatically based on dependency structures. Team A's system (bottom-right in Figure 51) splits cleanly with minimal dependency crossings, while Team B's system (top-left) requires massive restructuring. This reveals that software engineering encompasses more than building—it includes refactoring, and more than functionality—it includes structure.

The legacy problem emerges when structural debt accumulates because organizations prioritize new features over structural maintenance. The authors argue that refactoring must become inexpensive through automation. Their reference to Brant & Roberts' 2010 study shows that large-scale transformations are possible through systematic micro-automations, challenging the notion that legacy systems are inherently intractable.

Myth 2: Refactoring is Not a Business Problem

This myth frames refactoring as purely technical work, divorced from business concerns. The authors counter by arguing that modern organizations encode their core knowledge not in documents or people's minds, but within software structures. This knowledge remains critical for value creation through streamlining and recombination.

They illustrate this with a pandemic-era case study: a $10B+ retailer attempting to modernize their customer database. After six months and significant resources, they still lacked basic understanding of which systems used the database. The problem wasn't code writing—it was decoding the knowledge embedded in the system.

The turning point came when external experts instrumented the database and microservices for just one business cycle. By analyzing query logs and correlating data sources, they produced an accurate architectural map (Figure 52) in one month with two people. The left side of the figure shows what management believed the system was; the right shows reality. This demonstrates that refactoring is fundamentally a business activity about reshaping encoded knowledge, not a technical exercise in code rewriting.

Myth 3: Software Engineering is an Engineering Practice

While software engineering should be an engineering discipline, most of it remains a craft. The authors examine testing and development separately to show this divergence.

Testing has evolved into an engineering practice through test-driven development (TDD). Early testing relied on gut feel and manual checklists. TDD transformed it by embedding system understanding into test suites—thousands of small, contextual tests that model the system. As the authors note, "the best specification is the test suite." This systematic approach, with its red-green-refactor cycle, represents true engineering: hypothesis-driven exploration using contextual tools.

Development, however, remains largely craft-based. Even with TDD, developers switch to monolithic coding environments, manually inspect code, and rely on diagrams that often represent beliefs rather than facts. The exploration remains ad-hoc until "gut feeling" suggests a solution.

The authors propose that development must follow testing's path: building thousands of small, contextual tools for each problem. This "moldable development" approach would elevate development to engineering status. They reference their "two wolves" framework:

1. Wolf 1: Challenging the view of software engineering as primarily a decision-making process
2. Wolf 2: Challenging how we ask and answer questions, demonstrating the need for contextual tools

Critically, they argue that monolithic tools—even those enhanced with LLMs—prevent this evolution. True engineering requires abandoning one-size-fits-all tools in favor of problem-specific tool suites.

Myth 4: LLMs Will Replace Software Engineers

The authors dismiss the common AI replacement narrative with three counterpoints:

1. Jevon's Paradox: Efficiency gains increase demand, requiring more engineers, not fewer
2. Red Queen Effect: Organizations must adopt AI to compete, but this doesn't eliminate engineering
3. Centaur Chess: Human-AI collaboration outperforms either alone

Their practical experiment with the Glamorous Toolkit reveals LLMs' limitations. When asked to map component dependencies, the LLM produced a plausible but inaccurate result—missing components, hallucinating relationships, and achieving only 70-95% accuracy. The error rate is problematic because you cannot know what's wrong without contextual tools, and manual verification defeats the purpose.

The authors propose a better path: using LLMs to generate contextual tools rather than answers. When they modified their prompt to request code that retrieves dependencies, the LLM produced a working snippet on the first try. This approach leverages LLMs' strengths (hypothesis creation, specific coding) while maintaining engineering rigor.

Myth 5: Architects Make Decisions

Traditional architectural diagrams are "statements of belief"—what we wish the system were, not what it is. The only architecture that matters is the one encoded in code, making developers the true architects.

The authors argue that architecture emerges through three activities:

1. Knowing where you are (assessment)
2. Choosing where to go (design)
3. Ensuring you go there (assessment)

Only the second involves traditional design; the first and third require system visibility. Without the ability to generate architectural diagrams from the system itself, developers operate in fear, unwilling to change poorly understood critical systems.

They critique specification-driven development using the ZX80/BASIC analogy: while BASIC was more abstract than assembly, its translation to machine code was deterministic and preserved semantics. LLM prompt-to-code translation is probabilistic and doesn't guarantee semantic preservation. This makes specification-driven development a "learning tool" rather than a production methodology.

The authors warn that removing human comprehension from the decision-making process creates systemic risk, referencing Knight Capital's $440 million loss in 45 minutes due to misunderstood system behavior. Comprehension is the scaffolding that makes safety, accountability, and learning possible.

Myth 6: Dealing with Legacy is Hard

Lifeware, a SaaS provider for insurance companies, achieves 100% success in migrating legacy systems—dramatically outperforming the industry's 26% success rate. Their secret? Three decades of investment in engineering practices:

• 160,000 tests for a 35M-line system, running in minutes on AWS clusters
• 3,000+ contextual micro-tools built with moldable development
• Fully integrated development environments that never require leaving the system

This contrasts sharply with DORA 2025 and METR studies showing that AI tool adoption correlates with perceived productivity gains but actual slowdowns and increased instability. The authors conclude that investment in engineering practices is the better bet because engineering fundamentals don't change with technology trends.

Myth 7: Non-Technical People Can't Understand Code

This myth confuses interface limitations with inherent complexity. The authors reference Xerox PARC's Smalltalk system, where children could understand and manipulate systems through graphical interfaces, versus text-based systems requiring technical expertise.

The key insight: interfaces determine who can understand a system. With moldable development, any system aspect can be presented through tools accessible to various audiences. They demonstrate this with treemap visualizations of the Glamorous Toolkit's structure, showing which parts have contextual tools (Figure 59).

Most compellingly, they show how the Squarified Treemap algorithm—760 lines of complex code—can be understood through visual step-by-step depictions (Figure 60-61). Non-technical users can participate in technical discussions when given appropriate interfaces. The visual revealed a flaw in the original paper's algorithm interpretation, discovered by someone who wasn't the original developer.

Myth 8: Technical Debt Exists

Ward Cunningham's 1992 "technical debt" metaphor was brilliant—a single term bridging technical and business communication about structural misalignment. However, it has become an "imaginary scalar" compressing multiple dimensions (function, structure, context, skills, tools) into one misleading number.

The authors argue technical debt is imaginary because:

1. It's compressible: Changing tools or skills can make "debt" disappear (e.g., automatic refactoring eliminated naming debt)
2. It's negative-framed: Always trying to reduce debt drives outsourcing and cost-cutting rather than strategic investment
3. It's reductive: Complex multi-dimensional problems deserve better metrics

Lifeware's success shows that investing in engineering practices can transform legacy systems into competitive advantages, making the "debt" metaphor obsolete. The authors propose we outgrow this 30-year-old metaphor and embrace more nuanced ways of discussing system evolution.

The Path Forward

These eight myths all trace back to our "missing wolves"—the failure to view software engineering as decision-making and to recognize the need for contextual tools. The authors propose:

1. Embrace moldable development: Build thousands of micro-tools tailored to specific problems
2. Use LLMs strategically: As tool generators, not answer providers
3. Maintain human comprehension: Keep humans in the decision-making loop for safety and accountability
4. Invest in engineering practices: Prioritize systematic approaches over shortcuts

The homework assignment challenges teams to apply these insights: pick a legacy system, determine its business value, and examine how changing context, skills, and tools could transform perceived "technical debt" into competitive advantage.

Ultimately, the authors argue that software engineering's future lies not in replacing humans with AI, but in amplifying human judgment through better engineering practices and contextual tools. This is the path from craft to engineering—from invisible knowledge work to visible, manageable, and joyful creation.

For further reading, explore the Glamorous Toolkit project, which embodies many of these principles, or dive into Simon Wardley's mapping techniques for contextual understanding of technology landscapes.