{ "version": "https://jsonfeed.org/version/1", "title": "Lance Newman", "icon": "https://avatars.micro.blog/avatars/2026/25/1927200.jpg", "home_page_url": "https://www.lancenewman.com/", "feed_url": "https://www.lancenewman.com/feed.json", "items": [ { "id": "http://lancenewman.micro.blog/2026/07/07/ownership-is-not-a-modularization.html", "title": "Ownership is not a modularization problem", "content_html": "

Ownership is an organizational question, not a problem to be solved with modular implementation.

\n

A lack of clear ownership shouldn’t be a motivator to seek out the mythical modular monolith, but in my experience it seems to be a primary driver for modularization in growing enterprises. Well-defined modules can help make codifying ownership easier, but you don’t need them to decide who is responsible for something.

\n

Modularizing a monolith is difficult. Working with stakeholders to choose appropriate context boundaries for an application’s domains can take years for monoliths that have exploded in complexity over a decade. Unfortunately, a 3:00 AM alert for an exception thrown by a shared bit of code doesn’t wait until refactoring can be prioritized. Someone still has to own it and respond, so these problems are usually offloaded onto a tired staff engineer or left to languish until your bug backlog has hundreds of unhandled exceptions that need to be addressed.

\n

Make an ownership decision even when the path towards true context separation is unclear or in progress. You’ll probably pick the wrong owner more than once, but documenting who owns a file or directory doesn’t change any code so the decision is inexpensive. Define who owns code before modularizing it and you’ll find that you have teams with the agency and responsibility to improve it.

\n", "date_published": "2026-07-07T15:27:17-04:00", "url": "https://www.lancenewman.com/2026/07/07/ownership-is-not-a-modularization.html", "tags": ["Software Engineering"] } ] }