Plan Wagon

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."