Here it is: 20+ years of programming experience distilled into 378 words. From the book I'm writing.
How do you decide what goes in a library and what goes in a vertical module?
Few hard rules exist, but there are guidelines. In Laws of Software Evolution, Lehman classified programs into 3 categories βΒ S-programs, P-programs, and E-programs. The naming didn't survive, but the idea did:
Software is built on components that are context-independent and those that evolve together with the business domain. These days we call them atoms, molecules, and organisms. Brad Frost popularized this naming as Atomic Design in the UI world, but the concept has helped me at every level of a software product.
- An atom is a component that works the same in any context. Its behavior is fully captured by a spec and can be exhaustively verified. It maps inputs to outputs and doesn't much care what they mean conceptually. Like a button or date library.
- A molecule is a self-contained piece of code that encapsulates a behavior with some business rules. It aims to achieve a goal and may be wrong despite having zero bugs. These are your higher level abstractions like a user profile component or a payments module. Reusable, but bring a lot of their own context.
- An organism combines molecules and atoms into a cohesive whole that encapsulates a business process. These are larger systems that own a business domain start to finish. Like a checkout component or shipping module.
These groupings don't have strict boundaries and they're somewhat fractal in nature. What counts as an atom or a molecule depends on the level of abstraction you're talking about. When building a webapp, the button is an atom, but to your CEO, the whole webapp might be an atom in a broader strategy.
For engineering, I think of atoms as reusable building blocks, molecules as self-contained reusable components, and organisms as modules or services that own a domain. The main distinction is how they accept arguments:
- atoms take base types with little semantic information
- molecules take domain objects and understand the context
- organisms take user actions and figure out the rest
This informs how you test things β unit tests for atoms, integration tests for molecules, observability and metrics for organisms. It also informs where data comes from βΒ atoms don't care, molecules get rich objects, organisms fetch their own.
Cheers,
~Swizec
Continue reading about Atoms, molecules, organisms
Semantically similar articles hand-picked by GPT-4
- The Laws of Software Evolution
- Finding modules in a big ball of mud
- Empirical evidence for code modularity
- Why even care about code structure
- What I learned from Software Engineering at Google
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below π
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails π on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. π"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help π swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers π ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are β€οΈ