May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Cargo Cult Programming

News Cargo Cult Science Recommended books Recommended Links CMM (Capability Maturity Model) Lysenkoism and politization of science Groupthink
Bootlickocracy:  Nicholas Carr's "IT Does not Matter" Fallacy  Skeptical view on the OO  CMM (Capability Maturity Model) Agile Crap Slightly Skeptical View on Extreme Programming IT offshoring Skeptic
Real Insights into Architecture Come Only From Actual Programming Brooks law Pseudoscience and Scientific Press Scientific Fraud Quotes Humor Etc

Richard Feynmann suggested, in his "Cargo Cult Science" speech, that scientists may form cult similar to a certain Micronesian cults. The term cargo cult is a reference to aboriginal religions that grew up in the South Pacific, especially New Guinea and Micronesian islanders, in the years during and after World War II. There was no one Cargo Cult so this proper name is a misnomer - no one who participated in a cargo cult actually knew that they were doing so.

The vast amounts of war materials that were air-dropped into these islands during the Pacific campaign against the Empire of Japan necessarily meant drastic changes to the lifestyle of these islanders as manufactured clothing, canned food, tents, weapons and other useful goods arrived in vast quantities to equip soldiers - and also the islanders who were their guides and hosts. When the war moved on, and ultimately when it ended, the airbases were abandoned and no new "cargo" was then being dropped. In attempts to get cargo to fall by parachute or land in planes or ships again, islanders tried to imitate practices they had seen the soldiers, sailors and airmen use. They carved headphones from wood, and wore them while sitting in control towers. They waved the landing signals while standing on the runways. They lit signal fires and torches to light up runways and lighthouses. Some built life-size mockups of airplanes out of straw, and created new military style landing strips, hoping to attract more airplanes.

Anthropologist Marvin Harris has linked the social mechanisms that produce cargo cults to those of Messianism. In his  Caltech commencement speech, which became a chapter in the book "Surely you're joking, Mr. Feynman!" Feynman pointed out that cargo cultists create all the appearance of an airport--right down to headsets with bamboo "antennas" -- yet the airplanes don't come. Feynman argued that scientists often produce studies with all the trappings of real science, but which are nonetheless pseudoscience and unworthy of either respect or support. A very similar term voodoo science was coined by professor and scientific skeptic Robert L. Park.   who outlined several warning signs (close to pathological science, as discussed by physicist Irving Langmuir in 1953).

There is great analogy between cargo cults techniques and Soft propaganda. Among common techniques  which would be relevant to programming I would mention the following:

  1. Making claims about superiority of OS or programming language directly to the popular media, rather than to professional press and conferences (pure propaganda).
  2. Making claims that a conspiracy has tried to suppress their favorite operating system of programming language.
  3. Anecdotal evidence is used to back up the claim.
  4. True believers mentality in support of the their claim.
  5. Abuse of jargon and re-implementing older technologies under the new fancy names. Attempts to reinvent the bicycle under the new fancy name and putting a smoke screen on any apparent analogies or prior implementations.
  6. Working in self-selected isolation from the other communities.
  7. Claims about "purity" of approach which implies the "impurity" of alternatives.  For example, created using  "pure agile software development methodology" 
  8. 'Black and White fallacy' aims at presenting only two choices to the public. Either you with us or with enemies mentality. 'Unstated assumption' that any other choice is bad and represents betrayal is used although it is not stated explicitly. But it is obviously implied.
  9. Name-calling also called stereotyping or labeling. Name-calling is a direct attack on an opponent. If it is likely to annoy the audience, indirect name-calling is used. In this case, sarcasm is employed. That is related to standard technique of demonizing the enemy during the war, make the people with an opposing standpoint, appear inferior. The use of the term 'gooks' for NLF soldiers during the Vietnam War-era is an example of this type of propaganda. Obtaining disapproval is another technique of obtaining disfavor of an idea by signifying that the opposite idea/approach is of the 'hated lot' .

