Originally Posted By: tsuwm
I don't think you can discount..
5. (or 4a) Those that actually *implement the OS are mostly simple folk like you and I, who can't possibly grasp the "big picture", whatever that may be.

-joe (simple) friday


I agree, but I subsume that under 4, complexity. There was a time in the history of programming when the idea of writing programs on the order of a million lines was considered to be extremely high risk - probably even impossible for some companies to undertake. I can imagine that the builders of the first pyramids felt the same hesitation. The history of software engineering is in large part the history of trying to manage complexity - assembler language, high level, general purpose languages, top-down design, structured programming, extreme programming, object-oriented programming, specification writing, design reviews, etc. They all fit specific needs, but one of the over-arching goals is to be able to get a handle on complexity.

Decades ago, the manager types used to consider programmers like any other kind of human resource. Pretty much we are all inter-changeable. To my chagrin, I've met senior management who STILL think this way. But programming has proven itself a unique human activity when examined by industrial engineers.

I can't recall my source or even the exact numbers here, but what I'm about to relate is approximate information: If you take the people who do any job and bin them by performance into quartiles, you discover that in every field the top quartile do about 1.8 times as much work as the bottom. Now you might think that the guys who are going slower do better work, but that's not the case. The faster guys generally are doing better than the slower guys. This figure of 1.8 to 2.0 holds true for a large array of human tasks - with one notable exception, programming. The top quartile of programmers produces about 5 to 10 times as much code as the bottom quartile. It almost always contains fewer errors, is more efficient, and is better engineered than that produced by the bottom quartile. If you break it down finer than quartiles, the effect of comparing the top to bottom is even more startling.

Here's the consequence: in a large s/w project, not everybody working on the team is going to be in the top 1%. Even at the best place you're going to have some of them who are at or below the median; that is, some of the people on a really big project are going to be less than average. But that's okay. That's one of the reasons we have software engineering practices - so we're not 'completely' limited by what the smartest guy can do. We can do pretty amazing things, by having the really, really smart guys do the main design, and maybe some of the initial coding. THEN the other guys who are pretty good, and maybe brilliant, but not quite so brilliant as the others come in and fill things out. But this is much easier to say than it is to do. Sometimes it's like a grandmaster explaining his philosophy to someone who is just, say, a mere expert or a class A or B player. It's not that the mere expert it dumb or incompetent, but getting that vision correctly can be a serious challenge. Not everyone is going to be a grandmaster - no matter how much they study.

An exacerbating factor is that managing projects - and PARTICULARLY managing large projects requires completely different skills from programming. Nevertheless, having a manager who understands the subject area is critical - otherwise, we're back to using questionable heuristics like "programmers are interchangeable."

So to go back to your point which if you are not being sarcastic I answer again, "Yes, I agree."