Separate what software does from how you do it
Separate what software does from how you do it
"Everything Starts Out Looking Like a Toy" (No. 71)
Welcome to the Find Data Ops 📊 members who have joined us since launch!
Join smart, curious folks by subscribing here:
Hi, I’m Greg 👋! I publish this newsletter on finding data products and interesting data observations with the goal of finding patterns and future product insights. (Also, it’s fun.) If you need a background on how we got here, check out What is Data Operations?
This week’s toy: Food Scan enables Snapchat users to take a picture of a food ingredient and find recipes that match that ingredient. By itself, this is interesting but not terribly notable. Combining all of the things that are scanned, however, might result in “ingredients that go well with this” or even suggested shopping lists. Taking a picture of a thing starts a knowledge graph of interrelated items. Edition No. 71 of this newsletter is here - it’s December 6, 2021.
The Big Idea
A short long form essay about data things
Separate what software does from how you do it
Systems do not start as complex systems. You build a thing. Then you get a request to build another thing. A customer asks you to build yet another thing. And the person who asks you to build the latest thing is not thinking naturally how to fit it all together. They are trying to solve a problem, not make your product better.
There is another way. To build better systems, do not depend only on the promise of other systems. That’s the premise behind composability:
“…a system design principle that deals with the inter-relationships of components. A highly composable system provides components that can be selected and assembled in various combinations to satisfy specific user requirements.”
The future of software looks a lot more like this than traditional models of software depending upon monolithic services, resources controlled by only one software provider, or even the very idea of single purpose software. For better or for worse, the way we acquire software these days means we are finding “best-in-class” tools and asking them to work together.
The effort to get systems to work together is hidden and difficult.
Turn ingredients into a recipe
When software doesn’t work together, as a customer it feels disjointed. When I contact the company, why doesn’t the next person I talk to in customer success realize I have already called? When someone from a vendor contacts me, why don’t they know what I’ve been doing in the product?
The root cause of this is systems that don’t talk to each other. You normally don’t notice this problem when you do all of your work in only one system - all of the pieces talk to each other naturally.
This is only going to get more pronounced as teams use more apps in the course of their daily work and expect those applications to work together. (Spoiler: they are not built to work with each other.)
Don’t take my word for it; look at this data from Benedict Evans and Productiv.
When applications are not built to work together, the incentive for software makers is to force you into using only their system. There is a more subtle observation here: software makers want you to use their logic, not yours.
When this goes wrong (perhaps because the software maker’s logic doesn’t work in your environment), you get problems like these 10 Famous ERP Disasters.
Good recipes require the best ingredients
It’s not enough to build your own logic (in contrast to using a software maker’s logic); you also need that logic to do some work on its own. In basic terms this means building individual pieces that look like components.
What’s a component? It’s a fancy way of saying that software needs to be self-contained. A component needs to solve a problem and do its job well. Components also need to describe the way they work to other systems, both in terms of the functions they support and in the structure they use to hold data.
Components need to work by themselves and also as multiples in a collection.
They need to be fault-tolerant, verbose in explaining what they do, and also not try to do too much in any one action. That’s a tall order.
All of this sounds like composability. What does it look like to have composability built into the system?
Objects with logic built into their definition that describes how they expect to interact with other objects
“Recipes” of workflow that use your logic instead only the logic of the platforms you’re using
Workflows that document themselves
I’d like to use more software based on these principles. Building the logic of your business operations should be a first-class software operation.
What’s the takeaway? Composable systems are smart because they build logic that you could use for future system changes, maybe even changing the components of your logic without rebuilding the whole system. By engineering composability, you’re starting with reusable blocks, not ideas that only work a single way.
A Thread from This Week
A Twitter thread to dive into a topic
Here’s a cool 🧵 on “light pillars”, an unusual atmospheric phenomenon. They don’t exist, but you can see them anyway.
Links for Reading and Sharing
These are links that caught my 👁:
1/ Do Androids Dream? - the GauGan2 demo from Nvidia shows the possibility of creating generative art from a model using a descriptive phrase or sentence. Building scenes using voice input is a really interesting idea for storytelling, and I can see it working for other kinds of data visualization too. I’m waiting for “show me metrics that will make people feel good” or “show the metrics I don’t want to see” as input for dashboards.
2/ The mechanics of grasping - It’s harder than you think to teach a robot how to pick something up. Researchers at MIT are working on dexterous hand manipulation by working on small skills that can be combined.
It’s not hard to imagine combining the kind of natural language processing for a model like GauGan2 with robot instructions to share simple yet vague instructions for a computer that will resolve correctly. The next operating system will use natural language prompts. When you can tell a household robot “Go pick up that red thing over there” rather than giving it exact instructions, that will be a breakthrough.
3/ Understanding what comes next - It’s been a long time since March 2020, and many things have changed about “normal”, especially where anything related to COVID19 is concerned. What hasn’t changed is our relative ability to understand the likelihood of solving problems involving unknown unknowns.
I love the idea that Alexandr Wang advances about betting on the future by embracing unknown unknowns. In the short term, things are much more well known, and as Alexandr points out, “making long-term predictions about the future which are grounded in reality will often lead you to be wrong.” Too many things can change too fast. This is a really good lesson for product, where we peer into the future to guess at what might be. You may as well take a bold bet because if you’re right, the benefits compound.
On the Reading/Watching List
Some things to watch or read, in no particular order
Reading: No One is Talking About This, by Patricia Lockwood. In this extremely online world, becoming popular overnight for a seemingly meaningless post or idea will change a person. Lockwood spins a yarn about this happening to an unnamed narrator, and you’ll have to read to find out what happens next.
Watching: Hawkeye, the latest from Marvel. I love this one, because it’s not all about space aliens, interplanetary war, and overpowered heroes. Ok, so there’s some ridiculous luck and skill involved, but at the core of it there is some excellent buddy-cop writing and a touch of the feels.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
I’m grateful you read this far. Thank you. If you found this useful, consider sharing with a friend.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon