The One Trillion Dollar Development Pyramid

Kit George is the program manager for the .NET Base Class Library team. Kit recently posted an entry on the BCL blog describing a solution to a customer problem:

This is a companion discussion topic for the original blog entry at:

Interesting post as usual :slight_smile:

“Copying UNIX over and over is laudable enough”

Or indeed VMS.

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.

I’m glad you brought this up because I was thinking along these same lines later today.

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?.

I agree with this criticism. It’s one of the reasons we have the Delusions of Grandeur problem-- the masses of developers on the bottom are envious of the developers above them. “The best developers”, they say, “write code this way, so we should too!”

However, you’re absolutely right-- there is no actual connection between level of skill and “low-level development”. I should have emphasized this more, but certainly you have many, many extremely talented programmers working on .NET applications! It’s just that there is a wider range of skills at play on that level. The (few) businesses writing operating systems or multi-platform development environments (.NET, Java, etc) are culling the cream of the crop, and thus the average skill level is quite a bit higher on projects designed for audiences this large. It would be bad business to do anything less-- you don’t let intermediate or beginning developers write your framework, but it’s certainly OK to have hundreds of thousands of beginners and intermediates hacking on your framework. That’s what it’s for!

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 wasn’t implying that writing GenericBusinessApp is any less difficult than writing GenericOs. I’m merely providing evidence that the decisions you make when writing an application should NOT be driven by the decisions “smarter” programmers are making while building kernels, OSes, or frameworks. The regular expression scenario is an example of that mistake being made, with the best of intentions. If a BCL developer offered me advice on how to write my app, I’d certainly take that very seriously.

So yes, envy-- or maybe an inferiority complex-- is definitely a part of the problem. Make decisions that are correct for your problem domain, not for the problems so-called “smarter” programmers are solving.

The irony is that IIS7.0 (well, parts of it, anyway) is written in managed C# :slight_smile:

“you don’t need to experience the dark ages to live in the post-renaissance world”

But you SHOULD.

A little something called “perspective”. Applies to history and politics as well as to engineering.

“Jon Galloway has an insightful rebuttal of Joel Spolsky’s recommendation that every college graduate learn low-level C programming …”

I think the rebuttal misses the point of Joel’s post. IMHO, what Joel was saying was that programmers need to learn C in order to have insight , not to gain productivity. Even if you learn a framework in college, what are the chances you will use that framework at your next job when there are so many competing? I think if you learn C, you can take that insight anywhere.

“C gives you a toolset that can solve just about any problem, but requires that you solve each and every problem every time.”

I like that one. I’ve been writing things in C for years (almost “by religion”) and now, i opt for PERL everytime i can.

Re: you need to learn how to work with frameworks

I absolutely agree, but which one?

Looking at Java there seem to be several overlapping frameworks. And how about Ruby, Python, and .Net? I’d guess it would take several months to get started with one of these frameworks, and a few years to get expert at it.

I’d hate to waste all that effort on the wrong framework. It’s too bad things are so balkanized.

Also, has anybody done any evaluations of frameworks in terms of how long it takes to implement a sample project? (eg. do a port one of the standard content management (aka discussion management) systems)

Ben Slade
Chevy Chase, MD

I may be a bit of a dinosaur, but I code my desktop applications in C++ and I enjoy the challenges (and rewards) this brings. Some parts of these applications require the best possible execution speed and you can’t get it any other way. There is also a lot of open source code out there written in C and it pays to know how to use it.

I find it interesting though to compare the effort involved working in C++ with the work which I do on my code-behind web pages in C#. C# is a terrific language to work in. It’s nicely designed and very quick to get things done once you get off the blocks. Because exception handling is built in from the ground up, it’s actually useful (unlike in C++), and being relieved of the task of memory management is a big plus. In fact that is probably the major step forward that modern programming environments bring us. No more dangling pointers :slight_smile:

Being a dinosaur, I have not written a desktop application in C#. It would be interesting to know just how much time it can save you. C++ can be pretty productive if you know what you are doing.

Paul Sanders

Funny - I was nodding along with you at the beginning of the post, not knowing you were going to quote my post later on. Cracked me up when I hit the quote.

Thanks for completing the line of thinking. Wise of you not to directly criticize the C language, too - after I started getting the angry comments and e-mails, I started realizing that I’d annoyed folks who could hack my refrigerator (HVAC over TCP) if they wanted.

The language isn’t the point, it’s the level you’re working at.