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.
// Share.on([hacker news,
linkedin,
twitter,
facebook,
reddit])
"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.
None. I know, I know...heresy. Javascript frameworks are useful for writing SPA's or Single Page Applications (or AJAX applications as we old fogies call them). Very, VERY few things qualify as a good fit for an SPA in my experience. Dashboards with lots of pieces of interactive data for one. Reports that you're going to keep on your screen full time are another. A tool used by people for long periods of time also qualifies.
Virtually every other application out there is an "open, check, close" site and for those (aka - 99% of web projects) there is no use for a Javascript framework...because Javascript isn't hard and jQuery took it from "not hard" to "stupid simple". Javascript frameworks take it from "stupid simple" to "extremely complicated" and since there isn't a dominant one out there yet, investing in the learning curve of one is probably a bad use of your time. Unless you're a dedicated front-end developer, in which case...peace be with you.
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.
You're seeing the same thing with Javascript frameworks. There isn't a "right" one because you don't really need them since jQuery already gave you virtually everything you need. Unless you have a data heavy, SPA, that's going to be open for a long time...you probably don't need to invest in a JS framework...because Javascript isn't hard.
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.
// Share.on([hacker news,
linkedin,
twitter,
facebook,
reddit])