The Fallacy of Assuming Reuse Equals Efficiency and the challenge microservices practitioners have given to the DRY principle.

1. <CLICK>
1

2. Let me tell you a little bit about myself. I work at Capital One, where I lead
microservices transformation efforts. Microservices is an area that I am quite
passionate about because it unites multiple other things I love: APIs, distributed
systems, containers, organizational design and team culture. I have been building
microservices for several years now and last year we published a book about
microservices, with several friends.
Today I want to talk to you about one of the hotly debated topics in Microservices,
which is – code reuse.
2

3. You see, reusing code, reusing APIs has traditionally been viewed as the road to
efficiency However, a lot of microservices practitioners actually question whether reuse
is always a good idea, instead prioritizing replaceability and upgradeability, over reuse.
This may feel like a fallacy to you, because the DRY principle of Don’t Repeat Yourself
has been one of the supreme commandments of software engineering, ever since Andy
Hunt and Dave Thomas published The Pragmatic Programmer book in 1999.
A lot of things have changed since 1999, however. So please indulge me in going on a
journey with you to explore whether reuse is always a good idea.
3

4. Let’s start by discussing some design principles. How many of you have been confused
by whether you should push or pull a specific door? Raise of hands, please!
Well, I have very good news for you – it’s not you, it’s the doors. Specifically the badly
designed doors often referred to as “Norman Doors”,named after the famous designer
Dan Norman, who first identified the poor usability of everyday products in his classic
book Design of Everyday Things.
Specifically, the problem on the photo is that a door that is supposed to be pushed has
a handle. Handles indicate pulling. These doors communicate false information about
their capability.
4

5. A proper ”push” door should have flat surface or a pushbar, making it clear that the
ONLY thing you can do with such door is to push. There should be no confusion.
5

6. Now, it’s too easy to assume that the designers of Norman Doors are just stupid. In
reality it is not always the case. They didn't design the doors out of spite of human race,
what they were probably trying to achieve was to manufacture a door that can be
“pushed or pulled” from both sides, so it’s reusable no matter how you install it. This is
designing for presumed reuse - sounds familiar? And yet it led to object so frustrating
and useless that a famous designer wrote a book about it. Ouch!
Photo credit: Sutterstock with proper license
6

7. When you make reuse the ultimate goal, you will end-up designing for an average user
and end-up creating lowest common denominator solutions.
7

8. Sometimes designers call the averaged persona a “normal user” to make it sound
better, but designing for such “normal” user is still very misleading and can even be life-
threatening, as US Air Force learned the hard way in 1940s. They tried to design a
cockpit of a fighter airplane based on averages. The results were devastating. The
performance of top pilots became abysmal.
See the problem was that no one is ‘normal’. Everybody is made up of a multitude of
individual characteristics: height, weight, length of the hand, ratio of upper and lower
body, feet length etc. Averages sortof work for single variable, but if you take an
average across multiple characteristics, you won’t find any individual who is even close
to the “normal”, in all respects. This is known as the ‘jaggedness principle - averaging
across multiple variables doesnt work.
When US Air Force designed the cockpits around average range of 10 body
measurements across 4,000 pilots, they ended up with a design that didn’t fit well
anybody. It was uncomfortable for EVERYBODY. Because they didnt take into account
juggedness principle. They ended up inventing adjustable seats, which is why we also
have them in our cars now.
8

9. Remember Maya Angelou’s words: "If you’re always trying to be normal, you will never
know how amazing you can be."
9

10. Aside from problems with averaging, another issue is that reuse can kill innovation. If
you always only have one choice – how do you foster innovation? A market with no
competition doesn’t have enough motivational forces to produce high-quality products.
On the photo we see a soviet soap. It’s extremelyuninspired, has no packaging but a
protective paper and the only information on it is: the percentage of oily substances.
You can compare it to how an example of a modern soap looks, created under fierce
competition.
Soviet soap photo: Shutterstock with proper license
Soviet shield: wikipedia
Dove bar: dove.com under Fair Use terms. https://www.dove.com/us/en/washing-and-
bathing/beauty-bar/white-beauty-bar.html
10

11. Now, if you decide to treat your API portfolio as a free market, you need to make sure
that you have two crucial forces that are required for proper functioning of real
markets: advertising and natural sun-setting of products.
Advertising, while it may be annoying when you are watching your favorite TV show, is
very important for informing consumers. You will have to create an internal developer
evangelism function to make sure you properly mimic it.
Secondly, in free market bad products have natural way of dying – if nobody buys a
product, it starves for resources and eventually disappears. In a corporation you can
endlessly fund your APIs or tech products just by knowing and befriending the right
people. So if you treat your APIs as products in a market, you need to make sure that
the ones that do not get natural adoption will organically disappear, and won’t get
funding.
If you don’t facilitate these two forces, encouraging duplication may not be appropriate
for you.
11

12. Hopefully we have given you a lot examples to convince you that reuse can be
dangerous. However you are probably still asking yourself: “but isn’t duplication
costly?” Doesn’t reuse save money? Well, not necessarily.
First of all, enforcing reuse for every single thing can be extremely costly itself, and not
worth it. Secondly, we know from manufacturing theory that if we are trying to
optimize overall cost of a complex process, local cost is a bad optimizer. Only overall
throughput matters.
And lastly, reuse creates tight dependencies on different parts of your system. And
those dependencies may create cost-saving initially, but over time their cost goes up
exponentially. The cost of dependencies may eventually surpass any savings in reuse.
12

13. Next thing you may be worrying about is: security of letting just anybody implement
crucial services. But in reality that’s not the case. Just having a free market of services
doesn’t mean that every service comes from free market. Just like in real world, most
of our products are market products but we also have government services and public
goods that are subsidized. Every community makes their own decisions about what
should be centralized and what should be in free market. Likewise, you have a lot of
control in your organization to adjust these levers, but by default most of the services
should be in “free market”, if you are doing it right.
13

14. 14

15. 15

16. In conclusion, we believe that reuse is neither inherently good or bad. It shouldn’t be a
commandment of software engineering, but it should also not be outright rejected
in all cases. The question of reuse or not is a very nuanced one and we should
approach it with a careful consideration rather than a zealous pursuit.
Thank you very much!
16

17. <CLICK>
17