Comments on "Thinking Inside the Box and Premature Optimization"
Here are my comments on Matt Podwysocki's post on premature optimization. Since I was also at the last DC ALT.NET we are just continuing our discussion.
All programming languages, frameworks, operating systems, databases, etc. have known best practices and many of the best practices are related to improving performance. I don't buy into the argument that following best practices is premature optimization. If you are going to implement something and it takes no more effort to use the best practice than it does to use a non-optimized approach then it makes no sense to me to implement things sub-optimally. Poor development habits beget poor development habits. Unless you are building trivial applications the aggregation of non-optimized software can have substantial negative impact to the application.
Unless you are new to software development you have some knowledge and experiences to bring to bear on the new thing you are learning. If you know the .NET framework and you are learning the Java framework, then you can apply lessons learned from .NET to Java even though it may not always be an apples-to-apples comparison. Implementing efficient algorithms, managing resources efficiently, minimizing I/O, building secure code, etc. are things that most software applications needs to worry about. It isn't too difficult to apply what you know about .NET to learn the equivalent thing in Java, or vice versa.
Should you think five steps ahead or not? I am a strong believer in defining a project's vision and requirements and letting them determine where the design and implementation should go. You should only design and implement the minimum features needed to meet the customer's requirements, however not taking into account the project's vision early in the project can result in some very costly redesign later in the project's lifecycle. Some applications are complex and require a certain amount of thought about the future. I agree with Matt that developers tend to carry implementation from project to project, unfortunately this isn't a good idea unless it satisfies the project requirements. I find that the less experienced developers are the more they practice the "whatever I did on my last project is the one true way" style of development.
So, what is it about the belief that learning "insert language or framework here" is a solution to design and implementation issues? I view this as the Survivor-style of development. Put yourself on a stranded island with minimal supplies and you will learn to survive, sometimes very well. Having learned a lot of programming languages and frameworks in my career I am very skeptical that there is a panacea to design and implementation issues. Most developers know how to implement complex solutions (or poor, complex solutions). It takes a lot of talent to come up with a simple solution. There was a time when Java, .NET, and other frameworks were considered to be lean. If Ruby on Rails achieves a substantial following then I am sure that we lament the bloat in it someday. I think it is inevitable that popular development frameworks will have additional frameworks added or ported. You shouldn't get frustrated by this. Instead, you should learn to use the minimal features needs to solve the problem you are working on.
I like some of the things I have read about Domain-Driven Design, but unfortunately I feel like it provides us with a small step forward, but not any major improvements. In general, I am still very disappointed with all of the modeling approaches: data, object, domain, etc. First, models are difficult to map back to requirements so it is very hard to have a meaningful discussion about the model with users. Second, models have a hard time accurately and completely describing solutions, especially complex and/or large solutions. Third, keeping the model and code synchronized is very difficult and costly. As much as we would like models to remain valid throughout the entire lifecycle of an application, the reality is that very few projects maintain their models past the early stages of the project. Fourth, I believe that many of the most successful solutions built were built without much modeling, certainly without a complete system model. So, where am I going with this? We need to glean whatever tidbits of knowledge that we can from the design gurus, but we need to be realistic about how much time we spend in the code vs. the model.
