Oren Eini made a great post the other day on his blog about some of the “experienced” .NET developers he has come across in interviews.
I found this part most interesting:
“I had a discussion today about the value of using a non-Microsoft framework for a complex application. The point that came up repeatedly was that they want to jsut grab a programmer from the street and have then start fixing bugs from day zero.”
This almost exactly describes my first professional experience with .NET. During some bench time while consulting, I was assigned to a local custom application development project that needed a few extra bodies to do manual regression testing for a few weeks.
Yep, you heard that right. I had to go from being a developer to being a manual tester. However, I assumed this was a temporary role (just a few weeks after all) and it gave me the chance to avoid traveling for a while after recently getting married.
After only a few weeks of grueling manual testing, I started peeking over the shoulders of the developers (who happened to be coding in .NET). With a little bit of background in writing JSPs and VB/VC++ win32 apps, I found it easy enough to put things together and understand the basic structure of the framework. After fixing a few bugs on my own, it became clear to the project managers that I was far better at fixing bugs rather than finding them. I was officially made a development resource and enjoyed my rebirth as a .NET developer. My induction ceremony consisted of being assigned about 20-30 medium/low priority bugs and told that they needed to be fixed within half a day. Joy.
So technically, I am a Poster Child for why companies choose the .NET framework and not something with a perceived steeper learning curve. By abstracting away many of the important details of the HTTP protocol with fancy wizards for everything, .NET sounds fantastic. It is pitched as being relatively easy for any developer to pick up in a very short time.
This could not be farther from the truth. While .NET has the appearance of being relatively simple and easy to use, it’s also very easy to grossly misuse it. The most common trap most new ASP.NET developers fall into is the dreaded Death By ViewState. ViewState is a powerful thing and all new .NET developers should make every effort to truly understand it.
In my situation, I initially tended towards the side of caution every time I changed a single line of code and commented the hell out of everything. That way, if I screwed anything up, a more experienced developer could easily fix it. Had I been a typical Cowboy Coder, I could have done some real damage to that application. This project also had no concept of unit testing or automated builds and barely had source control. Taking all of that into account, it became clear that there were huge risks in bringing new developers onto the project.
The bottom line is that it’s always a risk to bring in a new developer. A developer with X years of experience with a particular framework gives no guarantee that they can spit out great code. Standardizing on a particular framework won’t ever insulate an organization from poor developers. The only real solution is to involve existing succesful developers in the screening process for new candidates. And existing successful developers should be equally willing to be part of the hiring/interview process. After all, no one wants to waste time reading Talmud-like code.