Cargo cultists and the separate ways people search for answers 2

[psemianonymous]

I think this encapsulates my entire experience at Tek-Tips:

"Cargo Cultists, Part Three: Is Mort A Cargo Cultist?"

http://blogs.msdn.com/ericlippert/archive/2004/03/02/82840.aspx

In this, "Mort" refers to the in-house, 'line-of-business' developer. I link to the third part of the article, because the first part is possibly offensive to the Morts among us, though was not intended to be so(

http://blogs.msdn.com/ericlippert/archive/2004/03/01/82168.aspx).

I think this is an excellent positive spin as to why many of the tek-tippers seem so rushed. They just want answers. Most are extremely gracious and thankful when you can provide those answers.


Pete


Related, yet unrelated:

"Cargo Cult Software Engineering"

http://www.stevemcconnell.com/ieeesoftware/eic10.htm

 

[pmonett]

Great articles.
I suggest that someone create an official Voodoo Developer certificate program. I know a few people I could dubb CVD Gold !

Pascal.

 

[MakeItSo]

Really interesting!
I never knew I was a "Mort" - but I definitely am. Sounds like this guy was watching me work when describing Mort...


Now honest:

...Eric's advice for novice programmers is:
[ul][li]Don't be a cargo cultist -- understand the meaning and purpose of every line of code before you try to change it.[/li]
[li]Understand abstraction, and use it appropriately.[/li]
[/ul]
...that advice was directed towards people who want to be Elvis

Now I do not agree with this at all. This is also good advice for all MOrts out there, i.e. for all who program "quick and dirty", just fit for a specific (recurring) problem.
Even if you are not a studied developer and don't have the necessary knowledge for true OOP - abstraction and simplification is always good advice for any programmer...

It makes your programs faster, shorter and better readable.
Just imagine you try to pick up some code you wrote a year ago and try to generalize it to encompass a larger application range.

DO that with some non-simplified code and try to remember your ideas from a year ago to get the meaning of the code...

 

[Craftor]

Very nice articles indeed, and good advice too. I can remember when I started programming just wanting to get the apps out there and working - not bothering to understand what the code was actually doing - so when major changes or bugs came along - I had no idea what was actually happening...

Yes, I have gotten better since ;-)

 

[lionelhill]

(1) No, this sort of thing matters Drastically. Absolutely Drastically. One of the reasons I'm forced to program is because some of the commercial stuff available to frobnicate my widgets was clearly written by people who Didn't Think about how their code was doing it. Yes, it does the job, if you happen to have a Mega-super-computer available and don't mind leaving it half an hour grinding away at the hard disk. But I get upset when I find the same calculation, on the same data, can take 5 secs when done by a 30-min piece of coding written by an amateur. Why should I pay thousands to get something that works more slowly??

(2) I get depressed by the number of learners and students here who just want the first functional answer, and don't care about the "but if you did..."s. These people are going to write the sort of software I'm upset by, and expect me to pay them to do it.

(3) The thing I find interesting is the interraction with abstraction. Abstraction of course is good because it increases programming efficiency. But the whole point of abstraction as presented in most text-books, is that you no longer have to understand how something works in order to use it. But that is exactly what turns people into cargo-cult programmers. The reason that my commercial software (above) doesn't work is, I think, because it's working on a very large file of 2-dimensional data arranged the wrong way round. It's read it into memory (it thinks) so it doesn't care that it's reading the file "sideways". But actually the data are stuck in the Windows swap file or somewhere and are still being read from disk, so it's a really good idea to rearrange your methods to read sequentially.... In some ways it's a pity that anyone ever invented virtual memory. Abstraction is a land-mine for the unknowledgable.

(4) Another example. There exists a commercial piece of software running a lab instrument that makes measurements every few seconds. A part of it fits a regression line through the data and calculates the reliability of the line on the basis of how many points were measured and how scattered the data are about the line (very standard statistics). Unfortunately someone also had the idea of adding extra interpolated data points between the measured ones. They wrote everything all nice and abstractly so that no other programmer needed to know this - it would all work anyway. So the statistics chap/chappess programmed their part to use all the data, even though lots of the points are ficticious. As a result the instrument produced the Wrong Answers, as commercially sold. I don't know if it still does, as I haven't used the latest version of the software.

Beware of Abstraction without Brain Engaged.

Sorry to rant at length.

 

[CajunCenturion]

I understand what you're saying lionelhill, but one thing that you must also keep in mind. Most often, Mort's write specific little programs for specific little problems. And whereas that little program will work fine on their dataset, it will fail miserably on other datasets, because they are written with certain specifics in mind. It is not a general solution.

Commercial software, on the other hand, must deal and work with all cases, and provide general solutions. You cannot take advantage of known attributes of the dataset, or of the environment, because they are unknown. The general solution may work more slowly, but it also works on a much broader scale.

To perhaps illustrate that point, taking from your third paragraph,

