News
Wanted: A brain the size of a planet
- By Mike Gunderloy
- April 30, 2004
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.