{"id":12027,"date":"2013-10-10T14:28:29","date_gmt":"2013-10-10T11:28:29","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=5808"},"modified":"2022-02-01T17:49:30","modified_gmt":"2022-02-01T15:49:30","slug":"because-you-are-agile-you-can-change-your-system-fast","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/because-you-are-agile-you-can-change-your-system-fast","title":{"rendered":"Agile Architecture Myths #4 Because you are agile you can change your system fast!"},"content":{"rendered":"

(Guest blog post by Rebecca Wirfs-Brock<\/a>, originally appeared on\u00a0her blog<\/a>. Republished with permission.)<\/em><\/p>\n

Agile designers embrace change. But that doesn\u2019t mean change is always easy. Some things are harder to change than others. So it is good to know how to explain this to impatient product stakeholders, program managers, or product owners when they ask you to handle a new requirement that to them appears to be easy but isn\u2019t.<\/p>\n

Joe Yoder and Brian Foote, of the\u00a0Big Ball of Mud<\/a>\u00a0fame, provide insights into ways systems can change without too much friction. They drew inspiration from Stuart Brand\u2019s\u00a0How Buildings Learn<\/a>. Brand explains that buildings are made of components organized into shearing layers. He identifies six layers: the site, the structure, the skin, the services, the space plan, and physical stuff in the building.
\n\"\"<\/a>
\nEach shearing layer has its own value and speed of change, or pace. According to Brand, buildings are able to adapt because faster changing layers (e.g. the services layers and spaces) are purposefully designed so to not be obstructed by slower changing layers. If you design your building well, it is fairly easy to change the plumbing. Much easier than revising the foundation. And it is even easier to rearrange the furniture. Sometimes designers go to extra efforts to make a component easier to change. For example, most conference centers are designed so that sliding panels form walls that allow inside space to be quickly modified.<\/p>\n

Brand\u2019s ideas should\u2019t be surprising to software developers who follow good design practices that enable us to adapt our software: keep systems modular, remove unnecessary dependencies between components, and hide implementation details behind stable interfaces.<\/p>\n

Foote and Yoder\u2019s advice for avoiding tangled, hard-to-change software is to, \u201cFactor your system so that artifacts that change at similar rates are together.\u201d They also present a chart of typical layers in a software system and their rates of change:
\n\"\"<\/a>
\nFrequently, we are asked to support new functionality that requires us to make changes deep in our system. We are asked to tinker with the underlying (supposedly slower changing) layers that the rest of our software relies upon. And often, we do achieve this miraculous feat of engineering because interfaces between layers were stable and performed adequately. We got away with tinkering with the foundations without serious disruption. But sometimes we aren\u2019t so lucky. A new requirement might demand significantly more capabilities of our underlying layers. These types of changes require significant architectural rework. And no matter how matter how agile we are, major rework requires more effort.<\/p>\n

Because we are agile, we recognize that change is inevitable. But embracing change doesn\u2019t make it easier, just expected. I\u2019d be interested in hearing your thoughts about Foote and Yoder\u2019s shearing layers and ways you\u2019ve found to ease the pain of making significant software changes.<\/p>\n

\n

Would you like to improve the architecture and design of your project?\u00a0We can help with:<\/em><\/p>\n