Auren Hoffman has a good post on TechCrunch about how now might be a great time to cherry-pick the best software engineers available, and how it can pay off not only in the short term, but also over the long, to hire high-quality developers and spend money on developing them individually rather than hiring more, lower-quality developers. I find that a lot of companies do too much of the latter — but often the cost of hiring more and cheaper is so obscured by differing workloads and hard-to-quantify ‘quality of output’ that it may never be evident. In some cases, though, it can be quite evident — as in the study cited here in Joel Spolsky’s post describing the time taken by students to accomplish the same assignment… and their scores. I’ll steal just one graphic from him:
This graphic shows that some students finished in 12 hours what others took 50 hours to do — with roughly equivalent quality!
I’ve seen this personally, as well — we probably all have — where you know one developer can do something twice as fast as another… so why aren’t more companies hiring based on that? If you have to pay 1.25x as much for a developer who works 1.5x faster… wouldn’t you take that deal? I wish more companies would.
Read Full Post »
Over at the EngineYard blog, they have a couple of posts on working with RoR apps at scale, on general scaling and on sharding your database. We’ve had to do a few of these things already for certain customers and will hopefully have to do more in the future, but I think one of the important takeaways is that you shouldn’t do any of these things before you actually have a need to.
Almost all optimizations for performance are going to introduce some amount of friction in your development process and possibly add failure points, as well — and if you have a solution that works right now, and is going to work for what you estimate the load to be over the next month or two (depending on your release cycle), then you have solved the problem you have right now, and should spend that time adding features or fixing bugs instead.
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%” — Donald Knuth
In a comment to the page, Gregg Pollack points to his screencasts on Scaling Rails — I haven’t watched them yet, but he had a good session on ActiveRecord at last year’s Lone Star Ruby Conference.
Read Full Post »