Of course, I went to Stuyvesant Highschool in new york city, a specialized science and technology highschool. Theres a test to get in (despite being a public school) so you have several hundred of NYC's smartest students...
Not suprisingly, wasn't any prejudice against geeks (nor, really much in general). I wasn't remotely the most popular person in my class (was kind of a geek, even for stuy), but didn't suffer anything like what's described here.
I actually had good experieces through all my time in the NYC public school system, probably due to the efforts of my parents (thanks mom) for making sure I wound up in the good ones.
The careful text books measure (Let all who build beware!) The load, the shock, the pressure Material can bear. So, when the buckled girder Lets down the grinding span, The blame of loss, or murder, Is laid upon the man. Not on the Stuff--the Man!
But in our daily dealing With stone and steel, we find The Gods have no such feeling Of justice toward mankind. To no set guage they make us,-- For no laid course prepare-- And presently o'ertake us With loads we cannot bear. Too merciless to bear.
The prudent text-books give it In tables at the end-- The stress that shears a rivet Or makes a tie-bar bend-- What traffic wrecks macadam-- What concrete should endure-- But we, poor Sons of Adam, Have no such literature, To warn us or make sure!
We hold all Earth to plunder-- All Time and Space as well-- Too wonder-stale to wonder At each new miracle; Till, in mid-illusion Of Godhead 'neath our hand, Falls multiple confusion On all we did or planned. The mighty works we planned.
We only of Creation (Oh, luckier bridge and rail!) Abide the twin-damnation-- To fail and know we fail. Yet we--by which sole token We know we once were Gods-- Take shame in being broken However great the odds-- The Burden or the Odds.
Oh, veiled and secret Power Whose paths we seek in vain, Be with us in our hour Of overthrow and pain; That we--by which sure token We know thy ways are true-- In spite of being broken, Because of being broken, May rise and build anew. Stand up and build anew!
Seriously, though, this idea that power and ease of use are mutually exclusive is a myth.
Equally mythical, IMO (but no moreso) is the idea that anything can be made easy with the right UI. There is, I will readily admit, no excuse for making cryptic software. However some things are, in fact, complicated, and at some point, that complexity must be made visible to the user. If not, then one gets million-deep menus, brain-damaged wizards, and the like, as you attempt to express complicated concepts, in a simple "language".
Setting up your modem to dial your ISP so you can surf the web, shouldn't require any understanding of TCP/IP, routing, etc. Or indeed, be any more complicated than using the web. Optimizing your multi-homed machine to efficiently route http requests over your IP tunnel, will require that knowledge, no matter how hard you work to conceal it, and it should at that point be assumed that the user has that knowledge....
It's all one big symbiotic process that helps create really good and usable products through an evolutionary development process. It takes time and it takes a lot of work and coordination.
This IMHO, is one of the best points in this comment, that argues both for, and against, many of the points made.
dria makes some very good points about what good documentation requires, however many ideas are drawn from the way things work in a proprietary software shop. However, what works there, may or may not work (or even be desireable) in an open source environment. Thus the interesting question, is what development model/methodology will work best for documentation. Does writing tech docs require co-ordination? One thing the whole "bazaar" model of development does relatively well, is feedback, and incremental improvement. Can useful docs be made by starting with something, and a whole butch of Natural-Language programmers (maybe a hacker-friendly term for doc writers?) hacking them into line?
Maybe the help system should actively solicit user feedback on what worked and didn't. Get "end-users" when the docs are wrong, to fix them. This sort of dynamic involvement of the user has always been our greatest strength, programming-wise, and it's often been done with little, or no, centralized co-ordination. Can we leverage it into documentation?
The article misses one big point. (aside from many inaccracies and invalid comparisons)
It is possible for opensource software to be supported by commercial entities w/o becoming proprietary.
e.g. in http://www.opensource.org/for-suits.html several models are introduced. I think that with IBM, Dell, and compaq now (or soon) offering hardware with Linux installed one bears repeating:
Widget Frosting
In this model, a hardware company (for which software is a necessary adjunct but strictly a cost rather than profit center) goes open-source in order to get better drivers and interface tools cheaper. ..... The open-source culture's exemplars of commercial success have, so far, been service sellers or loss leaders. Nevertheless, there is good reason to believe that the clearest near-term gains in open-source will be in widget frosting.
If IBM and Compaq switched just one tenth of their AIX and Digital Unix teams to Linux programming, they could contribte immensly....
Slashdot Mirror
he said He3. A very different isotope than the normal He4 :)
Of course, I went to Stuyvesant Highschool in new york city, a specialized science and technology highschool. Theres a test to get in (despite being a public school) so you have several hundred of NYC's smartest students...
Not suprisingly, wasn't any prejudice against geeks (nor, really much in general). I wasn't remotely the most popular person in my class (was kind of a geek, even for stuy), but didn't suffer anything like what's described here.
I actually had good experieces through all my time in the NYC public school system, probably due to the efforts of my parents (thanks mom) for making sure I wound up in the good ones.
But good schools do exist.... There is hope.
-Fyndo ('88)
Hymn Of Breaking Strain by Rudyard Kipling
The careful text books measure
(Let all who build beware!)
The load, the shock, the pressure
Material can bear.
So, when the buckled girder
Lets down the grinding span,
The blame of loss, or murder,
Is laid upon the man.
Not on the Stuff--the Man!
But in our daily dealing
With stone and steel, we find
The Gods have no such feeling
Of justice toward mankind.
To no set guage they make us,--
For no laid course prepare--
And presently o'ertake us
With loads we cannot bear.
Too merciless to bear.
The prudent text-books give it
In tables at the end--
The stress that shears a rivet
Or makes a tie-bar bend--
What traffic wrecks macadam--
What concrete should endure--
But we, poor Sons of Adam,
Have no such literature,
To warn us or make sure!
We hold all Earth to plunder--
All Time and Space as well--
Too wonder-stale to wonder
At each new miracle;
Till, in mid-illusion
Of Godhead 'neath our hand,
Falls multiple confusion
On all we did or planned.
The mighty works we planned.
We only of Creation
(Oh, luckier bridge and rail!)
Abide the twin-damnation--
To fail and know we fail.
Yet we--by which sole token
We know we once were Gods--
Take shame in being broken
However great the odds--
The Burden or the Odds.
Oh, veiled and secret Power
Whose paths we seek in vain,
Be with us in our hour
Of overthrow and pain;
That we--by which sure token
We know thy ways are true--
In spite of being broken,
Because of being broken,
May rise and build anew.
Stand up and build anew!
Equally mythical, IMO (but no moreso) is the idea that anything can be made easy with the right UI. There is, I will readily admit, no excuse for making cryptic software. However some things are, in fact, complicated, and at some point, that complexity must be made visible to the user. If not, then one gets million-deep menus, brain-damaged wizards, and the like, as you attempt to express complicated concepts, in a simple "language".
Setting up your modem to dial your ISP so you can surf the web, shouldn't require any understanding of TCP/IP, routing, etc. Or indeed, be any more complicated than using the web. Optimizing your multi-homed machine to efficiently route http requests over your IP tunnel, will require that knowledge, no matter how hard you work to conceal it, and it should at that point be assumed that the user has that knowledge....
As simple as possible, but no easier.
This IMHO, is one of the best points in this comment, that argues both for, and against, many of the points made.
dria makes some very good points about what good documentation requires, however many ideas are drawn from the way things work in a proprietary software shop. However, what works there, may or may not work (or even be desireable) in an open source environment. Thus the interesting question, is what development model/methodology will work best for documentation. Does writing tech docs require co-ordination? One thing the whole "bazaar" model of development does relatively well, is feedback, and incremental improvement. Can useful docs be made by starting with something, and a whole butch of Natural-Language programmers (maybe a hacker-friendly term for doc writers?) hacking them into line?
Maybe the help system should actively solicit user feedback on what worked and didn't. Get "end-users" when the docs are wrong, to fix them. This sort of dynamic involvement of the user has always been our greatest strength, programming-wise, and it's often been done with little, or no, centralized co-ordination. Can we leverage it into documentation?
-FyndoIt is possible for opensource software to be supported by commercial entities w/o becoming proprietary.
e.g. in http://www.opensource.org/for-suits.html several models are introduced. I think that with IBM, Dell, and compaq now (or soon) offering hardware with Linux installed one bears repeating:
If IBM and Compaq switched just one tenth of their AIX and Digital Unix teams to Linux programming, they could contribte immensly....