Handbasket, part 2

In the comments to a previous entry, Michael suggested that you might, in fact, get a better preparation to be a software engineer in lower tier schools because, summarizing and giving them the benefit of the doubt, their programs are more likely to focus on methods of development being widely used in the business world at the moment.

On the face of it, this might not seem particularly unreasonable. Currently, a large number of businesses use Microsoft's toolchain, from server-side components written in Visual Basic or Visual C-something (see previous article) to Internet Explorer and ActiveX controls on the client-side. It's reasonable that people more facile with the MS toolchain would be more employable, immediately, than people with the same expertise but in, say, the GNU toolchain, which is virtually unused in most sectors of the American economy.

(Definitions, in the spirit of the last article: a toolchain is a collection of theoretically related tools which, while they don't work with each other in any meaningful sense of the phrase, go out of their way not to work with anything from outside their little club. The GNU toolchain, in this case, refers to a collection of somewhat decent compilers produced by a raving lunatic and his followers. MS is a crippling nerve disease.)

Michael went on to comment on losing your job to Bangladesh within a year, but I think that "within a year" exposes a more significant problem with the style of teaching we're criticizing. I believe that one of the reasons the Microsoft tools are currently so popular is because they come with an enormous library of prebuilt components, functions, procedures, widgets, and so forth. For any given common business task, there is probably a widget somewhere in Microsoft's libraries to solve it; while it's not likely to be the best solution, and probably doesn't exactly fit your problem, it's not hard to add twenty lines of Visual Basic code around it to make it quite close enough, and this means that developing with Microsoft's tools can seem quite efficient.

Unfortunately, my experience suggests that the response to this is to teach computer science/software development/management information systems/whatever at a higher and higher level. Instead of talking about whatever logic underlies Microsoft's libraries, they cover a collection of the tools, standard ways to combine them, and then go on to discuss the waterfall model, and so on. Missing from this picture, though, is a reasonable way to adapt when Microsoft releases the next generation of its tools, about a year from now. Of course, Microsoft's core abstractions and principles don't change drastically from one evolution of their toolchain to the next, but if you don't know any of the core abstractions — if, in fact, you haven't been given the basic knowledge of computer science to understand the core abstractions — then it's not going to make any difference how little they changed because all you'll be able to understand is the surface.

At that point, the case for outsourcing starts to make a lot more sense. If you're going to have to retrain your programmers every two years anyway, why not outsource the whole setup to Bangladesh and save yourself a lot of trouble?

The answer, of course, is that it shouldn't be necessary to completely retrain your programmers every two years. But as long as a lot of universities are teaching a computer science/software development curriculum that goes no deeper than how to align a RadioButtonList with a CheckBoxList and read the Values property of either, Bangladesh looks better and better.