Wednesday, February 27, 2008

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.

Monday, February 18, 2008

First blog

I am going to dip my toe in the blog pond. I spend a lot of time reading blogs, but I have always made the excuse of being to busy to blog myself. I have been in the computer industry 30 years. I have had the fortune to work on a lot of interesting projects, played with a lot of interesting technologies, and met a lot of interesting people along the way.

Here are some things I am interested in.
  • Large-scale data management. I am a child of the RDBMS era and have used Oracle since 3.0, Sybase since 1.0, and SQL Server since its first release. I have a lot of experience squeezing every drop of performance out of these products. There are lots of large-scale data management issues that interest me, but the current RDBMS products are having increasing difficulty playing in this space.
  • Internals. I love to tinker with operating systems internals. Early in my career I spent a lot of time in the Unix kernel, but in the latter part of my career I have spent more time in Windows internals than Unix/Linux. Since .NET was released I have spent as much time as possible learning the .NET framework internals. I never spent any meaningful time learning Java VM internals, not because of any dislike of Java, but just due to lack of time.
  • Project recovery. I have spent a significant amount of my career helping to bail out failing projects. Anyone who does this more than once or voluntarily is a warped individual. I get a sense of satisfaction knowing that I found and solved problems that no one else wanted to touch. Project recoveries involve:
    - Identifying and correcting systems lifecycle dysfunction.
    - Diagnosing and solving hard software correctness problems.
    - Diagnosing and solving performance issues.
  • High productivity. I enjoy studying tools, processes, and personalities to determine what makes individuals and teams highly productive.
  • Computer industry trends. I feel fortunate that my job is also my hobby. I can't imagine ever getting bored with my job. There are thousands of new things to learn every day.
  • Chicago Cubs. I have been a Cubs fan almost from the day I knew how to spell baseball. I am used to "waiting until next year". One of these years ...

Kevin Hegg