To subscribe to my feed, add the following Url: http://feeds.feedburner.com/jeffreypalermo.
I spent the first part of my career on the side of the fence where I want to make it fast first. In fact, I wanted to keep it fast all the way through.
I'm talking about software. Performance optimization. Speed.
There was a time when every time I concatenated a string I weighed the theoretical pros and cons of using the plus operator vs StringBuilder vs. string.Format(). I even measured differences. I've now come to the point where I realize that PDD (pain-driven development) is the real decision-maker. It's no longer worth my time to think about what concatenation method might be faster. Compared to a single database call, the speed different is irrelevant.
Point: A well-designed application can be tuned at any conceivable place after it's working correctly. An application that has "performance optimizations" coded into it from the start has less flexibility for the inevitable bottleneck that surfaces unexpectedly.
Point: I will not guess at what part of my code will be a bottleneck unless I have past experience in the exact same scenario. Rather, I will lead the team to create correct software that _appears_ to be fast enough throughout the project. At an agreed-upon time we'll profile (with the appropriate tools - yes, I mean _measure_) the application and find any bottlenecks that are not acceptable for production. Then, with real data in hand, we'll tune exactly the right parts of the application. We will not guess before measuring. After measuring, guessing is not necessary.
Point: First make it right. Then make it fast.
In general, out of process calls are performance bottlenecks, not in-process logic. Either way, measuring tells the truth, not guessing.