Perhaps its relatively synchronistic that I began this new project with this new client right before TechEd, during which all of my colleagues will be finding out about all this new stuff coming out with Whidbey and yada yada. Perhaps its a little weird that, during TechEd, I was reminded of a really interesting fact...
That there are people out there who are still learning the proper usages of the 1.1 Framework.
Even still...
There are some people out there who are using 1.1, but haven't quite grasped the power that it provides them, because of the fact that the overwhelming amount of work dictated by their employer dictates the “just get it done” paradigm.
Point, Mr. Gaster? Simply, there are people out there who are incredibly intelligent, who know technology, but because of the fact that they have applications to build on a daily basis, they don't have the time to really understand some of the unpderpinnings of .Net. That fact proves one very important thing to me -
We as a population are guilty as all hell of jumping the gun far too often, and as a result leaving many in the proverbial dust, forever to play catchup while we move onto other technologies. We as developers are a fickle group of people.
Some of my peers are good at .Net, others suck at .Net. Some still even hate it. And within all of those groups, there are members who really rock as programmers, but haven't had time to learn about delegates, events, attributes, reflection, inheritance, polymorphism, implementation, collections, design patterns, and all the other goodies we sometimes take for granted.
The team with whom I'm working, for example, contains a lot of individuals who have these nice little friendly things called deadlines and requirements, and for those reasons, are still writing procedural, ASP-like code.
[Okay, close your mouth and stop looking so shocked. You have lots of spare time, and for you (like me), technology is not only a job, its a passion/addiction and you revel in learning all you can about it. Sometimes, the application isn't as important as the vehicle. Stop looking so surprised for one moment while you're learning about all this new stuff and remember that, outside of that ivory tower in which you work, there's this real world, with money and requirements and users and developers and deadlines and all other sorts of things that aren't always as black and white as the code.]
Here's the deal - stop for a moment. I challenge you to go find one of your peers who's working with .Net, who's been grappling with a particular project for X days/weeks/months. Then, ask them if you can look at their code. Take a look at what they're doing wrong, and show them something new. Take an hour and use all that knowledge you've picked up about refactoring to help them split that hairy function into little pieces. Help the guy who's been struggling with his new web application build the reusable stuff into a web control so that he won't have to do it over and over and over again. Better yet, help the guy next to you who's having issues with his data layer, and assist him in the development of a simple ORM class structure. Or whatever the case may be - take a moment and help someone who hasn't had the time you've had to learn this stuff do it in a better way.
This team I'm on - they're awesome, each one of them - but they haven't had the time I've had to learn how all of this new stuff works. Some of their code lacks organization. Some of it could be refactored. I looked at an app yesterday that's simply beyond refactoring because of the sheer complexity of the business logic, which had to be hard-coded (and trust me, I'm not slacking on this - I implemented two brand new architectures over the weekend to accomodate this beast and neither ended up working because of the fact that this puppy is so freaking specialized there's no way it can be encapsulated).
If we as a developer community forget these very important people - those who are consulting, developing, maintaining, or architecting each and every day of their professional lives for clients, employers, or non-profit organizations whose businesses depend on deadlines (and not newfangled nify-ness or “oo-ah code“) - there's no point to the whole industry of information technology in the first place; what good is an industry whose sole purpose is to further itself and “be better“ if those using it haven't the time to learn how to properly make use of it?
Sure, you could call youself a “computer scientist” and argue that your career revolves around the “newfangled niftyness.” But for those of us out here in the real world who are trying to make business succeed, there's a different need. If the developer community exists solely to drive technology, what community exists to support the “enterprise developers” out here in reality who have to do something for our organizations? What community exists to teach my new partners-in-crime the “right” and “wrong” ways of doing things? Who is responsible for looking at the “new procedural C# code that could have just as well been written in VBScript?”
I'm out here doing it, and I'm not at TechEd. I'm giving a seminar for my team in the upcoming weeks on the proper usages of Delegates and Events, so that they might get some of their own “a-HA!”'s and find the kind of joy I've found with those two lovely little tools. Next? Maybe a lunch-and-learn on Attribute-based coding. And then, who knows?
One thing is true - I'm not going to show them things that they don't need to know. I'm not going to mention Whidbey. Why? They don't use it, they have no plans of moving to it any time soon. And more importantly - clients like this make mistakes because they haven't had the time to learn the stuff. They're too busy w-o-r-k-i-n-g for their organization, helping their team, and helping their internal customers. If these misuses continue to flourish, chances are they'll assume that “.Net isn't that much better than ASP.”
If that happens, what's the future of Whidbey? Or Microsoft? Think about Java - it was too complex, too slow, and Sun did a pretty crappy job of informing people on the best ways of doing things, because there was so much focus on coming up with better ways of doing what needs to get done done today. What happened to Sun? And to Java?
Reminder - .Net just took over in terms of acceptance.
All I'm saying is this - take a moment to remember the others out there, who are actually using .Net and coding as a means to a larger end. There's more to it than just code. There's more to it than niftyness. There's a whole big real world out there that continues to run because of technology. Don't let all those people working get left in the dust because 1.0 or 1.1 is so “yesterday.” The developer community needs to remember one very important thing -
If you keep pissing off the people who employ you because you're so focused on the technology for it's own sake and don't ever build anything with the toys you already have, you have no one to thank but yourself when the technology ceases to be accepted and applauded because nothing ever “worked” with it.
My new client has some standards in terms of dealing with exceptions. At this point, everything - and I mean everything - is being done in heirarchical try...catch blocks. I'm thinking that using the Page.Error event handler might be a better way. It would indeed allow for much less coding and simplified/centralized exception management. But that's not enough - I'm on the lookout for any articles or documentation benchmarking the differences in execution time between using try...catch or the more robust-feeling event methodology. Web forms would be best, but WinForms benchmarks would suffice too.
Anyone know of anything out there like this? I worked up a sample snippet of code to demonstrate this, but I'd like to get a little more information from MS or any other reputable source.
Bueller?