In the commercial world I see Open Source from a totally different perspective.
Rather than writing everything from scratch, I can make new, obscure, hardware work by modifying an existing OS; and I get a robust OS working on my obscure hardware in the least amount of time.
Rather than being helpless to a vendor's technical support; I can fix problems myself or ask a community of knowledgeable people. When my customers call with a problem, no need to play the blame game (i.e. "it's the other software you're running -- go ask their tech support). Instead, I can find the solution!
Open Source is a fundamental change. It is a new paradigm. It's software as a service, not software as a product.
Bezroukov chastises Raymond for seeing OSS from Raymond's perspective, then turns around to claim that the right way to view open source is from an academic perspective.
What does the world look like from an ivory tower? Bezroukov knows!
The vent was worth it (even if you're not a EE)!;)
Nevertheless, if your solution has not solved the problem (and OO* hasn't), then it's not the solution. As much common sense as OO, iso9000, CASE, etc... make, they have proven that, in the real world, they are not the software development silver bullets they claim to be.
Your argument is a kin to saying "if everybody would be nice to each other, we'd have world peace". Dream on.
The solution is not in the development cycle.
The solution is Open Source (if you read my other post).
Obviously an academic. Spend a few years in the real world.
I've been a software programmer for hardware companies for over twenty years. I've heard so many EE's tell we idiot programmers to "just use the black-box appraoch".
The truth is:
1) Hardware is simpler than software; it's easy to compartmentalize (firmware, like hardware, is also much simpler), and
2) Even so, hardware does suffer from the same ills as software.
Stick that in your academic ear!
It really irks me when I see another EE who's taken the requisite programming class, written "hello whirled", and come to the conclusion that software is simple, programmers must be dumb!
"If builders built buildings the way programmers wrote programs, the first woodpecker to come about would destroy civilization" -- I wish I new who said that first. I first heard it back in '82, when I got my first programming job.
At first, I thought the problem was: trying to define an analog world via a discrete logic; you can predicate every point you can think of, and still not adequately describe a multidimensional problem space (i.e. it takes an infinite number of points to fill a 3D space).
Ever since Chaos theory was postulated, I believe it to be the finest description of software: "A sufficiently complex system behaves as if at random". That's software.
The onus is always placed on the programmers: "why can't we figure out what the stupid woodpeckers do?"
Believing the blame is ours, I once sought refuge in high level tools, CASE systems, and ISO 9000 paradigms. Only to find out that there are no "silver bullets" for software; adding more software to solve the problem of software only adds to it's complexity, and worsens the problem.
I see every youthful programmer fall into this trap: we always want to write a new language or a new tool that will make programming simpler, but we inevitably add to the complexity (I apologize to all my previous employers for every programming aid I've ever written!)
The problem is exacerbated by the marketing Balmer'$ of the world: software is a product: you cut a CD for a nickel and sell it for $100.00 (that nickel amortizes the software development cost). If there's a problem, sell them the update for another $100.00 next month. Balmer and Gates have made a little profit with this paradigm.
But, we've found the solution. Open Source.
It parallels the analog world: do you expect your automobile to run without tune-ups and never break down? Do you expect that, if your car breaks down, you can call high-school dropout tech support in Detroit and have them describe the fix via pushing buttons on the dashboard? If that doesn't fix it, are you supposed to buy a new car?
The current paradigm is maligned; yet users buy it hook, line, and sinker (often blaming themselves for the problem)!
As George Bonser said: "would you buy a car with the hood welded shut?"
Service is the answer. Software is a service, not a product. In an unprecedented throat-slitting, golden-egg-laying-goose-for-dinner maneuver, Balmer said that last week; legitimizing the Open Source movement. The only way to quickly and deterministically service a product is to have the source... find "what the programmer was thinking", and fix it or do it the way the programmer intended. Guessing and hacking at dialogs and re-installing are too frustrating and unproductive.
The "single handedly designs, develops, integrates, and maintains a work of art" is a dead giveaway for a primadonna.
Also, referring to oneself as "the important programmer" is quite a 2x4-upside-the-head hint.
"Getting the job done" suggests and end-state, where "developer" implies an Ivory Tower. I tried to label myself "Applied, Practical Programmer" once, to embody the "no BS; lets make this work quickly" attitude... but I ended up sounding like a primadonna.
The "mental model" used for debugging is common to all non-clueless programmers. Nobody sifts thru the code after being told of a bug; their eyes roll to gaze at their forehead while the work the problem backwards.
The basic problem with a primadonna is: there are few useful tasks (beyond "hello whirled") that can be designed, coded, integrated and maintained by one person. Any useful application of substance requires a team and teamwork; which is alien to the premadonna.
They're good for firmware writing, since that's usually a small piece of code with well defined boundaries and interfaces.
Don't get mad at me for the label; I've been a premadonna too (I've caught myself twice in the last week alone!)
This is the sort of psychobable that led me to drop the school of Psychology in favor of a Computer Science degree (since then, I've found CS to be as much alchemy as Psychology).
When you try to quantify and categorize behavior, you always find that you:
1) force fit folks who don't fit; change the song to make the words rhyme.
2) have too many exceptions to be a scientifically valid theory.
So, it's my turn:
You have four types of programmers:
1) Clueless -- in way to deep over their heads, don't understand the subject, and it shows.
2) Hacker -- I'm going to fix this problem any way I can and by any means necessary and am going to be obsessively focused. Can cause a coronary if allowed to work with Windoze for more than a year (unless they figure out that the solution requires a fork-lift).
3) Guru -- Everybody turns to them for an answer; in reality, they just know how to use the man pages.
4) Primadonna -- works well in teams of 1 or fewer. Must understand everything in minute detail before any work can be started. Has written the ultimate "hello whirrled" program.
I've been all of these often; sometimes in the same day.
Slashdot Mirror
In the commercial world I see Open Source from a totally different perspective.
Rather than writing everything from scratch, I can make new, obscure, hardware work by modifying an existing OS; and I get a robust OS working on my obscure hardware in the least amount of time.
Rather than being helpless to a vendor's technical support; I can fix problems myself or ask a community of knowledgeable people. When my customers call with a problem, no need to play the blame game (i.e. "it's the other software you're running -- go ask their tech support). Instead, I can find the solution!
Open Source is a fundamental change. It is a new paradigm. It's software as a service, not software as a product.
Bezroukov chastises Raymond for seeing OSS from Raymond's perspective, then turns around to claim that the right way to view open source is from an academic perspective.
What does the world look like from an ivory tower? Bezroukov knows!
Chris
The vent was worth it (even if you're not a EE)! ;)
Nevertheless, if your solution has not solved the problem (and OO* hasn't), then it's not the solution. As much common sense as OO, iso9000, CASE, etc... make, they have proven that, in the real world, they are not the software development silver bullets they claim to be.
Your argument is a kin to saying "if everybody would be nice to each other, we'd have world peace". Dream on.
The solution is not in the development cycle.
The solution is Open Source (if you read my other post).
Chris
Obviously an academic. Spend a few years in the real world.
I've been a software programmer for hardware companies for over twenty years. I've heard so many EE's tell we idiot programmers to "just use the black-box appraoch".
The truth is:
1) Hardware is simpler than software; it's easy to compartmentalize (firmware, like hardware, is also much simpler), and
2) Even so, hardware does suffer from the same ills as software.
Stick that in your academic ear!
It really irks me when I see another EE who's taken the requisite programming class, written "hello whirled", and come to the conclusion that software is simple, programmers must be dumb!
Hugs & Kisses,
Chris
"If builders built buildings the way programmers wrote programs, the first woodpecker to come about would destroy civilization" -- I wish I new who said that first. I first heard it back in '82, when I got my first programming job.
At first, I thought the problem was: trying to define an analog world via a discrete logic; you can predicate every point you can think of, and still not adequately describe a multidimensional problem space (i.e. it takes an infinite number of points to fill a 3D space).
Ever since Chaos theory was postulated, I believe it to be the finest description of software: "A sufficiently complex system behaves as if at random". That's software.
The onus is always placed on the programmers: "why can't we figure out what the stupid woodpeckers do?"
Believing the blame is ours, I once sought refuge in high level tools, CASE systems, and ISO 9000 paradigms. Only to find out that there are no "silver bullets" for software; adding more software to solve the problem of software only adds to it's complexity, and worsens the problem.
I see every youthful programmer fall into this trap: we always want to write a new language or a new tool that will make programming simpler, but we inevitably add to the complexity (I apologize to all my previous employers for every programming aid I've ever written!)
The problem is exacerbated by the marketing Balmer'$ of the world: software is a product: you cut a CD for a nickel and sell it for $100.00 (that nickel amortizes the software development cost). If there's a problem, sell them the update for another $100.00 next month. Balmer and Gates have made a little profit with this paradigm.
But, we've found the solution. Open Source.
It parallels the analog world: do you expect your automobile to run without tune-ups and never break down? Do you expect that, if your car breaks down, you can call high-school dropout tech support in Detroit and have them describe the fix via pushing buttons on the dashboard? If that doesn't fix it, are you supposed to buy a new car?
The current paradigm is maligned; yet users buy it hook, line, and sinker (often blaming themselves for the problem)!
As George Bonser said: "would you buy a car with the hood welded shut?"
Service is the answer. Software is a service, not a product. In an unprecedented throat-slitting, golden-egg-laying-goose-for-dinner maneuver, Balmer said that last week; legitimizing the Open Source movement. The only way to quickly and deterministically service a product is to have the source... find "what the programmer was thinking", and fix it or do it the way the programmer intended. Guessing and hacking at dialogs and re-installing are too frustrating and unproductive.
The "single handedly designs, develops, integrates, and maintains a work of art" is a dead giveaway for a primadonna.
Also, referring to oneself as "the important programmer" is quite a 2x4-upside-the-head hint.
"Getting the job done" suggests and end-state, where "developer" implies an Ivory Tower. I tried to label myself "Applied, Practical Programmer" once, to embody the "no BS; lets make this work quickly" attitude... but I ended up sounding like a primadonna.
The "mental model" used for debugging is common to all non-clueless programmers. Nobody sifts thru the code after being told of a bug; their eyes roll to gaze at their forehead while the work the problem backwards.
The basic problem with a primadonna is: there are few useful tasks (beyond "hello whirled") that can be designed, coded, integrated and maintained by one person. Any useful application of substance requires a team and teamwork; which is alien to the premadonna.
They're good for firmware writing, since that's usually a small piece of code with well defined boundaries and interfaces.
Don't get mad at me for the label; I've been a premadonna too (I've caught myself twice in the last week alone!)
Chris
This is the sort of psychobable that led me to drop the school of Psychology in favor of a Computer Science degree (since then, I've found CS to be as much alchemy as Psychology).
When you try to quantify and categorize behavior, you always find that you:
1) force fit folks who don't fit; change the song to make the words rhyme.
2) have too many exceptions to be a scientifically valid theory.
So, it's my turn:
You have four types of programmers:
1) Clueless -- in way to deep over their heads, don't understand the subject, and it shows.
2) Hacker -- I'm going to fix this problem any way I can and by any means necessary and am going to be obsessively focused. Can cause a coronary if allowed to work with Windoze for more than a year (unless they figure out that the solution requires a fork-lift).
3) Guru -- Everybody turns to them for an answer; in reality, they just know how to use the man pages.
4) Primadonna -- works well in teams of 1 or fewer. Must understand everything in minute detail before any work can be started. Has written the ultimate "hello whirrled" program.
I've been all of these often; sometimes in the same day.
Chris