Cargo Cult Programming

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.

NEWS CONTENTS

• 20210703* Mission creep ( Jul 03, 2021 , en.wikipedia.org ) [Recommended]
• 20170505 : William Binney - The Government is Profiling You (The NSA is Spying on You) ( Apr 20, 2017 , www.youtube.com )
• 20070307 : Coding Horror Your Code OOP or POO by Jeff Atwood ( Coding Horror Your Code OOP or POO, Mar 7, 2007 )
• 20070307 : K. Scott Allen Cargo Cults ( K. Scott Allen Cargo Cults, )
• 20070307 : Fabulous Adventures In Coding Cargo Cultism, Part Four Other Disciplines ( Fabulous Adventures In Coding Cargo Cultism, Part Four Other Disciplines, )
• 20070307 : Fabulous Adventures In Coding Syntax, Semantics, Micronesian cults and Novice Programmers ( Fabulous Adventures In Coding Syntax, Semantics, Micronesian cults and Novice Programmers, )
• 20070307 : BufferOverrun Eric Lippert on Cargo Cult Programming ( BufferOverrun Eric Lippert on Cargo Cult Programming, )

Old News

[Jul 03, 2021] Mission creep

Highly recommended!

Jul 03, 2021 | en.wikipedia.org

Mission creep is the gradual or incremental expansion of an intervention, project or mission, beyond its original scope, focus or goals , a ratchet effect spawned by initial success. ^[1] Mission creep is usually considered undesirable due to how each success breeds more ambitious interventions until a final failure happens, stopping the intervention entirely.

The term was originally applied exclusively to military operations , but has recently been applied to many different fields. The phrase first appeared in 1993, in articles published in the Washington Post and in the New York Times concerning the United Nations peacekeeping mission during the Somali Civil War .

...

• Feature creep is an analogous phenomenon in software engineering .
• Ratchet effect is the inability of a system to reduce its scope once it expands.
• Scope creep is an analogous phenomenon in project management .

[May 05, 2017] William Binney - The Government is Profiling You (The NSA is Spying on You)

Very interesting discussion of how the project of mass surveillance of internet traffic started and what were the major challenges. that's probably where the idea of collecting "envelopes" and correlating them to create social network. Similar to what was done in civil War.

The idea to prevent corruption of medical establishment to prevent Medicare fraud is very interesting.

Notable quotes:

"... I suspect that it's hopelessly unlikely for honest people to complete the Police Academy; somewhere early on the good cops are weeded out and cannot complete training unless they compromise their integrity. ..."

"... 500 Years of History Shows that Mass Spying Is Always Aimed at Crushing Dissent It's Never to Protect Us From Bad Guys No matter which government conducts mass surveillance, they also do it to crush dissent, and then give a false rationale for why they're doing it. ..."

"... People are so worried about NSA don't be fooled that private companies are doing the same thing. ..."

"... In communism the people learned quick they were being watched. The reaction was not to go to protest. ..."

"... Just not be productive and work the system and not listen to their crap. this is all that was required to bring them down. watching people, arresting does not do shit for their cause ..."

Apr 20, 2017 | www.youtube.com

Chad 2 years ago

"People who believe in these rights very much are forced into compromising their integrity"

I suspect that it's hopelessly unlikely for honest people to complete the Police Academy; somewhere early on the good cops are weeded out and cannot complete training unless they compromise their integrity.

Agent76 1 year ago (edited)

January 9, 2014

500 Years of History Shows that Mass Spying Is Always Aimed at Crushing Dissent It's Never to Protect Us From Bad Guys No matter which government conducts mass surveillance, they also do it to crush dissent, and then give a false rationale for why they're doing it.

http://www.washingtonsblog.com/2014/01/government-spying-citizens-always-focuses-crushing-dissent-keeping-us-safe.html

Homa Monfared 7 months ago

I am wondering how much damage your spying did to the Foreign Countries, I am wondering how you changed regimes around the world, how many refugees you helped to create around the world.

Don Kantner, 2 weeks ago

People are so worried about NSA don't be fooled that private companies are doing the same thing. Plus, the truth is if the NSA wasn't watching any fool with a computer could potentially cause an worldwide economic crisis.

Bettor in Vegas 1 year ago

In communism the people learned quick they were being watched. The reaction was not to go to protest.

Just not be productive and work the system and not listen to their crap. this is all that was required to bring them down. watching people, arresting does not do shit for their cause......

[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
Next

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
Next
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:

• Don't be a cargo cultist -- understand the meaning and purpose of every line of code before you try to change it.
• Understand abstraction, and use it appropriately.

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: C++

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:

[DDInstall.Services]
AddService=<driver>_Service_Inst

[<driver>_Service_Inst]
StartType=0

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:

StartType=start-code Specifies when to start the driver as one of the following numerical values, expressed either in decimal or, as shown here, in hexadecimal notation. 0x0 (SERVICE_BOOT_START) Indicates a driver started by the operating system loader. This value must be used for drivers of devices required for loading the operating system. 0x1 (SERVICE_SYSTEM_START) 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. 0x2 (SERVICE_AUTO_START) 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. 0x3 (SERVICE_DEMAND_START) 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. 0x4 (SERVICE_DISABLED) 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 Recommended

Top articles

[Jul 03, 2021] Mission creep Published on Jul 03, 2021 | en.wikipedia.org

Sites

• Wikipedia cargo cult programming
• Voodoo science - Wikipedia, the free encyclopedia
• Magical thinking - Wikipedia, the free encyclopedia
• Pathological science - Wikipedia, the free encyclopedia
• Surely You're Joking, Mr. Feynman!, Richard Feynman, W. W. Norton & Co, New York, 1985, ISBN 0-393-01921-7. One of the chapters is the transcript of a 1974 CalTech commencement address, which contained the coining of "Cargo cult science".
• Cargo Cult Science (pdf) by Richard P. Feynman. Article based on his 1974 CalTech Commencement address, with pictures, as originally published in Engineering and Science, Volume 37:7, June 1974. Digitized version from CalTech Library, retrieved June 20, 2007
• IEEE Software From the Editor Column by Steve McConnell
• Fabulous Adventures In Coding Syntax, Semantics, Micronesian cults and Novice Programmers

Etc

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. 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.

Last modified: July 03, 2021