"What led you to this particular decision?"
This is a common question I ask clients when discussing the way they are producing code.
Often teams have really good reasons for their decisions, reasons that aren't always apparent
unless you know the full technical and political history of the project.
However, with increasing frequency, I am staring to hear the Amazon justification.
"We decided to do X because Amazon does X."
"We use Service Oriented Architecture.
Why?
Because Amazon uses it."
"We are building everything with DynamoDB.
Why?
Because Amazon uses DynamoDB."
"We want to write every part of our application to scale to any work load.
Why?
Well that is what Amazon does and it seems to be working well for them."
"We want to lose $170 million as part of an experiment to build a new cell phone because
Amazon..."
Ok so I haven't actually heard anyone say that last one, but you get the idea.
And it definitely isn't limited to Amazon.
Netflix, Spotify, Google, Apple, pretty much any successful company is a candidate for
the "But [Insert Company Here] does it" justification.
This doesn't make any make any sense.
The fact that Google, Amazon, or Netflix does something is not a good reason that your company
should mimic it.
"I don't want to brush my teeth.
Why?
Because tigers don't brush their teeth and look how successful they are in ... tooth
... stuff."
Hey, maybe thinking of yourself as a tiger is a great self-affirmation and motivational
technique, but trying to make life decisions based on what a tiger does is going to have
some really bad consequences.
Just because a tiger sinks $170 million in to a failed cell phone...oh wait, that was
Amazon.
The reality is that you are not a tiger.
No seriously, you aren't.
Even if it did somehow make sense to model your life after a tiger, you've got to look
at things holistically.
Not brushing its teeth is such a minor thing in the overall picture of a tiger's dental
hygienic health.
Eating raw meat and gnawing on bones is probably a bigger deal in the overall scope of tiger
dentistry.
And the elephant in the room...
And no I don't think elephants brush their teeth either.
The elephant in the room is lifespan of a tiger.
They only live about a decade in the wild.
(Why only 10 years?
I don't know.
Maybe they all die of complications from tooth decay.)
But, if you were going to die in 10 years, maybe it would make sense to spend less time
brushing your teeth too.
The point is that, the facts and circumstances in your life that would make brushing your
teeth a rational choice are completely different than the facts and circumstances in the life
of a tiger.
(Plus it is hard to hold a toothbrush in a paw without opposable thumbs)
Many decisions that are good choices for a tiger are not going to be good decisions for
you and many decisions that Amazon makes about how to build software are not going to be
good decisions for your organization.
Your company isn't Amazon any more than you are a tiger.
(Unless you are an Amazon employee who happens to be watching this.
Then your organization literally is Amazon.
But you probably still aren't an actual tiger.)
Successful organizations are the ones that are good at making decisions that will help
grow the company.
Those decisions are based on what is best for their particular set of circumstances
and usually some type of experimentation to determine what works and what doesn't.
A sure fire recipe for failure is to assume that you can be successful simply by making
the same decisions made by Amazon.
Amazon's strength is their process of making good decisions for their particular set of
circumstances.
Their whole microservices approach has grown out of their response to problems they were
encountering in 2001 once they got to the point of selling $1 billion in a single quarter.
Yes, billion with a B in a single quarter.
Just for scale, 1/3rd of the countries in the world had a GDP of less than $4 billion
back then.
Amazon's micro services approach has been extremely successful for them, and it is very
much worth looking at their model for lessons that you can apply to your organization.
But Amazon's approach isn't a magic bullet.
They are making decisions based on what will give them a good return on investment for
their set of problems at their scale.
A well designed monolithic application might be a horrible approach for Amazon, but doesn't
necessarily mean that micro services offer a better return on investment for your company
than a monolithic application.
I'm assuming here that, unlike Amazon, your organization is smaller than Kuwait, Ukraine,
Ecuador, and 100 other countries.
If you want to mimic something about Amazon, mimic their skill at making good decisions
for their particular situation.
Decisions that give them a good return on investment
Guatemala, Luxembourg, Panama, Costa Rica,
And to be clear I'm not talking about making decisions for YOUR company based on THEIR
situation.
Your company...
Your situation and circumstances.
Uruguay, Morocco, Sudan.
Lesotho where is that?.
You can't shortcut the process of making good decisions.
Finding the best way to make software in your organization is hard.
Even if your goal is to become Amazon by mimicing them entirely, what they are doing today is
based on the problems and circumstances they are facing today--not the issues they were
facing back when they *were* in your position.
Seychelles are these even real countries.
Elbonia?
alright who put that on here
Is Amazon's DynamoDB a good way to store data?
Absolutely--if the problems you are facing are the problems Dynamo is designed to solve.
Does a Service Oriented Architecture offer a way to bring the work of many teams together
into one enterprise system? Definitely, but is that actually a problem you are facing?
Does Micro Services offer flexible scaling and redundancy?
Yes, but this is only useful if you are building something that you actually need to scale.
Too often teams forgo delivering something that is valuable today because they are too
focused on preparing for the issues they hope to have tomorrow.
This is like someone becoming so obsessed with planning their hypothetical wedding that
they never get out of the house and have a chance to meet someone willing to be their
spouse.
If you haven't created any usable software, you don't have a scaling problem.
You have a "we haven't created any useful software" problem.
Now this doesn't mean you shouldn't ever think about the future, but everything has trade
offs.
Time spent solving hypothetical future problems can be a huge waste if it comes at the expense
of solving the real non-hypothetical problems you have today.
In fact, many of the hypothetical problems teams obsess over are only going to be realized
if they can execute well on the immediate issues.
It is like saying, "If we happen to be successful it is just going to create more work for us."
Yes and that is a good thing.
It means you've done something right.
The problem of wedding planning only occurs after you've successfully found someone to
marry.
When a couple gets engaged, the fact that they now have a wedding planning "problem"
is not a sign they should have done a better job of thinking ahead so they would have less
work to do now.
That would be crazy.
The wedding planning "problem" is an indication of success, without which there would be no
need to plan a wedding.
Weren't we talking about Amazon?
How did we get to tigers and wedding planning?
No matter how good Amazon's decisions are for their particular situation, you aren't
Amazon.
And you are probably aren't anywhere near their scale, so your problems are going to
look significantly different with significantly different optimal solutions.
Now the good news is that your competition may be doing things simply be cause that is
how Amazon, Netflix or whoever is doing it.
There is a significant competitive advantage in being able to identify your current most
important problem and working to solve it.
The most successful software teams aren't the ones that can solve the greatest number
of hypothetical problems up front.
It is the ones that are laser focused on consistently delivering useful software over and over again
and then dealing intelligently with all the "problems" that come with their hard earned
success.