3 ms·
I think he is assuming way too many things to be constant, and then using that to justify his thesis of addressing efficiency concerns only just-in-time. The b
by azanar 17y ago
I think he is assuming way too many things to be constant, and then using that to justify his thesis of addressing efficiency concerns only just-in-time.
The biggest concern I have is that he account nowhere for growth of that new feature, and the increasing hosting costs as a result of that growth. Part of efficiency is how fast is it now; the other half of efficiency is how will the performance change based upon an increased load.
Part of the risk of putting out a new feature is you don't entirely know what the uptake will be. It could fall flat, it could grow exponentially within the first week. Or, as this author assumes, it could enjoy a rapid uptake of a certain amount, and then level off just as quickly. I'd argue this last possibility is almost never the observed pattern.
The other part of the risk is that, if you go the inefficient route, you may not have the time later on to even build bad hacks within the inefficient code to make it speedier. This is a bad situation to be in, you end up getting screwed by your own unexpected success, and users get pissed because now your site is unreliable.
Yes, spending insane amounts of time on efficiencies probably aren't worth it. Yes, you need to do cost-benefit analysis to decide what amount of time is. My point is that there is a lot more to consider than the author gives credit for, and I don't think you are as likely as he believes to reach the same conclusion he did. Cash flow is important, but it is also important to remember that things don't remain flat or grow linearly just because you assert that they do.
- Mz 17y agoI think it is worth pondering, especially for anyone in danger of being so perfectionistic that they are looking like they might never ship. I got a link to the Duke Nukem Forever story from one of the comments. I am currently feeling like that about some of my goals -- like I piddle and fiddle and tweak and never accomplish anything. Maybe I am just having a bad day (heck, that's very likely -- I am treating a sinus infection), but this article meant something to me personally. Yes, you need to not just fuck it up royally. But, like with Duke Nukem Forever, you really can err terribly in the other direction as well. Thanks for your very well-thought out and meaty comments.
- gridspy 17y agoThere are many choices like this - put time in now to save time later. Recently I decided to take the time to make our system configuration for a new user really easy (I was doing it by hand in a slow way before) because I know that once we have many users I won't have the time to fix the admin interface around the time demands of doing it by hand. There are lots of decisions where you don't know up front the cost of an inefficient solution - perhaps the feature is underused and it doesn't matter - you've wasted time making it fast. Perhaps you become a success overnight because of the feature but now your server is fried. It is a tough call - either way, you should spend some time thinking about how you would throw more hardware at the problem should it arise. Gridspy is still pretty tiny load wise, but I have put a lot of thought into scaling plans, keeping my options open.