The premise of the article is flawed. It grossly oversimplifies the relationship between expertise and specialization, and reasons ex post facto regarding the reasons for the distribution he perceives; most of th flaws are rooted in the false assumptions of the CultOfSystemsProgramming?.
First, it assumes that programming can be described as a singly rooted heirarchy with experts on top and non-experts on the bottom; it specifically presumes. Implicit in this is the assumptions that a) systems programming is the most difficult of all programming fields, and b) the only difference between a business applications programmer and a systems programmer is overall wizardry. Both of these are demonstrably false; while the field as a whole does share a broad common base of practices, there are a wide number of specializations in programming (as well as non-programming specializations that involve some programming as an adjunct, such as MIS and system administration). To master any one field takes both study and inclination, and there is no reason to believe a given programmer would be proficient in all of them just because he or she is a talented systems programmer. I have known many very talented systems programmers who have no comprehension of databases, and conversely, equally competent DBAs who could not design a web site or write a device driver. While some of the best programmers are generalists, most of the true experts are proficient in a relatively narrow field or handful of fields, and even the broadest polymath cannot master everything.
The article incorrectly concludes that, since commercial OS development is dominated by a handful of extremely competent programmers, systems programming must be the realm of the most rareified of wizards. This reverses cause and effect. The truth is, the niche for commercial operatin systems is very deep, but very narrow, and it is the natural inclination of the market to settle into a near monoculture based on the lowest common denominator. Thus, the field for professional systems programmers is small and highly competitive, with the majority of systems programmers being shunted off into fields which they are less adept at. This by no mens implies that those handful are the absolute best of all programmers, nor does it imply that their work is more difficult than that in fields where the demand for programmers and operators is very large (e.g., client-server integration). Indeed, the more advanced enterprise applications are probably more demanding than systems, not less; in the words of The /Tao of Programming/:
“When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design.”
I specifically emphasized the word ‘professional’ earlier because there is in fact a very wide and active, if not always terribly productive, community of hobbyist student system programmers, who write operating systems in vast profusion; these range from the ubiquitous Unix and MS-DOS clones, to various experimental systems which resemble nothing else ever seen. Also, in the field of embedded real-time systems, where compatibility is of minimal importance, there are a large number of competing commercial and open-source systems. Thus, it should be clear that systems programming, like the rest of the field, includes many individuals whose skill and experience covers the full range.