What does it mean to architect a system? It means you solve
problems.
While that might seem simple, I am absolutely dumbfounded by the
number of people that attempt to solve their problem by simply
applying the solution to someone else's problem without any sort of
reasonable thought process.
Let me tell you all about "Plan Wagon."
Bob's a great parent. In fact most people that know Bob are
extremely impressed by Bob's parenting skills. He spends time with
his kids and one of his favorite things to do with them is take them
for wagon rides around the neighborhood. Bob's blogged a few times
about how challenging it was to take his kids around the block before
(as they were all different ages with different walking speeds and
attention spans), but now with the wagon — life is swell.
Jack reads Bob's blog amongst many others, and he himself has some
experience with wagons and knows how they operate. He was a child
once and just the other day saw someone transporting some children in
a wagon. Jack is an important player in education: he coordinates
various programs and has been very successful.
Jack is posed with a challenge at work: a new educational program
being offered will serve 120 children ages 4 through 9 across a suburb
and his organization must provide transportation. Jack feels
confident. Jack knows Bob's success with wagons. Jack has used a
wagon, has seen them work. Jack purchases a fleet of 64 wagons. He
figures that two kids per wagon would work fine and that having four
extra will leave some to be used if another wagon needs servicing.
Now, who will pull them? Well, with 60 wagons, you'll need at least
60 adults. And the distance to be covered is about 4 miles, so they
should allot for approximately 2 hours each way of travel time.
A casual observer notes to Jack that perhaps a transport with
higher service capacity and faster travel time might be more
appropriate. Jack is irritated because he knows that the wagons will
work (and BTW, he is correct). Despite his irritation at being
distracted from ironing out the implementation details of "Plan Wagon"
he does some research. Jack finds that a both a Boeing 737 and an
Airbus A320 will hold 120 children and go around 500 miles per
hour. But, clearly those are impractical because of the cost.
A colleague of Jack's suggests that perhaps buses should be used.
Jack, of course, knows exactly what these are. However, Jack doesn't
have a C class license so cannot drive a bus, nor has Jack ever fixed
a bus, and buses typically don't have seatbelts, which has always
concerned Jack. Jack is confident that were something to go wrong
with "Plan Wagon" he could act in any role required to facilitate
success.
Jack sleeps on it. After reviewing the facts he comes to a
decision. Jack's goal is to move different aged children around the
suburbs. Jack knows that Bob effectively moves children around his
suburb on wagons and the choice of a wagon made Bob happy, popular and
solved the critically important problem of varying mobility of
children of different ages that Jack is sure to face. Jack goes ahead
with "Plan Wagon."
Jack is an ignorant ass clown.
Now, in reality, Jack's "Plan Wagon" can work. It's overly
expensive and painfully suboptimal, but possible nonetheless. The
issue here was very obvious: Bob's problem and Jack's problem were
different — no matter how much Jack wished otherwise. For some
reason, in technology, even seemingly smart people act like Jack.
People
applying NoSQL to
problems that would clearly benefit from deep relational
management. People applying
traditional DBMS
to problems that require no atomicity, isolation or
consistency. People who feel they need to
use Hadoop to process a mere
terabyte of data. These technologies aren't "wrong" — but can't be
considered "solutions" when they are applied to the wrong problem.
Here's an idea: how about understanding the problem before you try
to solve it? I know it's a radical concept, but it might just help.
I would argue that almost every solution has at least two legitimate
technology selections that can be cleanly applied. In other words, if
I need a strong DBMS, chances are good that
both PostgreSQL
or Oracle
will work. If I need a horizontally scalable key-value store,
likely Cassandra
or Voldemort
(or MongoDB
or CouchDB) will work. Now
stop. I'm not telling you to look hard at the differences between
Cassandra and Voldemort, I'm tell you to look hard at the differences
between a DMBS and a key-value store. Do not assume that because you
are building an app "today" that you it must be powered by a key-value
store.
Next time you are posed a problem and you pick up your favorite
tools — put them down. Why? It might just force to think about what
you are building instead of the tools you are using. Be an engineer
and think about the solution to the problem rather than the building
materials and tools.
At OmniTI, we hire engineers and often immediately have them use a
language and a database and an operating system they don't know. It
separates the engineers from the programmers — programmers are a dime
a dozen.
Unfortunately, engineers are hard to find. If you want to be an
engineer consider OmniTI as a home for
engineers. It was built by engineers and continues to be run by
engineers. We're hiring
people that are more excited about the solutions they produce than
they are about the tools they
use. We're hiring people
that want to solve problems right and can restrain themselves from
trying to jam a square peg in a round hole just because the peg is
shiny or familiar. We're looking for people that care to understand a
problem before they solve it. Ignorant ass clowns need not apply.
Regardless of who you are and what you are doing: avoid "Plan
Wagon."
