My last post received a rather long comment from 2kMediat.com whose article I referred to in my post. Although I rarely respond to my feedback in public, I wish to do so in this case. This is mostly because Mr. Kortelainen replied in a professional manner - in a way that allows reasonably useful discussion to continue. Please do read his whole comment; I'm not quoting it fully here. I agree with many of the points and will only bring forward those sections I have something to add to.
"If it [the article] would have contained indepth issues like components or webservices about 90% of readers would not have understood a thing (remember, the year was 2002)."
I definitely agree! Simplifications are fundamentally important for teaching and learning. Actually, in a sense, abstractions are everything programming is about. However, simplifying things ("ASP.NET provides a totally new way of designing web sites") is a concept entirely different from providing a partial view ("The most important aspect of ASP.NET is (insert any nonsignificant feature)"). The first one is about reducing depth, the other one is about reducing breadth. Both approaches have their uses, but the latter one very easily provides a very distorted image - in this case, stating that ASP.NET's key change from traditional ASP is the lack of ability to provide a multi-language code file hardly does ASP.NET justice.
While it's true that beginners in 2002 would've been very unlikely to understand f.e. the control model, you shouldn't just have ignored it. If you were unable to write a tutorial that helped them understand the technology, that's fine - but you should've certainly limited your writing to what you can reliably present. Even if you can't popularize a concept well enough to teach it, you should never skip your educational duty of providing the big picture - in this case, telling what ASP.NET is really about. Even warning people that you're about to cover only very minor details of the system would've helped.
Technicly incorrect? I want to see an aspx/1.0 written with 2 or more languages inline (note: inline!) code compiling happily. The last time I checked that was impossible..."
Yes, true for inline, but you didn't say so in the article. This isn't just nitpicking, it's a very relevant issue. When running on a platform where all languages have nigh-equal abilities, you don't need multi-language support for using features such as regular expressions. When you want to use multiple languages for the purpose that was in mind when designing ASP.NET - allowing each developer to work in the language of his/her preference, you quickly realize intermixing several languages in a single page is actually a horrible idea. Page/control/business logic separation is the way to approach it - and in practice I have much trouble imagining a situation where inline language mixing would actually be beneficial over the separation of controls and/or assembly layers.
My point? Simplification ("You can't use several languages on a single page") might be acceptable despite its misleading nature, but calling this the most important difference is entirely another thing. It's reviewing ASP.NET technology from a perspective that is neither valid or supported by Microsoft's own material. It may be the one intuitively possessed by classic ASP coders, but training companies most certainly shouldn't support such an outdated view.
"I wish mr. Heikniemi would in future make some background checking before writing blazing opinions about other sites content in public. It can be one nasty piece of bad publicity (especially since we are a training company with some really heavyweight clients)... I realize that anyone can write whatever he/she wants in personal websites (after all, all human life is based on opinions), but putting an 3 year old article on the table as an example of "bad technogical views" is relatively harsh."
Oh, come on. What background checking? Nowhere in your article can I see the date it's written on. Even if there was such a date, "a training company with some really heavyweight clients" cannot hide behind such details. Google finds older writings just as it does the brand new ones. In general, do you expect your heavyweight clients to verify all the information you provide for accuracy? If one of your publicly available web courses is outdated, mark it as such or remove it.
People just don't get it. Every week I bump into a living example of a person who has enormous misconceptions on what's going on in the web development world. If you can read Finnish, take a look at 2kMediat.com's ASP.NET tutorial. Among the text, it is stated that (translation mine) "The most important difference between ASP and ASP.NET programming comes from a single issue: ASP.NET doesn't allow using several programming languages on the same page."
Apart from the fact that it's technically incorrect, it shows a fundamental misunderstanding of the whole technology palette that .NET represents. "The most important"? How many of you guys ever even wrote an ASP page with several languages embedded? How many of you even knew it was possible? And these are the guys posting tutorials...
My point? Microsoft is pushing out .NET 2.0 with the new ASP.NET 2 platform. We have another great wave of great technology coming about, but most people don't even faintly grasp the dimensions of the current .NET Framework. My prediction is that this will have two key consequences:
1) The rift between hobby coders (most commonly using PHP) and the professionals (ASP.NET, modern Java) will be broader. As shifting from a hobbyist status to a web coder pro will be harder, there will be increasing demand for proper education. Since it won't be sufficiently available, many professional solutions will be created using inappropriate tools and lacking knowledge, falling back to what we saw in today's example.
2) Even though the chasm is wide, many will jump. We'll have loads of "experienced ASP.NET coders" who have no idea on what they're really doing. The control model provides more than enough tools for creating a total mess - The Daily WTF will certainly thrive and Microsoft's platform will get the blame for bad code.
Mr. Time, please prove me wrong.
In late July Microsoft published IE 7 beta 1. But what? It's not public! Now it's time to scream! Really, reading the IE team blog's post with all its comments is... enlightening. I'm a bit surprised we've got to the point where people start whining when a beta isn't public - it's not like public betas had been the standard operating procedure all along anyway. Of course, open source projects have a different concept of beta releases, but why should it be so for commercial applications?
A public beta is making your users test the software for you. This is something people loathed at a time, saying that software houses should do the testing stuff themselves. Of course, a beta is also a chance to see a preview and get ready for new technology, but still - early betas rarely always provide truly useful insight into the interesting new things. It's mostly about testing and reporting bugs, really.
Contrary to what one might initially think, getting as many bug reports as possible is not beneficial for the quality of the product. Getting as many bugs reported as possible is what you want. Although more testers provide more feedback and thus more useful findings, the signal/noise ratio drops dramatically as the number of eager testers rises. Remember some of the Mozilla suite's releases when bugzilla.mozilla.org was flooded with duplicate/invalid bug reports?
Now, if Microsoft has the testing department that's sufficient for the product's current phase AND they know IE7 is unfinished enough not to be ready for everyday use, why should they release a public beta that's bound to get them kazillion bug reports on issues they already know about?
Looking at the various reports people have written on IE7, I'm inclined to believe this wouldn't have been the phase for a public beta. But as a more general phenomenon: Microsoft's first betas have often been rather shoddy tech previews. Beta 2s, on the other hand, have often represented nigh-production quality. It'll certainly be interesting to see both IE7B2's quality and release model. At least a lot of promises have already been made.
There are several roads to quality software, and not all of them involve slipping out pre-production software to everybody who happens to want it. Different resources and methodologies give room for different approaches. At the end, judgement by final product is the only fair way.