Every good developer knows that you don't want to spend too much time optimizing code as you're writing it. Premature optimization is Eric Gunnerson's 4th deadly sin of programming. I don't think that's over-exaggerating the problem.

But how do you know when you're going too far? Let's say you're writing a class that will be transferring data to or from somewhere else. When you find yourself thinking something like, "What if there's a ton of data being transferred? I need to change the format and consolidate information to make sure we send as little as possible." you're optimizing prematurely. You don't know that you'll run into that situation, and if you fix it now you're spending time fixing a problem that may never exist.

I recently ran into a situation like this, but instead I was thinking something more like, "According to the customer, there will possibly be tons of data to work with." Now I know that there will be a lot of data, so it's not premature to think about how that will affect performance. However, I don't know how bad my code will perform with the amount of data we'll have at production, so I don't know for sure that I need to spend time on the issue. There actually isn't an issue yet, even though the likelihood of a problem is much higher. Do I want to optimize in this case?

The feedback I got from my team was to not spend any time on optimization until the problem actually exists. I think there's a fine line between premature optimization and optimization based on known factors. I'm still not sure if I'm doing the right thing, but I'm going to follow the methodology and see how it works out.

Labels: methodologies