This is the third part of a trilogy of articles addressing the pitch deck to the usable product impedance mismatch all startups face.
If you missed them, here are part one and part two.
Welcome back. It looks like you’re serious about this. This article is for builders like you. What parts from the second instalment of this article did you implement?
Last time, we discussed how one could leverage the “Divide & Conquer” pattern to seemingly unfathomable problems by chunking them into resilient, reusable, self-sufficient blocks of varying sizes.
Today, we’ll discuss instances where, instead, it makes sense to slice in homogenous chunks of approximately equivalent size as there’s no obvious point where the cut is the most appropriate.
Design System Iconography
Setting up and beefing up design systems would fall onto my plate in most early-stage startups. Although many activities in the design system work comply with the CDD (Component-Driven Development) paradigm, as discussed in the second part, a whole class of subtasks requires the execution of repetitive motions that can’t be entirely automated. In such cases, it makes sense to divide into chunks of equivalent or similar size and work through the entire list slice by slice.
Iconography example. Source: storybook.js.orgA glaring example of such a sub-task is iconography. When the designer has to adjust the impedance mismatch between the icons set that is “almost there“ but not quite, he has to get the icons through his grinder one by one, adjusting sizes, tones, stroke widths, formats, etc. This is where it’s essential to find a good playlist that’ll make time go by quickly.
Converting Existing Infrastructure to IaC
Describing your cloud infrastructure as code is something I recommend you start doing as soon as you begin erecting it. However, personal experience shows that, in most cases, you’ll start working with an existing setup.
// Pull-in existing resources and gradually replace them with
// new ones.
this.vpc = Vpc.fromLookup(this, 'ExistingVPC', { vpcId: 'legacy-vpc-id' });
You can split the services you need to import into packs of n. Then, you can chew through them one by one. This will slow you down, but it is necessary to gradually transition legacy constructs into ones created through IaC (Infrastructure as Code). Such migrations will be almost immediate for stateless things like network configurations or lambda functions. However, it will be significant for stateful ones, such as databases or user pools. Reach out if you need a sounding board.
Storybook Files
Now that your Storybook has been set up, every web component will have a dedicated file containing stories. If you begin from scratch, follow the Definition of Done (DoD) and create a file with at least one basic story. If you’ve inherited an existing code base, you can dedicate time to iterating and enriching the existing components with such files.
A basic Storybook component file
The resulting interactive storyAs you progress, I recommend structuring the hierarchy of all your components and pages in the library as a tree that mimics the folder structure of the code. You want your components to be as high in the tree structure as necessary and not higher. Documenting components using Storybook can provide a visual aid to determining if you need to push something further down or bubble it higher up the hierarchy.
Test Files
Since the testing framework was set up and configured as part of becoming equipped with the necessary context-agnostic development tools, you can now kick some low-hanging fruits in chunks of x.
The first part of the article mentions smoke and snapshot tests.
...
// Smoke test
it('renders without crashing', () => {
const container = document.createElement('div');
const root = createRoot(container);
root.render(<Hint text={'Hint'} />);
});
// Snapshot test
it('renders correctly', () => {
const view = render(<Hint text={'Hint'} />);
expect(view).toMatchSnapshot();
});
These tests are repetitive to write and don’t require deep thinking. All you need to do is augment every component, be it a package, a React button or an Amazon Web Services (AWS) CDK construct, with an additional file as described in your DoD (Definition of Done) document. You’ll have as many such files as you have testable standalone components. Go through all of them iteratively and add those few lines of code.
Analytics Events Tracking
Meta is known for tracking ~50.000 data points on you. Your startup probably doesn’t need to track that much, but you want to collect analytics of events that matter. You don’t want to implement 50 thousand random events from day one. Requiring this level of sophistication comes with maturity.
// A stereotypical user cart analytics.
await analyticsAddToCart({
currency,
items: products.map(({ id }) => id),
webappUserId: user.username,
value: numberOfItems,
})
What I often witness is that developers who are supposed to implement tracing of analytics events expect marketers to know exactly what events they want to track. “Give us a list of what you want, and we’ll prioritise it,” I often hear. Unless these are seasoned specialists who’ve been there and done that before with the same type of product, this will generally not be the case.
However, if such a list was made, you could chunk it into manageable portions and deliver each portion every day or sprint.
When covering your code base with events tracking, I recommend not overthinking it and going from coarse to thin. Limit yourself to simple events, such as page views and scrolls beyond the fold. Then, add search query terms and session durations. Later, you can get more granular and collect shopping cart items and how they relate to the recommendations that your system yielded based on their search intentions.
Modelling of Business Entities
Hopefully, the second part of the article convinced you to invest energy into modelling your business through UML (Unified Modeling Language) or an equivalent. If you did make this wise choice, you’ll now have to populate your model with business entities routinely used throughout the company. There’s a list of commonly used ones, such as users, queries, chat messages, etc. But there are undoubtedly business-specific ones, too.
A basic UML use-case diagramMy recommendation is to begin with drafting an ERD or Entity Relationship Diagram. Every relevant business entity should be reflected with the attributes you want to keep stored with it. Connect them using the chicken leg notation.
A product can be part of zero or many carts. A cart can include zero or many products.Adopt a higher-level, conceptual perspective instead of a low-level database table-like thinking. Although depicted as part of a particular entity, your attributes don’t necessarily have to be implemented within the same data store. This is especially applicable in the case of distributed systems, which are the majority of modern platforms. You could also use RDF or OWL ontology conventions, but that's a topic for another time.
There’s not a lot of OS-agnostic modelling software worthy of your attention and money. I always recommend StarUML since it is the closest I could get to top-of-mind analysis software without breaking the bank.
Conclusion
This piece was initially written to avoid repeating myself.
Indeed, all companies I worked at, without exception, were spreading themselves thin, trying to build everything simultaneously or focusing on secondary things more than the core ones, sacrificing efficiency and burning money in sub-optimal ways.
I’m not pointing fingers. We all miss the forest for the trees. I’m certainly guilty of that, too. The trick is to notice it early enough or put yourself in a setting where the likelihood of this happening becomes low. This is why we use frameworks. They frame our work, switching off the human factor. “Divide & Conquer” is just one of them.
If what you’ve read felt like common sense, that’s because it is. Most things that work tend to be ridiculously trivial. I didn’t invent anything. Nobody does. Instead, this is a tried and true pattern borrowed from other disciplines where they’re first-class citizens for getting things done. I’m sure they’ll work for you too.
Special Thanks
This series of articles wouldn’t be possible without the priceless contributions of Lilian T. , Farouq Aldori, Teppo Hudsson, Jarek Owczarek, Nickolay Tsybulyanko, and Jason Collins.