Cargo cult science can be viewed as a special case of scientific misconduct which includes but is not limited to fabrication, falsification, and plagiarism as well as intentional theft of, or damage to, research equipment or experiments. Cargo cult programming is a perversion of programming very similar to cargo cult science. Here is how it is defined by Eric Lippert who popularized the term:

During the Second World War, the Americans set up airstrips on various tiny islands in the Pacific.  After the war was over and the Americans went home, the natives did a perfectly sensible thing -- they dressed themselves up as ground traffic controllers and waved those sticks around.  They mistook cause and effect -- they assumed that the guys waving the sticks were the ones making the planes full of supplies appear, and that if only they could get it right, they could pull the same trick.  From our perspective, we know that it's the other way around -- the guys with the sticks are there because the planes need them to land.  No planes, no guys.  

The cargo cultists had the unimportant surface elements right, but did not see enough of the whole picture to succeed. They understood the form but not the content.  There are lots of cargo cult programmers -- programmers who understand what the code does, but not how it does it.  Therefore, they cannot make meaningful changes to the program.  They tend to proceed by making random changes, testing, and changing again until they manage to come up with something that works.  

We can distinguish between several common forms of cargo cult programming:

  1. The most common form of cargo cult programming characterized by the extreme adherence to the form instead of content ( CMM and to lesser extent  extreme programming  are good examples). 
  2. Another form is closely connected with outsourcing and related communication problems. This variant of cargo cult programming often includes absurd  "to the word" following of the specification even if it contains blunders and/or was completely detached from reality.
  3. The ritual usage of fashionable technologies like OO ten years ago are a third popular form and actually is the mildest cases of the same (is not OO good in all case ? ;-).
  4. Rare and extreme cases include debugging without understanding underling language that was described by Weinberg.

Steve McConnell applied the term to software engineering in a very narrow sense in his article of the subject is IEEE Software From the Editor Column (I doubt that he in his capability of Editor-in-chief of IEEE Software could attach CMM model ;-). He correctly noted that the key distinction is clueless imitation of a particular activity (project management philosophy in his very narrow example):

When used knowledgeably, either development style can produce high quality software economically and quickly. But both development styles have pathological lookalikes that don’t work nearly as well, and that can be difficult to distinguish from the genuine articles.

The process-imposter organization bases its practices on a slavish devotion to process for process’s sake. These organizations look at process-oriented organizations such as NASA’s Software Engineering Laboratory and IBM’s former Federal Systems Division. They observe that those organizations generate lots of documents and hold frequent meetings. They conclude that if they generate an equivalent number of documents and hold a comparable number of meetings they will be similarly successful. If they generate more documentation and hold more meetings, they will be even more successful! But they don’t understand that the documentation and the meetings are not responsible for the success; they are the side effects of a few specific effective processes. We call these organizations bureaucratic because they put the form of software processes above the substance. Their misuse of process is demotivating, which hurts productivity. And they’re not very enjoyable to work for.

The commitment-imposter organization focuses primarily on motivating people to work long hours. These organizations look at successful companies like Microsoft; observe that they generate very little documentation; offer stock options to their employees; and then require them to work mountains of overtime. They conclude that if they, too, minimize documentation, offer stock options, and require extensive overtime, they will be successful. The less documentation and the more overtime, the better! But these organizations miss the fact that Microsoft and other successful commitment-oriented companies don’t require overtime. They hire people who love to create software. They team these people with other people who love to create software just as much as they do. They provide lavish organizational support and rewards for creating software. And then they turn them loose. The natural outcome is that software developers and managers choose to work long hours voluntarily. Imposter organizations confuse the effect (long hours) with the cause (high motivation). We call the imposter organizations sweatshops because they emphasize working hard rather than working smart, and they tend to be chaotic and ineffective. They’re not very enjoyable to work for either.

