About the "Study Path" for new technologies
This is nothing earthshaking; its something I feel strongly about, however. This relates to your personal philosophy about how you handle new technologies as they move through the BETA and into the release phase. Specifically, I am talking about Visual Studio.Net 2005, Sql Server 2005, and .NET Framework 2.0. Your views may differ.
Generally speaking, when you get to the point of a BETA 2 or later with some sort of "Go Live" permission license, it's time to crack the books and get serious. RTM is not far away, the Assembly version numbers will not change, and most of the changes (obsolete / new or deprecated) have already been "baked".
What remains is tuning, fixing little things that are still not working 100%, and codebase optimizations that don't really affect method signatures, namespace or class names, and the like.
What I guess I'm trying to say is that its OK to start developing production software with VS.NET 2005 Beta 2. 95% of the software you write from this point on will work great under RTM. I know people that actually started developing production sites and software with VS.NET 2005 a year ago.
There are two kinds of development environments in the world - the ones that say "No, we won't install any beta software or platforms, and we don't want our people working with it", and the ones that say "This is exciting and has a lot of new features, let's set aside some time to work with this is a measured way so that we can be ahead of the curve, be in a position to exploit new technological advances, and also to look at what we are currently doing with a clearer view toward how it will fit or need to be changed for the newer platform."
If you are in camp number 1, I don't want to work for you, because you are "behinder than you think", and you will likely ALWAYS be that way. You can come up with all the rationalizations you want, but you aren't going to impress me. I just want to "Be there" and you are gonna hold me back. We simply don't FIT.
There is a lot of studying that needs to be done with .NET 2.0 and its associated tools. My philosophy is to try and understand as much of it as I can in advance, before I even think i will need it. The reasoning behind this is really quite logical. If I don't study generics and iterators now, how will I ever know what they can do for me later on? In other words, if I don't understand or know about a particular technology or feature, how likely is it that I'll have a broad enough architectural view of business problems to even know that I should consider using it in a solution?
An example of what I am talking about is Community Server - Rob Howard and his group were, in varying degrees, involved in the development of ASP.NET 2.0 and you can see the influence in the current version of their forum / blog software for 1.1. They have stuff in there for personalization and providers and so-on that they knew would be in ASP.NET 2.0, maybe under a slightly different name, and they didn't have it yet in Framework 1.1, so they rolled their own for version 1.1 and it made the software better. And, when they go to convert it and upgrade it for 2.0, their job will be that much easier.
Made my point. Crack those books, dewds and dewdettes.
Generally speaking, when you get to the point of a BETA 2 or later with some sort of "Go Live" permission license, it's time to crack the books and get serious. RTM is not far away, the Assembly version numbers will not change, and most of the changes (obsolete / new or deprecated) have already been "baked".
What remains is tuning, fixing little things that are still not working 100%, and codebase optimizations that don't really affect method signatures, namespace or class names, and the like.
What I guess I'm trying to say is that its OK to start developing production software with VS.NET 2005 Beta 2. 95% of the software you write from this point on will work great under RTM. I know people that actually started developing production sites and software with VS.NET 2005 a year ago.
There are two kinds of development environments in the world - the ones that say "No, we won't install any beta software or platforms, and we don't want our people working with it", and the ones that say "This is exciting and has a lot of new features, let's set aside some time to work with this is a measured way so that we can be ahead of the curve, be in a position to exploit new technological advances, and also to look at what we are currently doing with a clearer view toward how it will fit or need to be changed for the newer platform."
If you are in camp number 1, I don't want to work for you, because you are "behinder than you think", and you will likely ALWAYS be that way. You can come up with all the rationalizations you want, but you aren't going to impress me. I just want to "Be there" and you are gonna hold me back. We simply don't FIT.
There is a lot of studying that needs to be done with .NET 2.0 and its associated tools. My philosophy is to try and understand as much of it as I can in advance, before I even think i will need it. The reasoning behind this is really quite logical. If I don't study generics and iterators now, how will I ever know what they can do for me later on? In other words, if I don't understand or know about a particular technology or feature, how likely is it that I'll have a broad enough architectural view of business problems to even know that I should consider using it in a solution?
An example of what I am talking about is Community Server - Rob Howard and his group were, in varying degrees, involved in the development of ASP.NET 2.0 and you can see the influence in the current version of their forum / blog software for 1.1. They have stuff in there for personalization and providers and so-on that they knew would be in ASP.NET 2.0, maybe under a slightly different name, and they didn't have it yet in Framework 1.1, so they rolled their own for version 1.1 and it made the software better. And, when they go to convert it and upgrade it for 2.0, their job will be that much easier.
Made my point. Crack those books, dewds and dewdettes.
Comments
Post a Comment