December 11, 2019

443 words 3 mins read

Atomic design as a migration strategy

Atomic design as a migration strategy

Atomic design is well suited for migrating web applications. Because you build complexity out of simple components, you can start small and slowly carve out your application. Harrison Harnisch shares how Buffer is migrating six years of development with atomic design.

Talk Title Atomic design as a migration strategy
Speakers Harrison Harnisch (Buffer)
Conference O’Reilly Fluent Conference
Conf Tag The Web Platform in Practice
Location San Jose, California
Date June 20-22, 2017
URL Talk Page
Slides Talk Slides
Video

Atomic design is well suited for migrating web applications. Because you build complexity out of simple components, you can start small and slowly carve out your application. Harrison Harnisch shares how Buffer is migrating its codebase with atomic design. Over the past six years at Buffer, 60 contributors have generated over 50,000 commits. Buffer had been seeing diminishing returns in developer productivity and performance from its codebase built on PHP and Backbone, so it decided to update its stack. Migrating a large codebase can be very challenging. Doing a full rewrite in a separate repository would require splitting resources in a way that would delay features and fixes in the old application and slow down development on the new application. It’s also very likely that regressions would occur. There is something to be said about having a clean slate to work with. It means you don’t have to compromise on architecture and design. This is where atomic design principles shine. With atomic design, you can slowly migrate to a greenfield application. Atomic design defines the most basic building block as an atom. Atoms can be joined together to build more complex components like forms or search bars. The process of migration starts with a simple atom (like a button) that can replace a small part of your old application and simultaneously be added to the new application. You then build a few more atoms (like an input and a label) and stitch them together to make a molecule (perhaps a form). The molecule is added to the old application, replacing just a little more functionality while also being added at the same time to the greenfield application. This process is repeated until there is just the shell of the old application. When the shell is the only thing left, it’s possible to swap out the old application for the new one. Migrating with atomic design enables the development team to move at a natural pace while continuously delivering value. The process spreads out regressions and bugs over time, reducing the risk of fire drills and pager duty alerts at launch, meaning that development teams can build on momentum rather than fear of missing deadlines.

comments powered by Disqus