When Innovation is Appropriate
==============================
:author: Aaron Ball
:email: nullspoon@iohq.net


I have recently found myself very burned out on IT. Don't get me wrong, I love
doing anything related to building systems of any kind. I love to design
systems and I love programming (not that those two are very distinguishable).
Modular design that implements seperation of concerns well is like poetry to
me. All that goes to say that I still enjoy working with computers in most
capacities. What's really burned me out is the constant fight.

I work in a heavily regulated industry with a team that is made up of half
Linux guys and half AIX/IBM guys. I find that the Linux engineers are fighting
with the AIX guys about ways to do things. They don't want to use any product
that doesn't come with an enterprise support package (IBM support is
preferable). They always give the excuse "Well do you want to be the one at
3:00 in the morning who's trying to figure out some obscure problem by yourself
with management breathing down your neck, or do you want a third party who you
can point the finger at and send a ticket to?". The thing about that mentality
though is that pointing the finger at a vendor doesn't get your systems up any
faster, nor does it better you as an engineer.

I disagree with this mentality (as evidenced with this post). My feelings on
the matter are that my employer is paying me money to be the best at my job
that I can be. That goes without saying that it brings me tremendous
satisfaction to be great at my job. That means learning to support whatever
weird stuff is already in place and engineering better solutions for the ones
that break. After all, why bandage a problem when you can solve the problem all
together.


[[two-schools-of-thought]]
== Two Schools of Thought

All this goes to highlight two different mentalities (yes, I know how cliche
this sounds). One group of people asks "why", and the other asks "why not".

The "why" people will often look at a problem and think only inside the box the
problem's circumstances provide. If an outside the box solution is considered,
that solution is likely only inside of another box (from one proprietary
solution to another). They consider outside the box thinkers to be reckless and
"cowboy" because outside the box in many cases entails making ones own
solution.

The other group, the "why not" folks, tend to view the "why" people as closed
minded and paralyzed with indecision. They mentally roll their eyes when they
hear the phrase "enterprise support" and often look at budgets and say "Why are
we paying so much money when we can do such simple work for free".

Granted, these are generalizations of course. Not all of the above mentalities
apply globally and neither do they apply in their implied levels. These
attitudes are spectrums and do not accurately describe everyone in either
group.


[[i-personally...]]
== I Personally...

When I see a problem at work, my first reaction is not to look for a paid
solution that's going to cost loads of money and make finding employees with
experience with the solution harder. The way I view it, if you pay for a
software so expensive that only a fortune 200 has the resources to buy it, you
are limiting your pool of hireable people down to those who have ever worked at
a fortune 200. Instead I go in search of an open source product that is
established well enough to be able to handle the problems we throw at it (eg:
puppet, apache, clustered mariadb, openstack, kvm, native Linux tools, etc). If
one does not exist and the problem is still surmountable without needing an
entire development team, I try to build my own solution using design best
practice and then I document it like my job depends on it (code comments, class
architecture design documents, database schema design documents, etc). The way
I see it, building my own solutions gives me better understanding of how
already existing solutions work. It also helps because it gets me to research
better ways to do something. From the business' perspective though, they need
to find a developer to maintain my product when I am gone, so in these cases an
enterprise solution might be better.


[[a-short-list]]
== A Short List

Here's a short list of people and companies who have asked why not (notice how
they're all world renound innovators)...

Google is [seemingly] one of those companies who has a lot of people working
for it that ask why not. They are experimenting with low traffic server farms
that use ARM processors to save on electricity. Twitter is built on Ruby, an
open source language, because it actually can do the job and do it well (why
not when the alternative is licensing IIS, Windows, MsSql and using .Net).
Facebook (despite the problems I have with them) is built on PHP and when that
wasn't fast enough for them, they built their own php to c++ converter. The
Linux kernel which now runs the majority of the servers on planet earth is
built by people sitting at their jobs and at home, donating their time because
the alternatives aren't good enough, and again, why not? OpenStack is used and
developed by NASA, an organization who has safely sent people to space and
back, and Rackspace, one of the biggest hosting providers in the world.
Wikipedia, one of most frequently visited websites in the world, is built for
free on PHP and MariaDB because again, why not? Have you ever seen Wikipedia
crash? The http://en.wikipedia.org/wiki/Lustre_%28file_system%29[Lustre
filesystem] is an open source load balanced filesystem that runs 60 of the
world's top 100 super computers and 6 of the top 10. NASA also uses it.


[[in-conclusion]]
== In Conclusion

It's people asking "why not" that brought us things like HTTP, SSH, Apache, pgp
encryption, multithreading, fiber and copper communications, radio-based
networking (WiFi), and so much more. I seriously doubt that I will ever make
anything nearly as cool or world shaping as
http://www.goodreads.com/quotes/10286-if-i-have-seen-further-it-is-by-standing-on[the
work upon which everything I have made is built], but I can at least try in the
effort to not perpetuate bad methodologies and maybe contribute if even a
little to the knowledge base that is so readily available to all of us.


// vim: set syntax=asciidoc:
