Right after getting back from RailsConf I headed off to a family trip to Southern California. I only just got back this weekend and I feel like I haven't quite had the time to fully digest the conference. As a result I've had a lot of odd thoughts rattling around in my head, most of which have failed to form into anything cogent. Well, except for one..
One of the important takeaways I got from the conference wasn't specific to Ruby or Rails, but rather a larger concept of leverage. It occurred to me that the people and organizations that are really shaping our technological lives are doing so by a judicious application of force. Our world is simply to complex to blindly apply raw force to problems. Instead it seems to me that the thought-leaders are finding and using force-mulitpliers of various types to build the future. Three examples of this pop into my head. Whether or not they constitute the best examples is debatable, but I believe that they all share a common underlying principle.
The first is Ruby on Rails. I'm not here to sing the praises of Rails and tell you that you should do all your web dev in it. I happen to like Rails and think it's got a lot going for it. But for the purposes of this post I want to talk about the choice by its creator in using the Ruby programming language as the foundation for Rails. For the Rails team, the choice to use Ruby was crucial to the success of the framework. Not everyone likes Ruby and that's fine. But it is a high-leverage language. I'm not aware of anyone who has adopted its use and not become more productive.
The Rails team and David Heinemeier Hansson deserve a lot of credit for developing Rails, but a lot of that credit should go towards the decisions they made about the tools they built and their choice of technologies to rely on. Rails isn't worth looking at because it's an ingenious piece of engineering, Rails is worth looking at because it applies maximum force with minimal effort.
The second example is Google. It's hard to imagine web-life without Google. But what makes Google so special is not simply that they apply sheer mass of brain-power to sheer mass of computing-power (though it doesn't hurt). Instead it seems to me that Google has made the major effort up-front to build the world's must powerful clustered system (i.e. their core search engine), then they have leveraged both the data and the infrastructure from that core for their other services. The things they are doing with Docs & Spreasheets or Google Gears wouldn't be possible without leveraging that first asset and these types of products are clearly part of the next generation of services.
My final example is similar to Google, and that is Amazon Web Services. Much like Google, Amazon has built an impressive infrastructure to power their core retail business. At first glance AWS seems totally unrelated to that core business. But a second look reveals some pretty smart thinking.
What Amazon has on its hands is a massive amount of computing power setup across the globe. Amazon's chief asset is the very infrastructure that its retail business is built on. AWS is simply the commercially-available version of that infrastructure. Whether Amazon has excess computing power that it's selling or it has figured out how to grow that power is largely irrelevant to this discussion. I'm assuming that Bezos and his minions are smart enough to figure out a way to sell this service and not make it a loss-leader. The important point here is that AWS could be a very disruptive technology. The flexibility and scalability that AWS provides is something that simply doesn't exist at a price-point where anyone can use it.
I don't think Amazon's retail business is going to shrivel and blow away, but I think the creation of AWS reveals some shrewd long-term planning for the overall health of the company. Clearly Amazon is attempting to diversify and it is doing so by taking advantage of its greatest assets. The server infrastructure Amazon is the force-multiplier behind AWS.
So while these three examples may seem a little disparate and scatter-brained I think they reflect an overall emerging trend in high-level thinking. Think of job interviews you may have had where someone wanted you to implement a merge-sort algorithm or write a database connection pool. I understand the mechanical intent behind these questions (does the candidate have basic technical skills?), but the answers that are typically sought miss a more important point. If I were to give that question to a prospective candidate I would hope they would answer with one line of code that calls a built-in sorting routine that comes with whatever platform we're using. I simply don't care that they can write a merge-sort. I can't imagine working on a project where its success was dependent on us writing sorting algorithms. So I'm much more concerned with whether or not they know how to use it and what it means in context.
The sheer amount of information to master in our technical fields is daunting. Frederick Brooks acknowledges this in the 20th anniversary edition of "The Mythical Man Month" by lamenting the fact that he has simply had to stop following a number of developments in the field. We can't keep worrying about bit-shifting and low-level algorithms and hope to make any progress. While there has to be somebody who worries about this stuff, we need a much larger population that leverages these tools to build something truly wonderful. In short, let's find those things that let us get maximum force with minimal effort. For me right now, those things are tools like Ruby and my beloved MacBook Pro. As time goes on I'm sure I'll new tools to supplant these. The important thing is to keep evolving and adapting to find that leverage.