--- title: Software Architecture's Biggest Enemy (Not What You Think) description: Coupling is the single biggest factor in the cost of software change. Rather than eliminating it (impossible), the goal is to manage it deliberately. Michael... canonical: https://daily.dev/posts/software-architecture-s-biggest-enemy-not-what-you-think--y3fextm0t twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Software Architecture's Biggest Enemy (Not What You Think) | daily.dev og:description: Coupling is the single biggest factor in the cost of software change. Rather than eliminating it (impossible), the goal is to manage it deliberately. Michael... og:url: https://daily.dev/posts/software-architecture-s-biggest-enemy-not-what-you-think--y3fextm0t og:image: https://api.daily.dev/og/posts/Y3FexTM0T.png og:image:alt: Software Architecture's Biggest Enemy (Not What You Think) og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Software Architecture's Biggest Enemy (Not What You Think) **[Continuous Delivery](https://daily.dev/sources/continuousdelivery)** · 18 min read · 54 upvotes · 1 comments ## Summary Coupling is the single biggest factor in the cost of software change. Rather than eliminating it (impossible), the goal is to manage it deliberately. Michael Nygard's five types of coupling provide a useful framework: operational (runtime dependency), developmental (must change together), semantic (shared meaning without shared code), functional (duplicate logic that drifts apart), and incidental (accidental, no justification). Strong coupling to stable things is fine; coupling to unstable, invisible, or unintended things is what causes pain. Two tools exist to cope: better design (information hiding, event-driven architecture, API boundaries) and faster feedback (continuous integration). The danger zone is strong coupling combined with slow feedback — the 'big ball of mud' — which teams drift into accidentally. TDD is highlighted as a practical coupling detector, since hard-to-write tests signal excessive dependencies. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### what are the five types of coupling according to Michael Nygard's framework Michael Nygard, author of Release It, categorizes coupling into five types: operational (runtime dependency between consumer and provider), developmental (components that must change together), semantic (shared meaning of concepts without shared code), functional (multiple implementations solving the same problem inconsistently), and incidental (accidental coupling with no design benefit, like a module reaching across the system unnecessarily). _daily.dev surfaces architecture deep dives for engineers working through coupling and system design trade-offs._ ### why is strong coupling sometimes acceptable in software design Strong coupling is acceptable when the thing being coupled to is stable, such as SQL, which barely changes year to year, making heavy dependence on it low-risk. The real danger is coupling to something unstable, like a rapidly evolving application database schema, since the same strength of coupling carries very different risk depending on stability. _track which dependencies are safe to couple tightly to by following architecture discussions on daily.dev._ ### what combination of coupling and feedback speed creates a legacy big ball of mud system Strongly coupled systems combined with slow feedback create the disaster zone, essentially the definition of a big ball of mud legacy system, where changes are dangerous and releases are fearful. The other three combinations of coupling and feedback speed are survivable: decoupled with fast feedback, decoupled with slow feedback (classic microservices), and coupled with fast feedback (good continuous integration). _developers weighing microservices versus continuous integration strategies can find more architecture guidance on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@petercheung** · 1 upvotes > i think hong kong is already broken these 5 coupling rules. Whatevery the softwares are coupling or decoupling, no way to maintanence them. --- Tags: [#architecture](https://daily.dev/tags/architecture), [#cicd](https://daily.dev/tags/cicd), [#microservices](https://daily.dev/tags/microservices), [#tdd](https://daily.dev/tags/tdd) [View this post on daily.dev](https://daily.dev/posts/software-architecture-s-biggest-enemy-not-what-you-think--y3fextm0t) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Software Architecture's Biggest Enemy (Not What You Think)","url":"https://daily.dev/posts/software-architecture-s-biggest-enemy-not-what-you-think--y3fextm0t","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/software-architecture-s-biggest-enemy-not-what-you-think--y3fextm0t"},"datePublished":"2026-07-01T18:14:36.132Z","dateModified":"2026-09-14T09:07:12.149Z","description":"Coupling is the single biggest factor in the cost of software change. Rather than eliminating it (impossible), the goal is to manage it deliberately. Michael...","image":"https://i.ytimg.com/vi/grPtnrOTP_4/sddefault.jpg","thumbnailUrl":"https://i.ytimg.com/vi/grPtnrOTP_4/sddefault.jpg","isAccessibleForFree":true,"articleSection":"Continuous Delivery","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Continuous Delivery","logo":"https://media.daily.dev/image/upload/s---b6TAqpH--/f_auto/v1730404995/logos/continuousdelivery","url":"https://daily.dev/sources/continuousdelivery"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/software-architecture-s-biggest-enemy-not-what-you-think--y3fextm0t","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":54},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"architecture,cicd,microservices,tdd","timeRequired":"PT18M","video":{"@type":"VideoObject","name":"Software Architecture's Biggest Enemy (Not What You Think)","description":"Coupling is the single biggest factor in the cost of software change. Rather than eliminating it (impossible), the goal is to manage it deliberately. Michael...","thumbnailUrl":"https://i.ytimg.com/vi/grPtnrOTP_4/sddefault.jpg","uploadDate":"2026-07-01T18:14:36.132Z","duration":"PT18M","url":"https://api.daily.dev/r/Y3FexTM0T","embedUrl":"https://www.youtube.com/embed/grPtnrOTP_4"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Continuous Delivery","item":"https://daily.dev/sources/continuousdelivery"},{"@type":"ListItem","position":3,"name":"Software Architecture's Biggest Enemy (Not What You Think)"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/software-architecture-s-biggest-enemy-not-what-you-think--y3fextm0t","comment":[{"@type":"Comment","text":"i think hong kong is already broken these 5 coupling rules. Whatevery the softwares are coupling or decoupling, no way to maintanence them.","datePublished":"2026-07-03T04:12:48.705Z","url":"https://daily.dev/posts/Y3FexTM0T#c-KbpMgl95V","author":{"@type":"Person","name":"Peter Cheung","url":"https://daily.dev/petercheung","image":"https://lh3.googleusercontent.com/a/ACg8ocI-jk0hCrzyGwbK3v4C_UNMCXAe6FbRQjL_Z_54ywvVMjaCIRLxBw=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/software-architecture-s-biggest-enemy-not-what-you-think--y3fextm0t#faq","mainEntity":[{"@type":"Question","name":"what are the five types of coupling according to Michael Nygard's framework","acceptedAnswer":{"@type":"Answer","text":"Michael Nygard, author of Release It, categorizes coupling into five types: operational (runtime dependency between consumer and provider), developmental (components that must change together), semantic (shared meaning of concepts without shared code), functional (multiple implementations solving the same problem inconsistently), and incidental (accidental coupling with no design benefit, like a module reaching across the system unnecessarily). daily.dev surfaces architecture deep dives for engineers working through coupling and system design trade-offs."}},{"@type":"Question","name":"why is strong coupling sometimes acceptable in software design","acceptedAnswer":{"@type":"Answer","text":"Strong coupling is acceptable when the thing being coupled to is stable, such as SQL, which barely changes year to year, making heavy dependence on it low-risk. The real danger is coupling to something unstable, like a rapidly evolving application database schema, since the same strength of coupling carries very different risk depending on stability. track which dependencies are safe to couple tightly to by following architecture discussions on daily.dev."}},{"@type":"Question","name":"what combination of coupling and feedback speed creates a legacy big ball of mud system","acceptedAnswer":{"@type":"Answer","text":"Strongly coupled systems combined with slow feedback create the disaster zone, essentially the definition of a big ball of mud legacy system, where changes are dangerous and releases are fearful. The other three combinations of coupling and feedback speed are survivable: decoupled with fast feedback, decoupled with slow feedback (classic microservices), and coupled with fast feedback (good continuous integration). developers weighing microservices versus continuous integration strategies can find more architecture guidance on daily.dev."}}]} ```