A couple of days ago I was sent a link to Robert Cringely’s latest treatise: The second coming of Java – and to say I disagreed was a bit of an understatement. To me, it represents a fundamental flaw in his perception of developers, and more importantly the economics of software development.
The key to Cringely’s argument comes down to this:
When SSDs gain enough capacity there will be a shift from the Ruby world back to the Java world. Not for prototyping, because, well, it’s prototyping. But simply because the statement “Ruby is incredibly slow but I don’t care because my database is slower” will no longer be true.
What he’s missing here is the real reason people use frameworks like Rails; it’s not about it being Ruby, or being the latest cool thing – it’s about developer productivity. That’s it, and that’s all there is to it – Rails allows a developer to do more in less time. That’s one of the key reasons so many Java web developers jumped ship (though I can think of a few others), and what pushed Microsoft to invest so heavily in their MVC framework.
I could fully rehash the argument, but in what I consider to be one of Jeff Atwood’s best articles, Hardware is Cheap, Programmers are Expensive, he covers a key point to my argument – developer time is vastly more expensive than hardware. Atwood’s take on the issue is clear:
Clearly, hardware is cheap, and programmers are expensive. Whenever you’re provided an opportunity to leverage that imbalance, it would be incredibly foolish not to.
When there’s a choice between developer productivity, and spending money on hardware – the conclusion should be the same. It’s much cheaper to throw more hardware at a slower framework than it is to invest more developer time in a faster framework. For any non-trivial application, throwing more front-end servers at it will always be cheaper than slowing the development process down with a non-productivity-centric toolkit.
It’s simple economics; server hardware is getting faster and cheaper, developer time is only getting more expensive.
I recently had an idea for a small web application, and seeing as I’ve not spent as much time as I’ve wanted to using Rails – I opted to build it the latest version of Rails. A decision that caused far more grief than I expected.
If you are using Dreamhost’s PS offering (a managed VPS for those that don’t know), the seemingly simple task of getting a Rails 3 application up and running is actually quite complex.
Before I get started, let me make a couple of things clear:
Apple is evil; pure and simple. I’m fully convinced that Steve Jobs has weekly planning meetings with Lucifer himself1. Apple’s policies are anti-everybody. From bloggers to developers2, Apple seems to make life as hard as possible for those that use their products for profit. With these facts in mind, I tend to shy away from their products when I have a choice (which isn’t always the case); though a while back I decided to buy an iPad for some reason.
In early December, about a month ago, I had the to perform one of the hardest tasks I’ve ever faced as a leader, letting my team know that a colleague had passed away. She was a friend to us all, and the glue that held the team together; telling them that she was gone was, without question, the hardest thing I’ve had to do in a work setting.
What made this so hard was not just what I was telling them, but my own feelings for her as a friend, and the opportunity I had missed.
Today, something happened that made me think carefully about my platform, my time in the spotlight, and how to best leverage my position to help others. Hopefully, you’ll find this to be thought-provoking and consider your own position and how it can be used.
Your Platform & Your Responsibility As a leader, there’s an undeniable responsibility to help others. This may mean being a mentor to someone just joining the industry, or giving opportunities to someone that would otherwise not get the break they need.
Communication can be a real challenge; working across cultures, backgrounds, experiences, and perspectives can result in different interpretations — and this is under the best of circumstances. However, when it’s written communication, the challenge is multiplied due to the lack of feedback cues from facial expressions, body language, and the like. These challenges make it exceedingly easy to create a situation where what a person hears is entirely different from what the speaker (or writer) intended.
