I think we're being a little harsh in this case and really overstating never optimize prematurely like it's some kind of religion. Optimization is built in to

I think we're being a little harsh in this case and really overstating never optimize prematurely like it's some kind of religion. Optimization is built in to most web stacks. Database caching for example. For rails this is convention over configuration when you're running with the production flag. Plus there's all sorts of other optimizations going on at every level, because it's suspected that even if a lot of applications don't need them, to not bake them in will cripple and add undo complexity to other apps. This adds tons of complexity, but it's well abstracted. And many of our apps don't need this... so it's premature definitely, but it's a pretty fast and fun stack to build with. I think it is completely acceptable to perform certain types of optimization, even prematurely perhaps, provided the cost of these optimizations is low if you think there's a decent chance, or have a hunch that you could get into trouble if you don't. Experience teaches you which assumptions to make, but it's definitely not a perfect science. Sometimes you overdo it and there's a cost, but there's also a cost if you underestimate as well. It's an effort we make as developers to balance between the two. So in this scenario, caching some pages to me sounds pretty acceptable, or at least border line. He implemented the caching in a very simple, basic, and well known commonly accepted way. No memcached or anything fancy, just static page dumps. He's running on a 256 VPS slice, which is pretty slim for a business, so it's not too hard to imagine he'd run into problems if there was even a small spike in traffic. Plus, his traffic is decent. I for one would probably have cached as well, at least the landing pages anyways. He got in trouble sure, and as a direct result of his caching, but these things happen when you're running everything yourself. I don't think it's due to bad judgment. This reminds me of another statement that is often taken to the extreme. "Launch quick and get it in front of people. Don't assume you know what your users want." I think it's a pretty good reminder once you start to go too far, but of course we all know you still need to make many assumptions just so you have a product. There's not much value in the canvas alone. These little gems like "Never optimize prematurely" won't do your job for you. The reality is too fuzzy, and that's why you get paid. I hope this doesn't sound like a harsh reply. I do agree that there are many cases where people go crazy with optimization, features, etc, and it's good to have a little mantra like "Never this, never that". I just don't think he's guilty of any of these in this case is all. The cron was a blunder many of us have experienced. It cost him though, and he's learned that lesson well now I bet. I always learn best from my most costly mistakes.