Before throwing your hat in with this guy, you might want to research his motivations.
Congratulations, you have just committed the fallacious technique that C. S. Lewis found so common he decided he had to make up a word for it - Bulverism. It's also known as the genetic fallacy. Speculations about a person's motivations do not prove or disprove their assertions - you have to actually examine their reasoning. And I do mean speculations, as finding that someone has a potential motivation does not prove that that is the only thing motivating them - people are rarely motivated by just one thing, and people's motivations are often mixed, if not contradictory. Speculating about their motivations first is putting the cart before the horse.
Lewis coined the term Bulverism back in the 1940's. From what I can see, the ubiquitous use of it has grown enormously since then, to the point where it seems that political discourse has shifted from being about "who's right?", to being about "Who's righteous?". Bulverism has contributed heavily to the tendency to merely demonize the opponent, rather than actually debate on the real issues. Let's not contribute to its continuation, ok?
As a ham, I want to know what the RFI profile of CFLs are before putting them in the house. Normal flourescent lights are sometimes sources of RFI. If CFLs are likely to interfere with my radio operations, I'm not likely to use them.
My preferred solution is a La Femme Nikita style covert anti-spammer group. The main difference is that there wouldn't be much need to recruit from death row, as there would probably be a L-O-N-G waiting list of mail admins wanting to join.
"I was falsely accused of a hideous crime and sentenced to a life in prison. One night, I was taken from my cell to a place called Section 551, the most covert anti-spammer group on the planet . . . Their ends are just, but their means are ruthless. If I don't play by their rules, I die . ..<snort> yeah, like that's gonna happen - I'm getting to do nasty things to spammers. This is great!"
I think a lot of this comes down to the 'solutions mindset' vs the 'tools mindset'. A 'Solution' is self-contained, operates itself, and requires little thought. A 'Tool', on the other hand, requires a wielder (or operator), may need other tools to be effective, and requires thought and skill to use.
The problem is that computer technology, by and large, is much more a tool than it is a solution, while management tends to gravitate towards 'solutions'.
Most 'silver bullets' are in fact useful tools, if treated as such. When treated as a solution, they always come up short, because no tool, by itself, is a full-blown solution. The result is that management ends up using and discarding one silver bullet after another, rather than concentrating on gathering a useful set of tools and a group of people capable of using them skillfully.
As a RAD environment, it is (or was:) ) without peer.
For database work, VB was unparalleled.
I'd challenge both of these. Though not well enough known, Clarion (http://www.softvelocity.com) definitely challenges VB as a RAD environment, and beats it hands down for database work. Clarion's dictionary and template-based generator will write most database code for you. Even more impressive, once you've defined the tables you need in the dictionary, Clarion will slickly generate a full-blown data entry program for those tables. That's often how I start out new applications - define tables in the dictionary, generate the data entry program, and then tweak as necessary. It gives you a definite leg up on getting an app started, and if you are careful while creating the dictionary, you won't have to do that much tweaking.
Now if we could just get SoftVelocity to market it better
MS is pretty well getting in the habit of understating or perhaps blandly stating any problems. I particularly have noticed that with every release of Windows, error messages get more and more vague. I fully expect that by the time Vista makes it to market, all error messages will be replaced by a single pop-up that reads "Something bad happened". Figuring out exactly which bad thing happened will be left as an exercise for the poor techie who gets called in to "Fix this problem right now!".
- None of this would even be a question if the inventor hadn't patented it... the invention simply wouldn't exist!
This is utter hogwash, particularly in the area of software, where independent invention is commonplace. Inventions don't cease to exist simply because someone fails to patent them. And while the possibility of patenting an invention may provide an additional incentive, it is hardly the sole necessary incentive to invention. It's not like the software industry went nowhere before an activist judge or two decided to legislate software patents into existence.
I'd hate to have him as a neighbor when I fire up the ham receiver. The RFI out of that thing is going to be pretty bad, as the case really provides little shielding. And forget selling something like this commercially, no way he could get FCC certification.
Number one, those people are already employed full-time, so they ARE doing a hobby.
I think you're completely missing the point of the article. He's blowing apart the 'Linux is just a toy OS written by hobby programmers who a real OS company would never let near their code' FUD that Microsoft et al like to use against Linux. The point is that while Linux developers may be hobbyists in the sense that they're doing this for fun, they're not the incompetents that anti-Linux FUD would make them out to be.
Plus... how do we really know what security problems are fixed in MSIE? On my XP box at home, and the W2K boxes I have to use at work, the Windows Updates just say things like, "A security problem could allow an attacker access to your computer." How am I to know what that security problem is, what part of the system it affects? I don't even know if it is function I use, or even have enabled--the update information is just too terse--at that's after clicking, "Show Details".
(My main systems are Linux and Mac, so there may be a way to get more information from Windows Update, but it isn't as obvious... unlike Mac OS X Software Update, where it lists the major components right there, and links that take you to the Apple web site for more information.)
This seems to be a problem that's endemic in recent Microsoft releases, not just in Windows Update. Error messages and error information displayed by M$ OSs and applications seem to get more and more vague with each release. By the time Longhorn actually makes it to market, I fully expect that all error messages will be reduced to a single window that will pop up every so often, reading simply "Something Bad Happened".
On an unrelated note: I wonder how project planning estimate accuracy correlates with the experience level of the person making the estimate. Because if the IT industry tends to burn out the young people os that there are't many older IT people, that could contribute as well.
For a good look at this, see Tom DeMarco's "Controlling Software Projects". One of Tom's points is that one reason we are so bad at estimation is that we so rarely do it. What we often oall estimation is often actually more like negotiation: "How long will it take you to do X?" "Three months" "No, that's too long" "How about 2 months?" "OK, thanks for the estimate". Instead of actually trying to predict how long it will take, you're negotiating what the schedule will be.
It doesn't matter how much time I spend in the pre-planning stage, meeting with users, coming up with all the needs and feature requests. Once the project is in progress, and specially as you start demoing it, the end users will start adding requirements that had never come up before no matter how detailed you tried to be. And of course all the "wouldn't it be nice if"s.
I call this Heisenburg's Law of Software Delivery: The act of delivering to a client what he wants changes what he wants.
Managers generally don't want to give the programmers the whole picture, because management often believes that they are superior in rank to programmers, placing the programmers on a need-to-know-basis, only. Huge mistake.
I call this the myth (or culture) of managerial superiority. It tends to go "I'm your boss, therefore I must be smarter than you are." It's one of the reasons that some managers come to resent technical people, whose jobs require that they be smart, and who are not usually reluctant to show those smarts. Maintaining a culture of managerial superiority is difficult when your subordinates often demonstrate that they know more than you do. Too often, the result is either denigration of the subordinates knowledge (You were hired for your expertise in X, but your manager keeps on overriding you on matters relating to X, leading you to wonder "Why did they hire me if they won't pay attention to the knowledge I was hired for?"), or denigration of the importance of subordinates knowledge.
The fact is, management requires a different set of abilities, not necessarily a superior set of abilities. Acknowledge that, and you've at least opened the door for each side to recognize the others talents and use them together.
I don't get your logic... who can be held accountable for FOSS?
You say right now Microsoft can be held accountable for their software? I don't believe that. When have we seen a major lawsuit because of security holes in Microsoft software? In fact, when have we seen lawsuits because of security holes in any software, proprietary or open source?
Once again, we're seeing ManagementThink in action. Us techies tend to think of support in information-gathering terms, while management tends to think in business-entity terms. While we tend to look for whatever information is needed to keep things working, management tends to look for some business entity to take responsibility for it. Actually being able to win a legal case against this entity in case things go wrong isn't in view so much as the mere fact that you have some viable business entity put into the 'responsible for this technology' slot.
Microsoft understands this. When they harp on the 'where will you get support' issue, note that they don't really focus on whether or not their support is effective, just on that fact that they're a business that a manager can point to as filling the slot. Having someone to fill in the slot is so comforting to management that they tend to ignore the fact that Microsoft's licensing pretty well precludes being able to sue when things go wrong (although I wonder how much you'd be able to shake up management's confidence by making comments along the line of "Lemme get this straight. You actually think it's good policy to bet our business on being able to beat Microsoft in a lawsuit?"
It is faster to develop an application in VB than any other Language
Actually, for speed of development for business applications, I'd rather go with Clarion. Clarion also lets you generate whole applications with a few clicks, but the templates mechanism that makes this possible is open, and you can add your own template code to automate things that you find yourself doing often. This is better than 'wizards'. I just wish they would port the environment to Linux.
So what does it mean if they no longer support it.
It means that PHB types will be shaking in their boots if they oversee projects that use VB6 code. Management generally sees 'support' in business-entity terms - they expect some business entity to take "responsibility" for dealing with a particular technology. They can have oodles of employees who actually know more about the technology (in this case VB6) than the vendor, but let the vendor go away, and as far as manglement is concerned, the product is dead.
We techies tend to think in information-gathering terms - as long as we can get the information we need, we're happy, whereever the information comes from. That's one reason we like FOSS so much - the information is readily available. Management tends to think in terms of responsible business entities, and if those entities go away, they're lost.
What gets me most is the near-universal bland, meaningless and Bulverising replies in the "Company Says" section. "Oh, you can't trust these web sites to be impartial". Um, we can't trust you to be impartial either, guys. As long as your responses are typical of company policies that prioritize PR over actually doing things right, I'm going to give serious attention to the complaints on such web sites.
By and large, you deserve these sites. As long as you prioritize PR over actually doing things right, the only way people will have to resolve their problems with you is going to be to give you bad PR. Don't complain about the bad PR if your priorities make that the only way people can get satisfaction from you.
People are trying to look like they are doing something even though their proposed "solutions" make no sense.
This is extraordinarily common nowadays. I've come to refer to it as 'prioritizing PR over actual effectiveness'. Let this go long enough, and it becomes acceptable to actually make the problem worse, as long as you can argue that 'looks' like you're trying to solve the problem.
You can actually get AOL to stop sending you CDs. When I was at Interop a few years ago. I stopped by the AOL booth, gave them my address, and asked that it be taken off of their mailing list. I haven't seen an AOL CD mailed to me since.
I wouldn't go so far as to say they are always wrong, they are just in over their heads in many cases where they are trying to explain something they don't understand
It's not just that they're in over their heads, it's that they don't realize or don't acknowledge that fact. Sometimes it's as though they think that being anointed as journalists magically gives them the ability to pull out the pertinant points of material they don't fully understand. And too often, if you point out errors, you get back a bunch of handwaving, followed by "We stand by our story". I'm not sure if it's ego, or just that they're afraid that if they acknowledge mistakes too often, they'll lose readers. I think it's just the opposite. I'll listen a lot more to someone who makes mistakes, but will acknowledge them when they do, than to someone who feels they have to keep up an appearance of being mistake-free.
Slashdot Mirror
Congratulations, you have just committed the fallacious technique that C. S. Lewis found so common he decided he had to make up a word for it - Bulverism. It's also known as the genetic fallacy. Speculations about a person's motivations do not prove or disprove their assertions - you have to actually examine their reasoning. And I do mean speculations, as finding that someone has a potential motivation does not prove that that is the only thing motivating them - people are rarely motivated by just one thing, and people's motivations are often mixed, if not contradictory. Speculating about their motivations first is putting the cart before the horse.
Lewis coined the term Bulverism back in the 1940's. From what I can see, the ubiquitous use of it has grown enormously since then, to the point where it seems that political discourse has shifted from being about "who's right?", to being about "Who's righteous?". Bulverism has contributed heavily to the tendency to merely demonize the opponent, rather than actually debate on the real issues. Let's not contribute to its continuation, ok?
another good reason for pushing the FairTax and getting rid of Federal Income Tax altogether.
As a ham, I want to know what the RFI profile of CFLs are before putting them in the house. Normal flourescent lights are sometimes sources of RFI. If CFLs are likely to interfere with my radio operations, I'm not likely to use them.
My preferred solution is a La Femme Nikita style covert anti-spammer group. The main difference is that there wouldn't be much need to recruit from death row, as there would probably be a L-O-N-G waiting list of mail admins wanting to join.
I think a lot of this comes down to the 'solutions mindset' vs the 'tools mindset'. A 'Solution' is self-contained, operates itself, and requires little thought. A 'Tool', on the other hand, requires a wielder (or operator), may need other tools to be effective, and requires thought and skill to use.
The problem is that computer technology, by and large, is much more a tool than it is a solution, while management tends to gravitate towards 'solutions'.
Most 'silver bullets' are in fact useful tools, if treated as such. When treated as a solution, they always come up short, because no tool, by itself, is a full-blown solution. The result is that management ends up using and discarding one silver bullet after another, rather than concentrating on gathering a useful set of tools and a group of people capable of using them skillfully.
I'd challenge both of these. Though not well enough known, Clarion (http://www.softvelocity.com) definitely challenges VB as a RAD environment, and beats it hands down for database work. Clarion's dictionary and template-based generator will write most database code for you. Even more impressive, once you've defined the tables you need in the dictionary, Clarion will slickly generate a full-blown data entry program for those tables. That's often how I start out new applications - define tables in the dictionary, generate the data entry program, and then tweak as necessary. It gives you a definite leg up on getting an app started, and if you are careful while creating the dictionary, you won't have to do that much tweaking.
Now if we could just get SoftVelocity to market it better
How many people do you know who don't want more seconds (or more likely, minutes or hours) in a day?
No, for Bill it's not about money, it's about "winning". He grew up in a home where competition was heavily stressed, and he's still running on that.
MS is pretty well getting in the habit of understating or perhaps blandly stating any problems. I particularly have noticed that with every release of Windows, error messages get more and more vague. I fully expect that by the time Vista makes it to market, all error messages will be replaced by a single pop-up that reads "Something bad happened". Figuring out exactly which bad thing happened will be left as an exercise for the poor techie who gets called in to "Fix this problem right now!".
This is utter hogwash, particularly in the area of software, where independent invention is commonplace. Inventions don't cease to exist simply because someone fails to patent them. And while the possibility of patenting an invention may provide an additional incentive, it is hardly the sole necessary incentive to invention. It's not like the software industry went nowhere before an activist judge or two decided to legislate software patents into existence.
I'd hate to have him as a neighbor when I fire up the ham receiver. The RFI out of that thing is going to be pretty bad, as the case really provides little shielding. And forget selling something like this commercially, no way he could get FCC certification.
I think you're completely missing the point of the article. He's blowing apart the 'Linux is just a toy OS written by hobby programmers who a real OS company would never let near their code' FUD that Microsoft et al like to use against Linux. The point is that while Linux developers may be hobbyists in the sense that they're doing this for fun, they're not the incompetents that anti-Linux FUD would make them out to be.
This seems to be a problem that's endemic in recent Microsoft releases, not just in Windows Update. Error messages and error information displayed by M$ OSs and applications seem to get more and more vague with each release. By the time Longhorn actually makes it to market, I fully expect that all error messages will be reduced to a single window that will pop up every so often, reading simply "Something Bad Happened".
For a good look at this, see Tom DeMarco's "Controlling Software Projects". One of Tom's points is that one reason we are so bad at estimation is that we so rarely do it. What we often oall estimation is often actually more like negotiation: "How long will it take you to do X?" "Three months" "No, that's too long" "How about 2 months?" "OK, thanks for the estimate". Instead of actually trying to predict how long it will take, you're negotiating what the schedule will be.
I call this Heisenburg's Law of Software Delivery: The act of delivering to a client what he wants changes what he wants.
I call this the myth (or culture) of managerial superiority. It tends to go "I'm your boss, therefore I must be smarter than you are." It's one of the reasons that some managers come to resent technical people, whose jobs require that they be smart, and who are not usually reluctant to show those smarts. Maintaining a culture of managerial superiority is difficult when your subordinates often demonstrate that they know more than you do. Too often, the result is either denigration of the subordinates knowledge (You were hired for your expertise in X, but your manager keeps on overriding you on matters relating to X, leading you to wonder "Why did they hire me if they won't pay attention to the knowledge I was hired for?"), or denigration of the importance of subordinates knowledge.
The fact is, management requires a different set of abilities, not necessarily a superior set of abilities. Acknowledge that, and you've at least opened the door for each side to recognize the others talents and use them together.
Once again, we're seeing ManagementThink in action. Us techies tend to think of support in information-gathering terms, while management tends to think in business-entity terms. While we tend to look for whatever information is needed to keep things working, management tends to look for some business entity to take responsibility for it. Actually being able to win a legal case against this entity in case things go wrong isn't in view so much as the mere fact that you have some viable business entity put into the 'responsible for this technology' slot.
Microsoft understands this. When they harp on the 'where will you get support' issue, note that they don't really focus on whether or not their support is effective, just on that fact that they're a business that a manager can point to as filling the slot. Having someone to fill in the slot is so comforting to management that they tend to ignore the fact that Microsoft's licensing pretty well precludes being able to sue when things go wrong (although I wonder how much you'd be able to shake up management's confidence by making comments along the line of "Lemme get this straight. You actually think it's good policy to bet our business on being able to beat Microsoft in a lawsuit?"
Actually, for speed of development for business applications, I'd rather go with Clarion. Clarion also lets you generate whole applications with a few clicks, but the templates mechanism that makes this possible is open, and you can add your own template code to automate things that you find yourself doing often. This is better than 'wizards'. I just wish they would port the environment to Linux.
It means that PHB types will be shaking in their boots if they oversee projects that use VB6 code. Management generally sees 'support' in business-entity terms - they expect some business entity to take "responsibility" for dealing with a particular technology. They can have oodles of employees who actually know more about the technology (in this case VB6) than the vendor, but let the vendor go away, and as far as manglement is concerned, the product is dead.
We techies tend to think in information-gathering terms - as long as we can get the information we need, we're happy, whereever the information comes from. That's one reason we like FOSS so much - the information is readily available. Management tends to think in terms of responsible business entities, and if those entities go away, they're lost.
What gets me most is the near-universal bland, meaningless and Bulverising replies in the "Company Says" section. "Oh, you can't trust these web sites to be impartial". Um, we can't trust you to be impartial either, guys. As long as your responses are typical of company policies that prioritize PR over actually doing things right, I'm going to give serious attention to the complaints on such web sites.
By and large, you deserve these sites. As long as you prioritize PR over actually doing things right, the only way people will have to resolve their problems with you is going to be to give you bad PR. Don't complain about the bad PR if your priorities make that the only way people can get satisfaction from you.
This is extraordinarily common nowadays. I've come to refer to it as 'prioritizing PR over actual effectiveness'. Let this go long enough, and it becomes acceptable to actually make the problem worse, as long as you can argue that 'looks' like you're trying to solve the problem.
Where is Nikita when you need her?
You can actually get AOL to stop sending you CDs. When I was at Interop a few years ago. I stopped by the AOL booth, gave them my address, and asked that it be taken off of their mailing list. I haven't seen an AOL CD mailed to me since.
It's not just that they're in over their heads, it's that they don't realize or don't acknowledge that fact. Sometimes it's as though they think that being anointed as journalists magically gives them the ability to pull out the pertinant points of material they don't fully understand. And too often, if you point out errors, you get back a bunch of handwaving, followed by "We stand by our story". I'm not sure if it's ego, or just that they're afraid that if they acknowledge mistakes too often, they'll lose readers. I think it's just the opposite. I'll listen a lot more to someone who makes mistakes, but will acknowledge them when they do, than to someone who feels they have to keep up an appearance of being mistake-free.
This is Slashdot. Someone will correct you even if you are right.