APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

When the how gets ahead of the why

© September 2004 John G. Spragge
Sun Sep 19 03:17:41 2004 When the how

In the theatre and movies, the technique known as 'method acting' has a religious status among its adherents. Sceptics love to mock this attitude, and they tell the following story about an encounter between Lord Olivier and Dustin Hoffman on the set of Marathon Man. Hoffman, a famously devoted method actor, had prepared for a scene in the movie by running full tilt through Central Park, and panted up to the set, covered with mud and brambles, just as Olivier rolled up in a limousine. Olivier asked Hoffman what on earth had happened to him. Nothing, replied Hoffman; he was just preparing himself for his role. Oliver responded with an astonished: "But my dear boy, why don't you just act?"

I can think of few professions which obsess as much about their methods as acting and programming. From 'method acting' to structured programming and open source, we focus with religious intensity on the way we do things. In fact, we get involved in such frequent, detailed, and bitter arguments that we frequently seem to forget to ask why we do them. In all the obsessive arguments on web forums about why we should or should not avoid Windows, sign an NDA, or click the 'I Agree' button on a EULA, I rarely see any mention of the reason for doing the work in the first place. The triumph or trashing of open source gets treated as an end in itself.

Programming and the programming community do not, or at least should not, exist as ends in themselves. They serve a purpose. Whatever our professional controversies, we owe it to ourselves and the world we live in to relate them, at some point, to the needs of people who will use what we write. To put the word in its larger context, we should stop fussing so much about how we do what we do, or how we distribute the fruits of our actions, and just act.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> When the how gets ahead of the why

Inexpensive and informative Apple related e-books:

Take Control of High Sierra

Take Control of IOS 11

El Capitan: A Take Control Crash Course

iOS 8: A Take Control Crash Course

Photos: A Take Control Crash Course

More Articles by © John G. Spragge

---September 19, 2004

Perhaps it is because both professions are much more art than science?


---September 19, 2004

It's been my experiance that computer software is art. Much more then "enginneering". I worked several years as a artist assistant to a successfull fine artist, and have taken several years of formal study of commercial and fine art.

I decided a while ago that I didn't want to be a commercial artist. I don't want to make ads for people. However being a successfull fine artist is next to impossible, it's like being a pro basketball star. So since I liked computers I decided to dedicate a great deal of my time to try to understand as much about computers as possible.

I've noticed a large corilation between being a artist and programmer. One example:

If your a bridge builder, you have a finished product. You have a time were you call quits and it's finished and you'll probably never spend much time ever again on that bridge.

But art and programming is not like that. A artist is never finished with a painting and programming always has bugs. As a art student the hardest thing to do is to call it quits, there is always "one more thing", you add a figure their, it makes the painting unbalanced, so you have to add another object their to correct it. But then there is a ugly brush stroke and you try to fix that and you mess up, and you have to compencate and cover it up with something. etc etc etc.

Eventually what happens is that you grind the painting into the ground and ruin it. Eventually you just have to say "it's finished NOW" and leave it alone even though there is more work to be done. This can be borne out thru the fact that it's very very rare that a fine art gallery or museum will ever have a original artist to fix a damaged piece. They would simply change everything around and then all documentation will be screwed up forever. So they hire a specialist artist/restorer to fix things.

That's like programming becuase the deadline is ever present and eventually the product must ship if you want to make money, bugs and all.

I think that you end up breaking programmers into 2 main groups:
"hackers" and "software engineers".

Hackers tend to go on about the "Tao of Programming" and stuff like the "Unix Philosophy".

Software enginneers go on about professional and marketable results and debate the merits of things like "Extreme Programming" or "Object Oriented Programming".

Of course nobody falls exactly within the two groups, everything is a mixture. Everybody is a individual.

But I guess what I am saying is that if art is indeed like programming and visa versa, then the art of programming is in the act of programming, not the finished product. That's kinda of what Open source is about. Closed source along the lines of trying to engineer a bridge, to make a finished polished object that will live forever as a object unto itself. Open source advocates concintrate on the proccess of creation, on the proccess of programming. There are no realy finished product, there are only release revisions and obligations for backward compatability.

