What is the Mermaid Principle

Brief Intro

The reality of our industry in 2020 puts product-development in a bit of a predicament.

Why you ask?

Well, it’s really hard to plan if we are reacting to feedback and looping all the time, and it’s really hard to maintain our code if we want to move fast, and it’s really annoying to polish something, to work hard to make the code amazing and then realize it’s a turd when we release it – because people don’t use it…

Basically, it sucks!

The fast-moving pace of our industry and the adaptive methods we use today made product-development to be a bit more reactive in many senses:

• The markets are moving so fast and so are trends, we need to keep up all the time.
• We start many initiatives, test the waters (pun!) with them and proceed with those that are working well for us.
• We try to have many small feedback loops, we try to reach our target audience (AKA users, I just hate that word) as fast as humanly possible with our products, to get their feedback and calibrate how to move forward.

There are many more reasons why it’s difficult, for me, the biggest one is:

If we plan, and invest time to create a perfect solution we might just miss the market, others could monopolize our solution space or we miss it because our perfect solution isn’t solving the real problems people see… basically we invest a lot of time and in the end, we cry about spilled milk, a lot of it…

I’m not here to convince you that this is a good approach, I’m here to talk about the Mermaid Principle.

How do we deal with this now, what are common practices that are not the Mermaid Principle?

Option 1

We either invest so much time, we talk about SOLID principles, we push for clean code and 100% coverage, we argue about method names and more.

We put coding on a pedestal.

And what does it achieve really?

It’s slowing us down, it and it makes us want to leave our job and move somewhere else… every time we invest a lot of time to deliver a polished turd, our hope shatters a bit more and maybe a fairy dies, who knows?

It hurts when we go to production with shiny great looking code and we learn that products are what’s important and our code – shiny as it is, in the worst-case scenario: left unused (but still maintained) or best case scenario: going to the trash.

Because you ask, well, we might be:

too late, or we didn’t solve the problem, or users don’t need what we made.

Option 2

On the other hand, if we move fast all the time, we get to the same situation many startups and companies find themselves in today.

What is this situation? normally it looks like this:

• Unmaintainable code
• Everything we do breaks something else unrelated
• We can’t onboard new people because our solution makes no sense and follows no known principle
• We are churning hard on the frustrated devs we have and know how to handle our environment
• In the end, we still move slow… REALLY SLOW!

 

Fuck, it’s the same result…

 

So, What is the Mermaid Principle?

This name came from a good friend that worked with me, you know who you are 😉, the idea is:

1. We create a great looking solution, the people using it see the “human part” above the water, the fish part is what we see underwater – visible to us the people working on it – we invest time to make the product/feature look appealing and attractive to our customers and manageable for us.
2. We also invest time on our  “logistics” – we make sure we can deliver our mermaid to our audience quickly and we can take it back if we get a negative response, or in code life –
   1. We invest time on:
      1. Our CI/CD infra
      2. We make sure we have a testing infra (but maybe no tests / minimum amount)
      3. We make sure our code structure is adaptable, without over-engineering it
   2. What’s important to us:
      1. We make our product look great! MVP doesn’t mean ugly looking
      2. We can go to production quickly
      3. We can revert quickly
      4. We invest our “tech-time” on the infra and on making sure we can re-implement the missing pieces once we get traction
3. We know how much attention each mermaid should get to be deemed successful – meaning we are able to measure clear matrices to understand if we have traction.
4. Once we see that one of our mermaid is getting the attention we wished it would:
   1. We work on improving the fish part, starting to make it more human… not necessarily in one go, but we apply the girl-scout rule (when going camping, you always leave the campsite cleaner than before we came) – we improve as we go, each class gets a nice touch for every new feature.
   2. We fill in the gaps of the tech-debt we took, but the slow-down isn’t as big, because we made sure to structure our code well (even though we probably violated DRY or SOLID some times), we might not have a great code coverage, but we invested time to have a unit testing set-up, now it’s just filling in the gaps… we track those things.

Summary:

The entire idea is to test the waters (pun intended), to put as many different solutions out there, without over-engineering, to be able to deliver solutions fast and to put good looking solutions, MVP doesn’t mean ugly looking!

We wish to put the emphasis on the Product and our Infra.

To make conscious decisions to cut corners to avoid initial slow-down, but to have the right structure and to know where to place the fish part, so if our product gets attention, we can wash it up incrementally without drowning (yeah yeah, pun intended).