|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
Richard Feynman suggested, in his famous "Cargo Cult Science" speech, that scientists and specialists often perform meaningless ritualistic actions similar to a certain Micronesian cults. A similar concept in Unix system administration and networking is "to wave a dead chicken".
But the key word here which supplies the concept with much richer meaning is the word "cult".
First some history. 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 materiel 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). Among those which would be relevant to programming I would mention the following:
Negative selection is a process that occurs in rigid, authoritarian hierarchies including scientific clans.
The person on the top of the hierarchy, wishing to remain in power forever, chooses his associates with the prime criterion of incompetence - they must not be competent enough to remove him from power. The associates do the same with those below them in the hierarchy, and the hierarchy is progressively filled with more and more incompetent people.
If the dictator sees that he is threatened nonetheless, he will remove those that threaten him from their positions - "purge" the hierarchy. Emptied positions in the hierarchy are normally filled with people from below - those who were less competent than their previous masters. So, over the course of time, the hierarchy becomes less and less effective.
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 with the meaning of loss of understanding of architecture of the program:
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:
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 attack CMM model ;-). He correctly noted that the key distinction is a 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.
In a broader sense as the process of performing meaningless actions in a hope to attract positive results the classic example 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 obscure forms of coding style and naming conventions.
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.
Dr. Nikolai Bezroukov
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
October 2008.
This page outlines the differences between good conferences, bad conferences and academic scams.
The purpose of conferences
Why would anyone organise a conference?
- To promote the exchange of ideas in a particular area
- To promote networking by researchers
- To generate funds for a non-profit organisation
- To focus attention on a particular area
- To promote the organisers' reputations
- To make a profit for the organisers
Why attend a conference?
- To learn about the area
- To interact with other researchers
- To add a publication to your CV
- To have a holiday somewhere nice
Most of the motivations above are generally altruistic, but the last two in each list are not. Promoting the organisers' reputations and adding to your CV are not necessarily bad; this is how academia works. However, these four motivations result in a lot of low-quality work being published.
Quality
If your motivation for attending a confernce is to have a holiday or to add (uncritically) to your CV the quality of the conference won't matter much. In contrast, if you attend for the other reasons quality is a major concern. Imagine attending a conference and not making any useful contacts or coming across any good ideas: you would not have not gained much!You might still consider this conference worthwhile because you got a publication out of it. After all, having publications may help impress your supervisor or thesis examiners or potential employers. Publications will also help your career as a scientist: you will be more likely to get funding, to be promoted, to attract students, to be invited to give talks and so on. However, quality is vital and there is a huge range in the quality of conferences and journals. These days it's possible to get anything published. In fact, in the famous SCIgen affair a computer-generated nonsense paper was accepted by a conference. As a result, publications in themselves mean little; what matters is their quality. In fact, if you publish in low-quality conferences, or, worse, junk conferences, you will find this hurts your reputation more that it helps.
Spam and junk conferences
A spam conference (or spamference) is one which is advertised with junk mail (spam). It is genuinely difficult to reach a large number of researchers in a particular area to advertise a conference, and some organisers of legitimate conferences are tempted into using junk mail. These conferences tend, however, to be lower quality ones, or new (or one-off) events which need to boost their attendence in this way. Well-established, high-quality conferences are well-known in their area and don't need to resort to junk mail. These are the conferences which count most on your CV.The conferences which send the most junk mail tend to be junk conferences, which have little or no academic value and are only run to make a profit for the oraganisers. Some researchers participate to get a free holiday and a publication but others participate in good faith, not realising the nature of the event. The point of this page is to ensure that you are not one of hem.
Where the money goes
Most conferences charge a fee for attendance which is put toward the cost of running the event. Some events also raise money for a non-profit organisation with which they are affiliated. The Association for the Advancement of Artificial Intelligence is an example of such an organisation, and it is a legitimate one, although I don't know whether fees from their conferences contribute to the association.Some conferences, especially larger ones, subcontract some of the non-academic organisational work. Many conferences, however, are organised entirely by volunteers, although there may be concessions to the main organisers such as free registration. Invited speakers generally get free registration, a contribution toward travel costs, and possibly an honorarium (a small payment). The details of these arrangements are not usually publicised and there is the potential for dubious use of funds, but as each incarnation of a particular conference series is generally organised by different people each year it is difficult for misuse of funds to persist.
Although I see no reason why for-profit conferences cannot be of good quality there are a number of junk conferences which are run solely for profit, and where the quality of work is given little or no consideration.
Warning signs
Here are some warning signs but note that bona fide conferences may show some of these warning signs; in particular many reputable conferences are held in nice places.
- The conference is advertised using spam
- The conference has the same chair every year. (Bona fide conferences may have the same people on an executive committee for many years, but probably not the same chair.)
- The call for papers emphasises repeatedly that it is a "reputable" conference with many "famous experts"
- The call for papers, and subject of the conference, is very general
- The chair has chaired dozens of other conferences but probably has few good publications and does not work at a reputable institution
- The conference is in a very nice place
- You are invited by a stranger to organise a special session, or to undertake some other activity for the conference which would normally require some stature in the area, when you in fact do not have this stature. For example if you are a PhD student it's unlikely you will be asked by a stranger to take a high-profile role. Having said that, invitations to serve on a programme committee are not that uncommon or that high-profile, and advertising for special session proposals is fine as long as they're not automatically accepted.
Open access journal scams
Recently open-access journals have begun to appear. These journals provide free access to readers on the web and charge authors to publish. This is a big improvement over the traditional model of subscribing to journals since it makes results freely available to all. However, it allows for a new type of scam.In August 2008 I was invited to join the editorial board of a journal, which is normally quite an honour. I work in the area of the journal but didn't recognise the editor and decided to check him out on the web before replying. It soon turned out this was an open access journal scam, which was new to me. The "publisher" was in fact a single individual at a private address who was attempting to recruit academics to serve on his various editorial boards in an attempt to make them look legitimate and so attract others to the editorial boards and to submit papers. This is what a major publisher does when setting up a new journal, but a major publisher has the resources to do this properly (remember the section on quality!). This individual appeared to be working on his own and apparently is not affiliated with any insitution and doesn't even have a degree. This is something like trying to pass yourself off as a doctor without having gone to medical school.
See also
- Beware of VIDEA! - nonsense abstracts accepted by a conference.
- SCIgen affair - a computer-generated paper was accepted by a conference.
- Blog mentioning a bogus journal
- Wikipedia article on peer review "Although generally considered essential to academic quality, peer review has been criticized as ineffective, slow, and misunderstood."
- World Multiconference on Systemics, Cybernetics and Informatics (WMSCI)
- Oxford Round Table
|
|
|
From the JargonFile A style of (incompetent) programming dominated by ritual inclusion of code or program structures that serve no real purpose. A cargo cult programmer will usually explain the extra code as a way of working around some bug encountered in the past, but usually neither the bug nor the reason the code apparently avoided the bug was ever fully understood. It's an example of the CargoCult AntiPattern.At the next level, we get the lovely phenomenon of CargoCultCodeReviews. That's where, instead of detecting if your code is flexible and maintainable, the reviewer declares you did not construct your bamboo radar antenna to the correct shape. Even if you thought outside the box, and made a radar dish that actually works, there's no response to these kinds of critiques. You cannot use logic to talk someone out of a position they did not use logic to adopt.
[RE: You cannot use logic to talk someone out of a position they did not use logic to adopt. - Excellent point! I'll need to remember this the next time TopMind speaks up.[TM is that most subtle of chronic trolls - just friendly enough you feel sorry for him, and just knowledgeable enough to always know the most inflammatory response. You can lead him to teach you a lot of good OO theory if you are not careful!
[My statement applies more directly to Big-Tent Atheists arguing with Young Earth Creationists. Their positions are more identical than they can perceive - both working hardest to convince themselves!]
- I heard that. My opponents usually insist on using ArgumentFromAuthority, and call my complaints "cargo cult" because they cling to authorities, which is anti-science by my assessment. -top
- We've seen the "logic" by which you make your assessments, too.
|
|
|
MSDN Blogs
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.
The rest is just practice.
Jack Shainsky
I agree with Mike about importance of knowing your debugger, but after learning to use the debugger many people, even very experienced, remain closely tied to it. When they find a bug, they immediately begin to debug it, passing lots of code just in order to get to the _suspected_ piece and find that the problem isn't there. The continue the routine until they finally find the bug, then they fix it and feel proud of themselves.
I think that the very important thing for novices (and not only for them) is: Learn to NOT use your debugger until you _absolutely_ have to do so. Reading logs (and putting them in necessary places in first place) and passing code in mind can give you enough information to fix the bug, and it will take tenth of time you would need to find the problem with debugger.
Robert Sayre
I have been programming since 1997, when I took Introduction to Computer Graphics in art school. I thought it would be Macromedia Director type stuff, and the school's course catalog was a little confusing. It turned out that it was a semester of C followed by a semester of C with OpenGL. I ended up liking it more than art courses.
I think I can still remember what that level of knowledge was like, and I wish it had been made clearer to me just how hard it is to be a good programmer. I think most novice courses lie about this difficulty, in order not to intimidate students.
I wish someone had showed me this:
Teach Yourself Programming in Ten Years http://norvig.com/21-days.html
|
|
|
|
|
|
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.
|
|
|
# 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.
|
|
|
Cargo Cultism, Part Four: Other DisciplinesJust 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.
|
|
|
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 SumNow 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 FunctionThe 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.
|
|
|
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 ProgrammersBottom line... understand the meaning and purpose of every line of code before you try to change it.
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.
Filed under: C++
|
|
|
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=0If 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.
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
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. 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 to buy a cup of coffee for authors of this site |
Disclaimer:
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: February 19, 2014
