A couple of days ago, TechCrunch ran a column about Developaralysis that hit a little close to home. Developaralysis is defined as "the crippling sense that the software industry is evolving so fast that no one person can possibly keep up." This results in otherwise accomplished developers freezing up when trying to make decisions about the best language / framework / cloud platform to use for their project. There is a cure and it involves code. A code specifically.
"A man's got to have a code, a creed to live by." - John Wayne
This is the cure. You have to have a code. When you're starting out in your career, you don't know enough to have a code. You work under somebody else's rules in most cases. When you reach the point where you are evaluating so many thing that you're trying to work out all of the trade offs to find the perfect balance to build your system...you are probably ready to institute such a code.
Now, there are a couple of important things to remember about having a code. You need a personal code that applies to how you do things and you need an organizational code that you and your team work under in order to keep moving forward without the team freezing up the same way. Your code may not be the same as mine or anyone else. Everyone has different priorities. Ideally, you want your code to be adaptable to your circumstances.
For example, "Always use X for everything" is not a code. If you go to work for a company that uses mostly Y, that code will probably get you fired pretty quickly. As a developer, getting married to a single language is myopic. Likewise, deciding to learn every language that comes out is unrealistic and impossible.
As it turns out, I do have a code that I'm going to outline here. This might not suit your needs, but if nothing else seeing how I arrived at mine might help you to formulate yours and potentially the code of your organization.
Mine comes from my own experiences thus far. I've worked doing enterprise development and enterprise production support. I've worked for very small, high traffic operations. I've worked in a role of developer for hire and I've hired and managed developers. I've been in devops as well as project management. When I make decisions, I've often suffered from Developaralysis trying to balance all of these concerns.
When I was in graduate school, I worked as an assistant for two professors that were building a supply chain optimization platform. The key to making this formula work was to break down everything, at each phase of the supply chain, into a single, consistent unit of measure. This was different for every company but once you found it the system worked like a charm.
Likewise, when weighing all of the concerns I mentioned before, decisions can be made much simpler if you break things down into a single unit that you're trying to optimize for. In my case, I've discovered that the optimizing factor that works best for virtually all cases is simply...time. It's the scarcest resource that exists and it is consistently scarce over the course of every factor that I have mentioned.
Time is the consistent constraint. There are exceptions of course. In the world of entrenched enterprise, it is entirely possible that there is such an abundance of time and money that implementing the most heavily optimized solution might seem perfectly reasonable. This is how Oracle and raw Java have such a foothold. Oracle is extremely expensive from a sheer cost and training standpoint, but it is great at what it does. Java is just about as fast as it gets on the server and the infrastructure options are polished to the point of bullet proof...but development is slow, learning curve is high and most of the infrastructure is very expensive.
But...if I was working at a company that had 50 Java developers, and heap of existing Java and Oracle infrastructure...Java would still be the a big part of how we operated even if I was calling all the shots. The time and cost of retraining 50 developers, rebuilding existing systems, and dual supporting more infrastructure would be far higher than continued slow development cycle that it comes with. I'd probably evaluate some options to speed things up for future development but my evaluation would be heavily biased in favor of JDK compatible options to leverage existing investments. I'd be looking at Groovy, Scala, Clojure and jRuby.
If I wasn't working at a Java shop I probably wouldn't be considering any of them. This is an example of having a code that is adaptable.
I am a time limited individual. I'm married with two kids, a full time job and a social life. That leaves very little time for wasting on "cool tech X" and a much higher degree of urgency for "get stuff done." Because of that, I'm a firm believer in the 99% use case. That's the language that gets me from idea to operative, quickly, in 99% of situations. The language that does that best in the wild, is Ruby. There are a plethora of successful startups that back it up. They may refactor eventually at high scale, but they need to refactor because they got to market.
Ruby fills the 99% use case because of its versatility. It's great for:
Rails isn't ever going to win a raw benchmark competition, but it doesn't need to because it wins the time-to-market competition. Getting to market and generating income is far more important than whether you'll need 2 servers or 30 servers for your first 500,000 customers....because you have 500,000 customers and that's the type of performance difference we're talking about in a web application. Iron.io wrote that blog post moving from Rails to a Go application but the reason it matters is because they were relevant already since their application got to market and generated an income. At that point, you refactor to remove the bottlenecks and there are a number of ways to do so without needing Go to get those type of gains in their situation. But that was the route they took...because they could afford to...because they had customers.
It's important to remember things like that when making these types of decisions. There's a reason Donald Knuth said, "Premature optimization is the root of all evil." If I strive for the fastest code, everywhere, I'm going to be learning a lot of languages and the time investing in all of those different language learning curves is going to keep me from ever getting anything done. It's also going to lead to an unmaintainable mess. This is something I understand too well.
Optimizing for time leads to some more sane decisions. Use one language for the bulk of your new "I need a thing that does this" development and use one language for the bulk of your "this thing that does this needs to do it faster" development. In other words, your 99% and your 1%. A 99% that addresses virtually every code problem you can run into in a timely manner and a 1% for when one of those solutions needs to be optimized beyond the limits of the initial language.
For the same reason, I use PostgreSQL as my 99% database solution because it does virtually everything you could ever want from a database, does it well, and does it freely so scaling isn't a licensing concern. If I run into a table that is so write heavy it needs a 1% solution, then maybe I use MongoDB or Redis or Hadoop or Cassandra or something else depending on the exact situation for that particular piece of data. I'd certainly never build an application around those primarily because they're only needed for the extreme niche.
There's a trend you'll notice when using different technologies: if there are a lot of different solutions to the same problem, there is an underlying reason.
You see this with PHP frameworks. PHP frameworks are easy to make because PHP is already a fully loaded web language and all the frameworks are slow because PHP is bad at frameworks.
So, my code is this: accomplish the 99% of use case in the shortest amount of time - minimizing learning curve, coding time, training time, wheel reinventing time, devops time, and scaling time. That is Ruby on Rails + PostgreSQL + jQuery out in the wild for web application development. For blogs and low traffic content it's Wordpress and MySQL. In an organization with existing technology and human resource investments, the variables in that formula as well as the result will change.
Once you find the answer for your situation, everything else is a niche use case...and that's how you cure Developaralysis. You apply your problem to your personal or organizational code and let that code wipe away all those shiny new toys that you want to play with, but don't actually need.
My name is Barry Jones and Brightball, Inc was my contract development company from 2008-2012. Although I no longer do contract work this site has become my personal blog.
If you enjoy my writing and want to support the habit please use my referrals to help me pay for my servers with Digital Ocean, my DNS with DNS Made Easy, my email with Sendwithus and my focus with Freedom.
You're also welcome to buy some things that I highly recommend, such as the best movie ever made, a hilarious cookbook for microwave dependent men like myself, the best travel laptop backpack I've ever owned, an awesome lap desk, some of the best headphones out there for the money or maybe an iPad Mini for the kids?