Cargo cult software engineering is easy to identify. Cargo cult software engineers justify their practices by saying, "We’ve always done it this way in the past," or "our company standards require us to do it this way"—even when those ways make no sense. They refuse to acknowledge the tradeoffs involved in either process-oriented or commitment-oriented development. Both have strengths and weaknesses. When presented with more effective, new practices, cargo cult software engineers prefer to stay in their wooden huts of familiar, comfortable and-not-necessarily-effective work habits. "Doing the same thing again and again and expecting different results is a sign of insanity," the old saying goes. It’s also a sign of cargo cult software engineering.

...In this magazine and in many other publications, we spend our time debating whether process is good or individual empowerment (in other words, commitment-oriented development) might be better. This is a false dichotomy. Process is good, and so is individual empowerment. The two can exist side by side. Process-oriented organizations can ask for an extreme commitment on specific projects. Commitment-oriented organizations can use software engineering practices skillfully.

The difference between these two approaches really comes down to differences of style and personality. I have worked on several projects of each style, and have liked different things about each style. Some developers enjoy working methodically on an 8 to 5 schedule, which is more common in process-oriented companies. Other developers enjoy the focus and excitement that comes with making a 24x7 commitment to a project. Commitment-oriented projects are more exciting on average, but a process-oriented project can be just as exciting when it has a well defined and inspiring mission. Process-oriented organizations seem to degenerate into their pathological lookalikes less often than commitment-oriented organizations do, but either style can work well if it is skillfully planned and executed.

The fact that both process-oriented and commitment-oriented projects have pathological lookalikes has muddied the debate. Some projects conducted in each style succeed, and some fail. That allows a process advocate to point to the process success and commitment failures and claim that process is the key to success. It allows the commitment advocate to do the same thing.

Imitating form without understanding content can often be found among outsourcers. In this specific circumstances it is often called voodoo programming, or "stepping of the same rake again and again" 

The concept of "cargo cult programming" is especially applicable to software maintenance. As Eric Lippert  aptly noted in his blog post Syntax, Semantics, Micronesian cults and Novice Programmers:

There are lots of cargo cult programmers -- programmers who understand what the code does, but not how it does it. Therefore, they cannot make meaningful changes to the program. They tend to proceed by making random changes, testing, and changing again until they manage to come up with something that works.

Probably the most popular form of cargo cult programming is CMM (Capability Maturity Model)

It is certainly not limited to the software engineering.  In fact, this is just a very subject-specific case of Lysenkoism.

Cargo cult programming can also refer to the results of (over-)applying a design principle blindly without understanding the reasons behind that design principle in the first place. An example would be a novice being taught that commenting code is good, and then adding comments for lines that are self-explanatory or need no comment; other examples involve overly complex use of design patterns or certain forms of coding style.

A related term in software engineering is cargo cult software engineering, coined by Steve McConnell.

McConnell describes software development organizations that attempt to emulate more successful development houses, either by slavishly following a software development process, or by taking a commitment oriented development approach.

In both cases, McConnell contends that competence ultimately determines whether a project succeeds or fails, regardless of the development approach taken; furthermore, he claims that incompetent "impostor organizations", that merely emulate the form of successful software development organizations are, in fact, engaging, in what he calls Cargo cult software engineering.


Old News

[Dec 26, 2016] Does Code Reuse Endanger Secure Software Development?

