I take pride in the craft of writing software. I constantly work to improve the quality of my code: to be more readable, more maintainable, etc. I want to write code that is easy to understand and easy to update or extend. I also want to write code that will be easy to delete. Wait, what? Yes. Software for the web is ephemeral. That is unless you call something a "temporary hack", then it will live for a decade. Ordinarily, software serves its purpose and then is rewritten or removed as business needs change, architectures shift, etc. I used to liken writing software for the web as constructing a sand mandala: Tibetan Buddhist monks painstakingly construct a elaborate paintings with colored sand, and, then in a moment of detachment, it is swept away. This detachment from the output of my work is liberating. Occasionally this is the case, where I dramatically delete a whole feature or section of an application in a -1500 LOC pull request, but this is rarely the life cycle of code. Often a feature sits untouched for years until a bug is found or new functionality needs to be added. I now reach for a potentially less flattering metaphor: compost.
I've heard the term "bit rot" to describe code that hasn't been touched in some period of time. Often this means an app's dependencies are out of date such that is incompatible with the latest version of a library (e.g., a component library or Node). Bit rot can also apply to a piece of functionality that hasn't been touched or maybe even looked at in years. Sometimes it's hard to understand what the code does or how it interacts with the wider app, but it's important functionality that keeps chugging along. That is until we need to update React or the component library or even a subtle long standing bug is uncovered. Now this 1500 line hard to reason about component has now rotten to the point where it impacts the application. It slows down work at best and impacts users at worst. What if we wrote code that was easy to delete? Code that degrades gracefully rather than rots? This is where the compost metaphor comes in.
Code becomes like organic material that will degrade over time, but its pieces can be used to nourish the ecosystem of the application. Much like your banana peels and coffee grounds become soil for gardens and farms. So what does compostable code look like in practice? Honestly, it's very similar to writing code that is "maintainable", but with a different orientation. These examples are front-end web focused, but the principles apply to any software. Front-end web code tends to be more ephemeral than other software.
- Small functions that do one thing. Functions built from other smaller functions. These functions can be used in other places in the application, as well.
- Presentational components that compose smaller presentational components. Rather than writing all the markup in one component, break it up into smaller components that compose together. It's easier to read and update. Components can be swapped in our out as needed. These smaller components can be used in other places in the application, as well.
- Make page layouts composable. Avoid copying layout patterns across components. Avoid layout component that has a bunch of conditional logic to render different layouts. For example, rather than a
headerandfooterprop on a layout, create small components for these that can be used across layouts. If your layout (or really any) component has a bunch of boolean props, it's probably better served by composition. - Composition over data-driven components. Rather than writing an array of 4 objects to map over to spit out some markup, create a presentational component and copy it 4 times. DRY isn't always the ideal.
- Avoid coupling. Allow components to work together, but not be dependent on each other. This way components can be swapped out or removed without impacting other components.
- Components that connect to data layer only connect data and then pass data to presentational components. This way the data layer can be swapped out without impacting the presentation layer or the other way around. This is a specific example of #4.
- Prefer some boilerplate over abstractions. Abstractions are often useful, but they can be hard to reason about. Let's say you have an application with some integrations with APIs. You have five integrations, it may be worse to write an abstraction that only pays off if integrations expand to 100+. It's okay to repeat yourself sometimes.
- Test code at lowest levels and integration points. It's important to make sure that the pieces work as intended themselves and then come together in the big picture. The integration tests may get replaced over the time, but the lower level tests will remain useful as long as the components remain in service.
It is a small coincidence that composable and compostable are one letter different. It's a happy coincidence, but composition is really one big tool of how to get this this point.
These are just examples to demonstrate the idea. What I'm describing are just good architectural practices. However, thinking of the code as compostable helps detach you from your previous work. It encourages a growth mindset of constant improvement, but in a healthier way than just rewriting code in a fit of pique. Compostable code can be deleted, but it can be repurposed as well. This enables iterative refactoring and improvement without the (always) fraught process of rewriting. It's all about creating a healthy ecosystem for your application to grow and thrive.