Beware The Everything Pig
Beware The Everything Pig
Why chasing down the one-solution-to-rule-them-all rarely works out.
A What Now?
One of my favorite product analogies is that of the Egg-laying Wool Milk Sow mythical beast. Admittedly, the name rolls off a little bit better in German, as the Eierlegende-Wollmilchsau (pronounced close to eye-er-leegendah-vol-miss-shou, or so I'm told). It conjure in the mind a fun little beast — not quite a hideous beast, but not really adorable, either. Let's call it the Everything Pig, or 'EP', for short.
The basic idea is that it's got all these capabilities in one convenient little domesticated package, ready for use. You want eggs? Before you needed to raise of a bunch of chickens, set up chicken coops, the works. Now? Just call on EP. Milk? Before days, you needed cattle, lots of land, and to get up early — but EP has you covered. Wool? Sheep are such a pain — why don't you just sheer EP while you're getting milk anyway? Multitask! See where we are going?
For farmers and Austin, TX hipsters, this animal would be the dream. It's the Apple iPhone of livestock product announcements.
The Real Meaning of the EP
But really, the Everything Pig is a lesson in tradeoffs.
(And it's also to some extent probably about Jurassic Park and genomic editing ethics.)
The lesson is that the Everything Pig is a myth. We can't simply build this Swiss Army knife chimera out of thin air.
If we want to live in a world of milk, eggs, wool, and bacon (sorry, EP), then we have to consider these features along with the systems needed to be in place to support these things — farms, henhouses, grass, sheep-land, butchers, etc. Each one of these features and their associated system has its own backgrounds, histories, relationships, quirks, opportunities, and constraints. Spend an afternoon with someone who won't stop talking to you about Jersey Cows (not from New Jersey, it turns out), and you'll see what I mean.
What's this have to do with product development, particularly when it comes to building out code?
It seems obvious when we imagine our adorably Cronenberg-esque Everything Pig that we can't always get what we want at no cost, but it's less obvious when we work with teams to design software and to build products.
Single, Monolithic Solutions
One solution to rule them all is an alluring concept, as it seems more plausible, there, that we can combine a website with a company database with an expense system with a business-development-pipeline with a CRM with dashboards with AI. Why not?
I mean really, all one has to do, (the thinking goes), is to just identify all of the features that we want to see, glue them all together, and presto — finished product that does everything you want it to do.
This type of magical thinking is particularly abundant in software because working in code has such porous boundaries of possibilities — coders and marketers alike constantly reinforce that anything is possible, given the right mix of time, money, and resources. I'm surprised it isn't an enterprising tech startup company logo yet.
The notion of a single, all-capable system often also arises because there is separation between the folks looking for the finished product — who end up being the ones defining all the features they'd want to see, and the folks building out the project — who end up thinking through all the tradeoffs that have to be made.
Monolithic solutions that do everything are so tempting because we have a number of different needs that have to be met, so we're looking for a place that offers a one-stop shop for all of them, and many (myself included) are disappointed when faced with the prospect of dealing with multiple, disparate systems. It gets really complicated, really quickly.
The Reality
We often have to consider systems separately that maintain our email, our web browsers, our project management, and our data collection. What's even more frustrating, is that when it comes to the world of software, we actually could, in theory, buy/build systems that encompass all that we would like — would we actually want to? Most most most often, the answer is actually no (!)
It's not just a matter of cost (it's usually cost though). In thinking about our ecosystem of tech (whether an assortment of systems or a monolithic entity), we have to also consider maintainability, usability, security & risk assessments, longevity, flexibility, etc. Choose wrong on this, and you might look like PwC who used Lotus Notes for email until 2017.
When you start stacking all of these together, you start to realize why it's actually more strategic to have a data collection platform separate from your business intelligence software, separate from your intranet site.
There's a whole weeds angle we could get into here about the modern tradeoffs of microservices versus monolith systems — yet even the staunchest of monolith supporters still have to reign in scope creep from flooding their project. But you can also see that as you change the scale, timing, risk profile, existing expertise, etc. that you might construct a wholly new ecosystem built of different parts.
The Real Lessons
For teams that I work with, the takeaway is usually along the lines that there is often an underlying Eierlegende-Wollmilchsau implicit in our thinking. That we haven't done enough to think about the complexity behind the systems we are thinking of, the challenges in bridging them together, the time it takes to build out complicated, multi-part systems (even without the technology).
The Everything Pig is a cautionary reminder on wishing for a perfect product by just imagining the features most obvious and important features to us at the time. We need to think through things at a higher-order systems level, consider the unseen, the upkeep and maintenance costs, the investments, the resources, and the sustainability over time.
They can still be pretty cute, though.