Dec 26, 2016 |
( 148 Posted by EditorDavid on Saturday December 17, 2016 @07:34PM from the does-code-reuse-endanger-secure-software-development dept. msm1267 quotes ThreatPost: The amount of insecure software tied to reused third-party libraries and lingering in applications long after patches have been deployed is staggering. It's a habitual problem perpetuated by developers failing to vet third-party code for vulnerabilities, and some repositories taking a hands-off approach with the code they host. This scenario allows attackers to target one overlooked component flaw used in millions of applications instead of focusing on a single application security vulnerability.

The real-world consequences have been demonstrated in the past few years with the Heartbleed vulnerability in OpenSSL , Shellshock in GNU Bash , and a deserialization vulnerability exploited in a recent high-profile attack against the San Francisco Municipal Transportation Agency . These are three instances where developers reuse libraries and frameworks that contain unpatched flaws in production applications... According to security experts, the problem is two-fold. On one hand, developers use reliable code that at a later date is found to have a vulnerability. Second, insecure code is used by a developer who doesn't exercise due diligence on the software libraries used in their project.
That seems like a one-sided take, so I'm curious what Slashdot readers think. Does code reuse endanger secure software development?

[Dec 26, 2016] Ask Slashdot: Has Your Team Ever Succumbed To Hype Driven Development?

Dec 26, 2016 |
( 332 Posted by EditorDavid on Sunday November 27, 2016 @11:30PM from the TDD-vs-HDD dept. marekkirejczyk , the VP of Engineering at development shop Daftcode, shares a warning about hype-driven development: Someone reads a blog post, it's trending on Twitter, and we just came back from a conference where there was a great talk about it. Soon after, the team starts using this new shiny technology (or software architecture design paradigm), but instead of going faster (as promised) and building a better product, they get into trouble . They slow down, get demotivated, have problems delivering the next working version to production.
Describing behind-schedule teams that "just need a few more days to sort it all out," he blames all the hype surrounding React.js, microservices, NoSQL, and that " Test-Driven Development Is Dead " blog post by Ruby on Rails creator David Heinemeier Hansson. ("The list goes on and on... The root of all evil seems to be social media.")

Does all this sound familiar to any Slashdot readers? Has your team ever succumbed to hype-driven development?

[Mar 7, 2007] Coding Horror Your Code OOP or POO by Jeff Atwood

I'm not a fan of object orientation for the sake of object orientation. Often the proper OO way of doing things ends up being a productivity tax. Sure, objects are the backbone of any modern programming language, but sometimes I can't help feeling that slavish adherence to objects is making my life a lot more difficult. I've always found inheritance hierarchies to be brittle and unstable, and then there's the massive object-relational divide to contend with. OO seems to bring at least as many problems to the table as it solves.

Perhaps Paul Graham summarized it best:

Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.

Eric Lippert observed a similar occupational hazard among developers. It's something he calls object happiness.

What I sometimes see when I interview people and review code is symptoms of a disease I call Object Happiness. Object Happy people feel the need to apply principles of OO design to small, trivial, throwaway projects. They invest lots of unnecessary time making pure virtual abstract base classes -- writing programs where IFoos talk to IBars but there is only one implementation of each interface! I suspect that early exposure to OO design principles divorced from any practical context that motivates those principles leads to object happiness. People come away as OO True Believers rather than OO pragmatists.

I've seen so many problems caused by excessive, slavish adherence to OOP in production applications. Not that object oriented programming is inherently bad, mind you, but a little OOP goes a very long way. Adding objects to your code is like adding salt to a dish: use a little, and it's a savory seasoning; add too much and it utterly ruins the meal. Sometimes it's better to err on the side of simplicity, and I tend to favor the approach that results in less code, not more.

Given my ambivalence about all things OO, I was amused when Jon Galloway forwarded me a link to Patrick Smacchia's web page. Patrick is a French software developer. Evidently the acronym for object oriented programming is spelled a little differently in French than it is in English: POO.

K. Scott Allen Cargo Cults

# re: Cargo Cults "Cargo Cult" also applies to certain executives at dot com boom era software startups.

On arrival, jubilant about their new VP positions at hapless startups, many execs tended to simply reimplement what had been done at their previous company ("hey, it worked from '96 to '99.")

"I'm gonna build us a sales pipeline and a sales forecast. Then we'll cross the chasm."

"Once we send this product to a focus group, we'll know exactly what to change."

"Engineers aren't working long enough hours. At XYZ we pulled 80 hour weeks and shipped on time. Show these guys a sense of urgency."

"Once we write our mission statement we'll all be on the same page and move forward together."

"We need an offsite meeting at a fancy hotel so we can brainstorm, bond with each other, and innovate."

Then the boom ended, but they kept doing the same things religiously. (Until they got fired.)

Maybe "cargo cult executives" never really went away.

Fabulous Adventures In Coding Cargo Cultism, Part Four Other Disciplines

Cargo Cultism, Part Four: Other Disciplines > Just a couple quick follow-ups.

Mike Spille has some good comments tying the relationship between cargo cult programmers and abstraction layers together.

Mike Gunderloy wonders if I've ever read Steve “Code Complete“ McConnell's Cargo Cult Software Engineering essay. I have now -- thanks! However, this essay is about cargo cultism amongst managers of software teams, not the developers themselves.

What this really shows is that imitating form without understanding content is a methodology in many disciplines. It is certainly not limited to the engineering professions! In fact, this problem in a completely unrelated discipline has been on my mind lately.

As Professor Thingo mentions in his recent blog entries, in addition to knowing a thing or two about scripting languages, I'm also an expert on the life and work of JRR Tolkien. I have the dubious distinction of being the first person to put a Tolkien fan page up on the Internet. For many years that page was the first result returned by Google searches for "Tolkien", which got me a lot of email from kids doing book reports and a number of unintentionally hilarious interviews with newspapers when the first Peter Jackson movie was released. The admins of the university server upon which the page resided finally noticed that I'd graduated eight years earlier and removed it some time last year; it had not been updated since 1997 and was a mass of dead links.

But I digress. I think that it is safe to say that the vast majority of fantasy genre fiction produced in the last fifty years apes the form of The Lord of the Rings without coming close to the quality of the content. Want to sell books? Put a map in the back, have a few plucky short guys with swords go up against evil incarnate to save the world, and wait for the royalties to roll in. (See Tom Shippey“s excellent book Author of the Century for an in-depth analysis of this fact.)

Peter Jackson, in one of his Oscar acceptance speeches thanked the Academy for looking beyond the form -- the elves and wizards and hobbits -- to the underlying moral thematic core of the work. And you have to look beyond it; most genre fantasy is derivative dreck, not to put too fine a point on it, and that prejudices people against it. (A notable exception would be the early work of Guy Kay, who was Christopher Tolkien's assistant when he was editing The Silmarillion. I haven't read any of Kay's recent work, so I don't know if it is still of such high quality.)

Cargo cultism is everywhere.

Fabulous Adventures In Coding Syntax, Semantics, Micronesian cults and Novice Programmers

I've had this idea in me for a long time now that I've been struggling with getting out into the blog space. It has to do with the future of programming, declarative languages, Microsoft's language and tools strategy, pedagogic factors for novice and experienced programmers, and a bunch of other stuff. All these things are interrelated in some fairly complex ways. I've come to the realization that I simply do not have time to organize these thoughts into one enormous essay that all hangs together and makes sense. I'm going to do what blogs do best -- write a bunch of (comparatively!) short articles each exploring one aspect of this idea. If I'm redundant and prolix, so be it.

Today I want to blog a bit about novice programmers. In future essays, I'll try to tie that into some ideas about the future of pedagogic languages and languages in general.

Novice programmers reading this: I'd appreciate your feedback on whether this makes sense or it's a bunch of useless theoretical posturing.

Experienced programmers reading this: I'd appreciate your feedback on what you think are the vital concepts that you had to grasp when you were learning to program, and what you stress when you mentor new programmers.

An intern at another company wrote me recently to say "I am working on a project for an internship that has lead me to some scripting in vbscript. Basically I don't know what I am doing and I was hoping you could help." The writer then included a chunk of script and a feature request. I've gotten requests like this many times over the years; there are a lot of novice programmers who use script, for the obvious reason that we designed it to be appealing to novices.

Well, as I wrote last Thursday, there are times when you want to teach an intern to fish, and times when you want to give them a fish. I could give you the line of code that implements the feature you want. And then I could become the feature request server for every intern who doesn't know what they're doing… nope. Not going to happen. Sorry. Down that road lies cargo cult programming, and believe me, you want to avoid that road.

What's cargo cult programming? Let me digress for a moment. The idea comes from a true story, which I will briefly summarize:

During the Second World War, the Americans set up airstrips on various tiny islands in the Pacific. After the war was over and the Americans went home, the natives did a perfectly sensible thing -- they dressed themselves up as ground traffic controllers and waved those sticks around. They mistook cause and effect -- they assumed that the guys waving the sticks were the ones making the planes full of supplies appear, and that if only they could get it right, they could pull the same trick. From our perspective, we know that it's the other way around -- the guys with the sticks are there because the planes need them to land. No planes, no guys.

The cargo cultists had the unimportant surface elements right, but did not see enough of the whole picture to succeed. They understood the form but not the content. There are lots of cargo cult programmers -- programmers who understand what the code does, but not how it does it. Therefore, they cannot make meaningful changes to the program. They tend to proceed by making random changes, testing, and changing again until they manage to come up with something that works.

(Incidentally, Richard Feynman wrote a great essay on cargo cult science. Do a web search, you'll find it.)

Beginner programmers: do not go there! Programming courses for beginners often concentrate heavily on getting the syntax right. By "syntax" I mean the actual letters and numbers that make up the program, as opposed to "semantics", which is the meaning of the program. As an analogy, "syntax" is the set of grammar and spelling rules of English, "semantics" is what the sentences mean. Now, obviously, you have to learn the syntax of the language -- unsyntactic programs simply do not run. But what they don't stress in these courses is that the syntax is the easy part. The cargo cultists had the syntax -- the formal outward appearance -- of an airstrip down cold, but they sure got the semantics wrong.

To make some more analogies, it's like playing chess. Anyone can learn how the pieces legally move. Playing a game where the strategy makes sense is the hard (and interesting) part. You need to have a very clear idea of the semantics of the problem you're trying to solve, then carefully implement those semantics.

Every VBScript statement has a meaning. Understand what the meaning is. Passing the right arguments in the right order will come with practice, but getting the meaning right requires thought. You will eventually find that some programming languages have nice syntax and some have irritating syntax, but that it is largely irrelevant. It doesn't matter whether I'm writing a program in VBScript, C, Modula3 or Algol68 -- all these languages have different syntaxes, but very similar semantics. The semantics are the program.

You also need to understand and use abstraction. High-level languages like VBScript already give you a huge amount of abstraction away from the underlying hardware and make it easy to do even more abstract things.

Beginner programmers often do not understand what abstraction is. Here's a silly example. Suppose you needed for some reason to compute 1 + 2 + 3 + .. + n for some integer n. You could write a program like this:

n = InputBox("Enter an integer")

Sum = 0
For i = 1 To n
Sum = Sum + i

MsgBox Sum

Now suppose you wanted to do this calculation many times. You could replicate the middle four lines over and over again in your program, or you could abstract the lines into a named routine:

Function Sum(n)
Sum = 0
For i = 1 To n
Sum = Sum + i
End Function

n = InputBox("Enter an integer")
MsgBox Sum(n)

That is convenient -- you can write up routines that make your code look cleaner because you have less duplication. But convenience is not the real power of abstraction. The power of abstraction is that the implementation is now irrelevant to the caller. One day you realize that your sum function is inefficient, and you can use Gauss's formula instead. You throw away your old implementation and replace it with the much faster:

Function Sum(n)
Sum = n * (n + 1) / 2
End Function

The code which calls the function doesn't need to be changed. If you had not abstracted this operation away, you'd have to change all the places in your code that used the old algorithm.

A study of the history of programming languages reveals that we've been moving steadily towards languages which support more and more powerful abstractions. Machine language abstracts the electrical signals in the machine, allowing you to program with numbers. Assembly language abstracts the numbers into instructions. C abstracts the instructions into higher concepts like variables, functions and loops. C++ abstracts even farther by allowing variables to refer to classes which contain both data and functions that act on the data. XAML abstracts away the notion of a class by providing a declarative syntax for object relationships.

To sum up, Eric's advice for novice programmers is:

BufferOverrun Eric Lippert on Cargo Cult Programming

This blog posting from Eric Lippert has a ton of good advice for new programmers. It's not specific to C++, but the principles all apply:
Syntax, Semantics, Micronesian cults and Novice Programmers
There are lots of cargo cult programmers -- programmers who understand what the code does, but not how it does it. Therefore, they cannot make meaningful changes to the program. They tend to proceed by making random changes, testing, and changing again until they manage to come up with something that works.
Bottom line... understand the meaning and purpose of every line of code before you try to change it.
Filed under:

Larry Osterman's WebLog Critical Driver or Cargo Cult Programming

I've been self hosting Vista on my laptop since sometime in January. Every Monday morning, without fail, I installed the latest build available from the "main" windows branch, and tried it.

There have been good builds and bad builds - the first few were pretty painful, everything since sometime in March has been wonderfully smooth.

But sometime late in May, things changed for the worse. Weekly builds installed just fine on my main development machine, but my laptop would get about 3/4ths of the way through the install and stop after a reboot complaining about a problem with the critical system driver <driver>.sys.

Of course, I filed a bug on the problem and moved on - every week I'd update my laptop and it'd fail. While I was away on vacation, the guys looking into the bug finally figured out what was happening.

The first part of the problem was easy - something was causing <driver>.sys to fail to load (we don't know what). But that didn't explain the unbootable system.

Well, the <driver>.sys driver is the modem driver for my laptop. Eventually one of the setup devs figured the root cause. For some totally unknown reason, their inf has the following lines:



If you go to msdn and look up DDInstall.Services, you get this page.

If you follow the documentation a bit you find the documentation for the service install section which describes the StartType key - it's the same as the start type for Windows services.

In particular, you find:

Specifies when to start the driver as one of the following numerical values, expressed either in decimal or, as shown here, in hexadecimal notation.
Indicates a driver started by the operating system loader.

This value must be used for drivers of devices required for loading the operating system.

Indicates a driver started during operating system initialization.

This value should be used by PnP drivers that do device detection during initialization but are not required to load the system.

For example, a PnP driver that also can detect a legacy device should specify this value in its INF so that its DriverEntry routine will be called to find the legacy device, even if that device cannot be enumerated by the PnP manager.

Indicates a driver started by the service control manager during system startup.

This value should never be used in the INF files for WDM or PnP device drivers.

Indicates a driver started on demand, either by the PnP manager when the corresponding device is enumerated or possibly by the service control manager in response to an explicit user demand for a non-PnP device.

This value should be used in the INF files for all WDM drivers of devices that are not required to load the system and for all PnP device drivers that are neither required to load the system nor engaged in device detection.

Indicates a driver that cannot be started.

This value can be used to temporarily disable the driver services for a device, but a device/driver cannot be installed if this value is specified in the service-install section of its INF file.

So in this case, the authors of the modem driver decided that their driver was a boot time critical driver - which, as the documentation clearly states is only intended for drivers required to load the operating system.

So I'll leave it up to you to decide - is this an example of cargo cult programming, or did the authors of this modem driver REALLY think that the driver is a critical system driver?

What makes things worse is that this is a 3rd party driver - we believe that their INF is in error, but we can't fix it because it's owned by the 3rd party. Our only choice is to baddriver it and prevent Vista from loading that particular driver. The modem chip in question hasn't been made for many, many years, the vendor for that chip has absolutely no interest in supporting it on Vista, so we can't get it fixed (the laptop is old enough that it's out of OEM support, so there's no joy from that corner either - nobody wants to support this hardware anymore).

Please note: This is NOT an invitation for a "If only the drivers were open source, then you could just fix it" discussion in the comments thread. The vendor for the modem driver owns the rights to their driver, they get to choose whether or not they want to support it, not Microsoft.

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: December 27, 2016