The reason that my commercial software (above) doesn't work is, I think, because it's working on a very large file of 2-dimensional data arranged the wrong way round. It's read it into memory (it thinks) so it doesn't care that it's reading the file "sideways".

I have to ask the following question. Who turned the file sideways? Who arranged the data and where did it come from? How do you know that your situation is not the sideways exception, and not the norm. Here, and again in your 4th paragraph, you citing very specific situations as a criticism of commercial software. The fault may lie with the commercial software, but it could also lie in one of two other areas. The purchaser failed in due diligence to insure that the software was a good fit for their situation, or in the user who didn't fully understand what the chosen software was doing. Your claims may be quite valid, but I suspect that you're not telling the whole story.

I think that your second paragraph completely misses the point. With just a very few exceptions, the Mort's here that are looking for the first functional solution are not putting together commercial software. They are writing a specific piece of code to solve a specific problem in their line of business.

I'm not defending all commercial software by any means, because there is a lot of it that it just plain junk. But, if I'm going spend thousands of dollars on some software, then I'm going to damn sure that I know what I'm buying.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[lionelhill]

See what you mean, Cajun, I think I tend to think about myself and forget others. In my defence, I did say "learners and students" in paragraph 2, and if you're learning you should be open to ideas that don't seem relevant just now - they might be in the future. But of course tek-tips is not primarily here for learners and students! Hence red-flagging!

As regards the examples I gave, both are real and complete except I don't want to get myself jumped on for naming names. The sideways one is data from mass spectroscopy where the dimensions are mass and time. The machine has measured mass spectra at time points and stored them as a list of spectra (all the masses at one time, then all the masses at the next time and so on). It would, theoretically, be possible for an instrument to store the data the other way round (all the times at one mass, then at the next mass...) but it would be a difficult thing to do from the instrument's perspective.

I appreciate this is a very specific problem; but there is a case for understanding one's data and choosing a solution that is NOT general, but happens to be highly efficient to the specific data concerned. That even applies to commercial things: sometimes I want to pay for speed and efficiency rather than generality.

Thanks for your comments. I'm going to go and ponder.

 

[MakeItSo]

Sounds intriguing - and scaring. But I think the main problem here (as with many I have discovered) is not, that the programmer didn't fully grasp what his lines of code were doing, but he obviously didn't understand the task he was trying to fulfil with that code!

I think that's the main problem. A programmer who doesn't abstract and simplify because he doesn't understand the code will definitely not be able to program any sophisticated application and will thus not cost us money.

It's the programmers who don't think about what they're doing and thus cannot abstract and simplify the problem the're trying to solve...

You can be an ingenious programmer and still be unable to write good applications, cause they might not suit everyday needs...

I'm no cargo cultist and I would definitely recommend these people to get rid of this habit...
I'm neither Elvis nor Einstein but I deeply respect these people - they can code in the guts of an application I'd never understand...

But for everyday business needs, there's nothing better than a good Mort! Make the code as good as possible given the time frame of your project. If you're sure you might need the code again one day, abstract and simplify (and bug fix) it after the project...

 

[CajunCenturion]

... that the programmer didn't fully grasp what his lines of code were doing, but he obviously didn't understand the task he was trying to fulfil with that code!

This does often happen, and everyone loves to jump on the programmer without any consideration to the fact the the code may be doing exactly what was asked for. The problem often lies in difference between what a user needs, and what a user ask for. Not anyone fault necessarily, but definately a communication problem.

A programmer who doesn't abstract and simplify because he doesn't understand the code will definitely not be able to program any sophisticated application and will thus not cost us money.

That is a complete non-sequitar. I don't see at all where one follows from the other. I also think that statement is referring to a Mort, not a professional programmer.

It's the programmers who don't think about what they're doing and thus cannot abstract and simplify the problem the're trying to solve...

Offense accepted!


Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[MakeItSo]

Not anyone fault necessarily, but definately a communication problem

Agreed. Although it is often a certain snobbishness of certain programmers (esp. Elvis's who think they're Einsteins...)

I also think that statement is referring to a Mort, not a professional programmer.

Yes, that is who it was meant for.

Sharp as a blad, as always, Cajun.

 

[MakeItSo]

Oooops, what a typo! I meant sharp as a BLADE, of course. ;-)

 

[CajunCenturion]

I won't argue about the snobbishness of certain programmers, because it's true that sometimes, such snobbishness exists. But more often than not, the problem is caused by users not saying what they mean, leaving out a functional requirement, taking for granted that the programmer knows everything the user knows about their job, and assuming and expecting that the programmer will be able to discern what they need based on what they ask for. And then, blaming the programmer for not delivering what they want, when all the programming did was deliver exactly what they asked for.

It is the "snobbish" programmer who is held accountable (and judged by those very same users) when the user thinks "you idiot", and says, "but that's not what I meant".

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[lionelhill]

True, very true. Communication has two sides, and we users don't always do our bit.