Were both traditional attitude of commercial software falls short is that concitrating on the finished product and the end user ignores the reality of software, that is never finished, there are never realy any ending it's just a continuation of earlier work on bug fixes. As a Linux guy I just assume that I can upgrade my software to the newest version and gain functionality and solve problems. But if I am using NT 4.0 I get no benifit of Windows 2000 even though they are pretty much the same OS. Different in more name then anything else, one is mearly a evelutionary extenstion of the other.

Were blindly adhearing to Free Software ideals falls short is that it ignores that software is ment to be used. And not just bug tested or used by other developers and themselves, but by people who couldn't care less, nor should care, about the proccess of the creation of software they use daily. They exist soly to use software for some other purpose that has very little to do with the software in the first place it is mearly a tool.

But the fact is that the method of creation is as important as the end result. The method defines the end result, you can't seperate the two.

The Open Source method creates something that is unique and has qualities that are nearly unobtainable by commercial means, it even affects the end user. But the same goes either way. There are qualities of commercial software that are unobtainable thru free software means. The trick is to find the correct balance for success.

Then on top of that you through things like "freedom" "intellectual property" "liberty", and the idea that what people choose now will set the destiny of software and movement/manipulation of knowledge in general for the next hundred years. Hell you can't even get people to agree to the definition of the words.. It just makes a huge mess.


This article reminds me about something in the automotive world some 40 years ago having to do with getting bogged down with inconsequential details and nitpicking.

In the early 1960's, Detroit introduced bucket seats into their bread-and-butter cars. At the time, the Chevrolet Corvair and the Ford Falcon competed for the fuel economy segment of the market (this at a time when regular gasoline cost about 25 cents per gallon). Both cars got good mileage, even by today's standards (the Falcon was good for 26 MPG in average driving) but were otherwise uninspiring.

In those days, gas economy -- and the feeble performance that went with it -- really didn't sell cars (nor did safety). So in an attempt to appeal to a broader market, both Ford and Chevrolet manufacturered "sporty" versions of their economobiles, equipped with among other things, bucket seats.

Both seat designs had lateral pleats in the seat cushion, with the pleats in the Corvair being fewer and wider than those in the Falcon. A great debate arose in the automotive press as to which was better: wide or narrow pleats. Somehow in the process no one seemed to focus on whether the seats were actually comfortable to sit in on a long drive, which, of course, was what really mattered.

My point is that like arguing over bucket seat pleats, belaboring one programming method or another is kind of silly. What really matters is whether the program works, runs at a reasonable rate of speed, and can be understood by someone other than the original author should the need arise for modifications. If those requirements can be met, than there's no reason to hash out microscopic coding details.


---September 20, 2004

But arguing the details is so much fun :-)

No, seriously, I have a great example. There's a thread in c.o.l.m about swtching from tcsh to bash. I said at the beginning that no good would come of it, and indeed it has blossomed into 80+ nitpicking posts arguing esoteric details. Gawd. What a waste :-)



---September 20, 2004

Well it's always very easy to get nit picky about stuff. There are always people that will argue esoteric detail after esoteric detail for hours on end. It's like the more obscure or unusual things they whine about the more expert they are at something (at least in their own minds).

But for me when it comes to choosing software to use, having it open source is a definite plus. It's a fact that having a product open source offers significant advantages to the end user as well as the developer.

But it's not going to a overriding thing, it's not the end all and it's not going to solve all technical problems. Other issues are just as important: security,ease of use, compliance to standards (open source != open standards), performance and so on and so forth.

Another thing is that the people that get all argumentative and nit picky about details often don't represent the actual people that do do the work. They may seem to be the most representative of open source projects, commercial software, Linux or whatever, but perceptions don't often reflect reality.

Daniel Roberts, the creator of the Gentoo Linux OS notes in this article the type of busy-bodies that you run into.


---September 20, 2004

Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

I think it’s a new feature. Don’t tell anyone it was an accident. (Larry Wall)

Linux posts

Troubleshooting posts

This post tagged:







Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode

SCO Unix Sales, Support, & Service

Phone:  707-SCO-UNIX (707-726-8649Toll Free: 833-SCO-UNIX (833-726-8649)