> Markdown version of [/videos/206-move-fast-with-software-architecture](https://www.wearedevelopers.com/videos/206-move-fast-with-software-architecture). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md). --- # Move fast with Software Architecture Does sacrificing software design actually make you ship faster? Discover why technical debt kills velocity and how hexagonal architecture lets you safely sustain rapid delivery. - **Speakers:** Simon Lasselsberger - **Event:** World Congress 2021 - **Published:** July 1, 2021 - **Duration:** 42:02 - **URL:** https://www.wearedevelopers.com/videos/206-move-fast-with-software-architecture ## Summary While "move fast and break things" is a classic startup mantra, breaking things uncontrollably is an expensive waste of momentum. A more sustainable approach is to move fast, be strategic, and isolate errors by breaking only a few things. Software architecture is essentially the shared understanding of a system's design, fundamentally prioritizing whatever makes change easy and addressing the decisions that are hard to reverse later. Because software lives in a dynamic environment, a town planner's adaptable mindset is a far better analogy for architecture than static civil engineering. The architect is less of a rigid job title and more of a collaborative role that bridges technical execution with overarching business goals, requiring strong people skills to foster alignment across the organization and adhere to Conway's Law. Development velocity is intrinsically tied to internal code quality. According to the Design Stamina Hypothesis, sacrificing design for raw feature output only yields a faster pace for the first few weeks of a project. Soon after, the crippling weight of technical debt acts like a messy kitchen, imposing a steep "interest rate" on every subsequent code change until velocity flatlines. Rather than halting everything for a risky "stop-the-world" complete rewrite, teams must iteratively pay down debt to survive. Engineers on understaffed teams can secure buy-in for refactoring by directly quantifying the hours lost to painful developer experiences, framing the cost of technical debt in terms that product stakeholders understand. To safely sustain rapid delivery, isolating functional domains is paramount. Utilizing hexagonal architecture—also known as the ports and adapters pattern—protects core business logic from external dependencies like databases, user interfaces, or delivery mechanisms. By defining strict bounded contexts aligned with Domain-Driven Design, engineering teams can deploy fast-paced, high-risk product experiments alongside critical core systems. If a hastily built feature accumulates massive technical debt or simply fails to find market fit, its finite blast radius ensures the robust core application remains pristine. Ultimately, modular software design provides the structural boundaries required to move incredibly fast while radically reducing the consequences of failure. **Keywords:** software architecture, technical debt management, design stamina hypothesis, hexagonal architecture, ports and adapters pattern, bounded contexts, domain-driven design, internal software quality, iterative refactoring, conway's law, microservices isolation, system design communication, engineering delivery speed, product stakeholder buy-in, startup development process, monolith modularity ## Chapters 1. **Moving fast and reducing the cost of errors** (00:02) — Strategic software architecture allows teams to move fast by limiting the scope and impact of product failures. 1. **Defining software architecture and shared system understanding** (01:20) — True software architecture goes beyond technical documents to establish a shared understanding of decisions that are hard to change later. 1. **Recognizing technical components and proper engineering process alignment** (03:47) — Creating an architecture that accommodates change involves organizing high-level capabilities alongside specific communication patterns defined by conways law. 1. **Shifting software design paradigms from engineering to town planning** (06:15) — Town planning better represents the dynamic need to accommodate both legacy structures and future growth in evolving software systems. 1. **Navigating the software architect role and daily team responsibilities** (09:17) — The software architect role focuses on fostering team understanding and driving scalable logic via strong collaboration skills. 1. **Examining the design stamina hypothesis and long-term development speed** (10:44) — Investing continuous effort in internal software quality preserves long-term development speed despite an initial slower pacing. 1. **Managing technical debt accumulation and unpredicted feature delivery delays** (15:09) — Accumulating technical debt requires paying continuous system interest through slower development cycles before architectural progression becomes impossible. 1. **Addressing legacy codebases through iterative microservices framework migration** (19:06) — Iteratively isolating architecture components proves safer and more highly effective than stopping everyday product work to perform a complete system rewrite. 1. **Implementing hexagonal architecture patterns for business logic isolation** (22:21) — The classic hexagonal architecture pattern directly protects core business logic by decoupling dependencies using targeted system ports and external adapters. 1. **Modularity limits the application blast radius and technical debt** (27:23) — Isolating capabilities with bounded contexts naturally protects core system functions from flawed experimental features and spontaneous technical failures. 1. **Discussing pragmatic architectural scope reduction and system design patterns** (32:36) — Combining domain driven design with properly sized bounded contexts successfully scales technical operations without prematurely overcomplicating system prototypes. 1. **Securing architectural investment time on understaffed software engineering teams** (38:47) — Highlighting specific developer time losses caused by unstructured code solidifies the business case for allocating engineering resources toward sustainable architecture. ## Related Moments - [Managing technical debt with sensible software architecture](https://www.wearedevelopers.com/videos/608-throwing-off-the-burdens-of-scale-in-engineering) (from "Throwing off the burdens of scale in engineering") - [How the inevitable march of time breaks software patterns](https://www.wearedevelopers.com/videos/647-defeat-that-legacy-monster-guerilla-refactoring-with-web-standards) (from "Defeat that legacy monster! Guerilla refactoring with web standards") - [Building engineering cultures that support long-term software architecture](https://www.wearedevelopers.com/videos/1998-from-code-to-culture-why-leadership-determines-software-quality) (from "From Code to Culture: Why Leadership Determines Software Quality") - [Strategic use of technical debt for fast prototyping](https://www.wearedevelopers.com/videos/1405-fireside-chat-with-werner-vogels-vp-cto-amazon-com-daniel-gebler-cto-at-picnic) (from "Fireside Chat with Werner Vogels, VP & CTO, Amazon.com & Daniel Gebler, CTO at Picnic") - [Understanding the role of software architecture and quality](https://www.wearedevelopers.com/videos/1684-modern-software-architectures) (from "Modern software architectures") - [Building and maintaining sustainable software architectures](https://www.wearedevelopers.com/videos/411-it-s-all-about-the-domain-honey-experiences-from-15-years-of-domain-driven-design) (from "It’s all about the domain, honey ! Experiences from 15 years of Domain-Driven Design") ## Related Articles - [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering) - [Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)](https://www.wearedevelopers.com/magazine/745-why-event-driven-architecture-isn-t-about-speed-and-when-you-actually-need-it) - [Get Old, go Slow, Write Code!](https://www.wearedevelopers.com/magazine/81-get-old-go-slow-write-code) - [Why You Shouldn’t Build a Microservice Architecture](https://www.wearedevelopers.com/magazine/118-why-you-shouldn-t-build-a-microservice-architecture) ## Related Jobs - [Tribe Lead - ( Software) Engineering Centre of Excllence](https://www.wearedevelopers.com/jobs/ext/1475530-tribe-lead-software-engineering-centre-of-excllence) at **SD Worx** - [Senior Software Engineer, Client Apps Platform](https://www.wearedevelopers.com/jobs/ext/1773893-senior-software-engineer-client-apps-platform) at **GitHub** - [Senior Software Engineer](https://www.wearedevelopers.com/jobs/ext/15942-senior-software-engineer) at **GitHub** - [Senior Architect Realtime Bare-Metal Software](https://www.wearedevelopers.com/jobs/ext/381559-senior-architect-realtime-bare-metal-software) at **ZEISS Group** - [Principal Software Engineer, Database Infrastructure](https://www.wearedevelopers.com/jobs/ext/1465908-principal-software-engineer-database-infrastructure) at **GitHub** - [Software Solution Architekt](https://www.wearedevelopers.com/jobs/ext/1458613-software-solution-architekt) at **BWI GmbH**