News

Wanted: A brain the size of a planet

I recently took the beta versions of Microsoft's upcoming Application Security exams on the MCAD.NET/MCSD.NET track (70-330 for VB .NET and 70-340 for C#). They were, to be frank, brutal. I've been taking MS certification exams for more than a decade now (isn't it time to retire yet?) and usually I leave the test center knowing that I passed. This time around, I was wrung out, and I'm still not sure what the score report will say when it comes back in a month or two.

But the experience got me to thinking: the main reason why I found these particular exams so challenging is the sheer breadth of information that they cover. Security is, after all, one of those topics that cuts across the entire field of computing. So the exam demands knowledge of Code Access Security in Windows forms applications, setting up ASP.NET and IIS security, encryption, SQL injection, declarative security for serviced components, and dozens of other topics. And with security being such an important topic these days, this sort of baseline knowledge really should be on everyone's plate.

Of course, there are a lot of other things that we expect new developers to know. If I hire someone to help with a C# coding project, I expect them to know the syntax of the language and the ins and outs of the Base Class Library. That's a given. I also expect some familiarity with source code management procedures, bug-tracking, issue management, and the other skills that surround the production of the code. Oh, and unit testing, of course.

And at least in my corner of the development world, it's not enough to just know C#. A good developer ought to be familiar with several languages, and know enough of the landscape to pick the right one for particular projects. After all, languages come and go, but development is forever (or at least it seems like it when you're mired in some doomed project).

You see where I'm leading with all this, I'm sure. In the sixty years or so since computer programming became a separate skill, we've added an incredible amount of complexity to the field. And at Microsoft and IBM and Apple and Sun and thousands of other companies, developers are beavering away to make it even more complex. In fact, I rather fear we've reached the point where it is just too complex. Trying to train new developers is difficult and frustrating, and trying to learn enough to be productive is tough.

Unfortunately, I don't have any answers to go with my vague worries. I may lose my membership in the Pundits' Union for saying so. But I suspect that in another decade or so, we'll be looking back on this towering superstructure of complexity and wondering how we could possibly have gone so far down the wrong path. With luck, I'll still be in the business to see what the easier way is.

About the Author

Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.