I agree, it's the evolution that dies not the use. I regularly make use of other people's half-finished software projects, most of which will never be completed, and this hasn't made them any less valuable to me.
The problem I encounter is that none of these projects has been GPL'ed, and half of them haven't had their source code released. For those for which I have source code, in most instances I have sent the authors patches; but few of the patches have ever been released back into the public code stream. Since the projects are not GPL'ed (or equivalent), I am not able to fork the project and carry it forward into its second life.
My plea to the authors of both the projects is for them to open source them, publish the source code, and announce to their users that they will no longer be maintaining the projects. As long as the projects are free to be carried forward by another maintainer, at their leisure, then someone will eventually pick it up.
I recently had success getting money out of UPS (that they claimed I wasn't owed) by sending a complaint to the Better Business Bureau; they even have a website.
In 1986 David L. Parnas and PC Clements published a paper entitled, A Rational Design Process: How and Why To Fake It. Parnas and Clements present a strategy for imposing overlying order upon the often fractured development process; the goal of which is to produce better software. Doing snippets of work for managers/clients who don't care about quality as much as they care about costs is often a cause of this fracturing.
A key to providing backward compatibility is "design intent"; i.e., closely examine the backwards compatibility issue when you are first thinking about creating a piece of software. Internal data structures, external file formats, APIs, etc. are all influenced by the design constraints placed upon a project. If one of those constraints is backward compatibility then these structures will all be built differently than in the case where no backward compatibility is ever required.
FrameMaker is a great example of an application that appears to have been architected from day one to provide backward compatibility: every version of FrameMaker imports and exports Maker Interchane Files (.MIF files) and so it is trivial to move files between releases of the application. While I'm sure this causes the developers some headaches from time to time, I know from personal experience that a constant anchor point like.MIF files influences coding decisions.
Having done work on an ASCII interchange mechanism for a multiplatform application, I can be fairly certain that the FrameMaker decision isn't very difficult to implement: each release of the application has a pair of small functions, one to walk the internal data structure and emit the ASCII interchange format, and another that parses the ASCII interchange file and produces an internal data structure.
When we designed our application, the ASCII interchange functionality was deemed important; this influenced the internal data structures, which in turn influenced the binary data files. If we had tried to bolt backward compatibility on at a later date (i.e., in version 2.0) it could have been a lot of work; whereas, building it in from day one didn't cause any extra work.
Conscious design intent is the key to making backward compatibility a non-issue.
Definitely not new. The standard Nortel product configuration for secure 802.11b is to put the Baystack wireless access points on the one side of an encrypted VPN firewall (Nortel's Contivity product) and the corporate global WAN on the other.
Sorry for the product plug (I do work there), but as other have pointed too, NASA hasn't "come up with a solution"; more likely they've read our (or our competitor's) data sheets.
I listened to this report when it was broadcast yesterday, via WUNC's ShoutCast web stream. The radio piece is not as negative as the written article; in fact it ends on an upbeat. It really is worth a listen.
I'm slightly better off than the original poster: I have a 10 by 10 office with a door that closes. This allows me to play music without headphones and without disturbing my neighbours.
To faciliate tunes I installed a Turtle Beach Audiotron, and I've never looked back---it's wonderful. I play it back through the external PC speakers (a little y-adapter works wonders); which is hi-fi enough for the office.:)
Jordy, you're completely missing the point. You have clouded the writer's religious bias against western civilization by bringing facts into the discussion. If the writer had wanted to be deal with facts he would never have written his article in the first place: he only wants us westerners to acknowledge that johnny-come-latelys to the Internet game should have an equal place at the table. In other words, stop the Internet and computer technology from moving forward until everyone's perspectives have been completely accomodated; everyone, that is, except for those who started the revolution!
It is interesting to note that none of the concepts advocated by the XP method are new to XP. XP is simply the latest collection of these practices; all of which are good and should be practiced.
But I think discounting it because you don't like the name and are scared of pairing with someone else is highly unprofessional and closed minded.
NOT to your credit, you've responded negatively and harshly to the poster's concerns. Rather than simply tell of your positive experience with pairing, you denigrade the poster's concern. That isn't the way to win him over to your perspective!
As another poster wrote, this is because they usually aren't asked to estimate their tasks. Lots of times, their managers estimate their tasks for them!
This point and the others you've made all come back to a single underlying problem: most s/w developers don't get any better unless they are forced to. This is a sad comment on the industry in which I work. Geeks, hackers, s/w professionals, etc. all pride themselves on keeping their knowledge level at the leading edge (i.e., they're up on the latest developments) and yet they spend no time on personal discipline. Watching how I do my work so that I can ferret out mistakes and do a better job doesn't appear to be part of how the average person works.
In my experience managing software developers the difficulty is this: after even 10 years writing software, most programmers have no idea how long it will take them to implement a feature specification. At a higher level, most developers don't have any idea how long it will take them to develop the feature spec. in the first place. Go another step and ask them to write a test plan, and you'll discover that most developers don't even know what a test plan is.
Even more disturbing is the fact that after these lackings have been pointed out to the so-called developers, they show no personal initiative to improve their skills. Until I, the manager, force them to improve, they don't. There is still way too much of the "s/w development is an _art_" thinking floating around.
Re:Well, I see the usual anti-union bushwah
on
IT Unions?
·
· Score: 1
This comment, and the others in this thread (wish I could reply to a collection of comments), all express my own sentiments; however, I do have one additional thought.
People form unions in order to control the corporation they work for. The NetSlaves piece does an excellent job in explaining how business colluded with politicians and they collectively abused their power; hence, unions were the necessary tool to overthrow those in power. In our North American world today, I don't believe it is common for this level of abuse to occur, and so unions exerting that level of control is unnecessary.
Instead of controling your employer, I believe a more ethical approach is to quit and go elsewhere. If a manager keeps losing his employees because he's a jerk, he'll eventually be fired. If a company overworks their employees, they will be unable to keep them. Voting with our feet is the democratic way to express our opinion to a bad employer. Coercing them through a union is simply unethical.
Let's generate a constructive response to bullying
on
Sean In The Middle
·
· Score: 1
Rather than everyone launching into the usual/. rant about how unfair Sean has been treated, why doesn't the./ community put together some constructive instructions (a resource book) to help bullied youth (and adults for that matter) respond in a way that sees the bullies stopped and punished. As Sean's story shows, what typically happens is that youth respond in anger and end up having their rights curtailed; leaving the bullies to continue picking on others.
You wrote, "it causes me any harm that your bull banged my cows, you owe me". As the ruling also points out, if a farmer calls Monsanto and complains about "volunteer" plans then Monsanto will come and remove the offending plants at their own expense.
As I point out in my earlier post on this subject, if the farmer had simply made use of all the canola in his field there wouldn't have been a problem. The judge found Monsanto's case to have merit because the farmer culled Monsanto's offspring out of his harvest and only replanted those.
Personally, I think the farmer had every right to do that given the Stray Bull caselaw to which the judge refered. I guess that's why I'm not a judge.:)
As I see it there are two key points that deserve special coverage by the press, but which have not received proper mention:
While the Roundup resistant plants came to reside in Mr. Schmeiser's field through no fault of his own, he lost the case because he took actions to specifically harvest those "volunteer" plants and use that Roundup resistant seed for subsequent plantings. If he had not taken this specific action to harvest resistant see I do not believe he would have lost his case. See paragraph number 102 for the judge's thoughts on these actions.
Paragraph number 59 in the ruling notes that for the planting of Mr. Schmeiser's 1999 crop he purchased new seed from a source "which would be unquestioned". The paragraph goes on to note that "Roundup Ready canola were said to be found within the 1999 canola fields". This note is important because it demonstrates that there is no reasonable action which farmers can take in order to completely eliminate Monsanto's product from their fields. It would be very interesting to have the appropriate expert estimate how long it will be before all of Canada's canola crops become essentially "Roundup Ready" (through no fault of non-licensing farmers).
As you hint at, a faraday shield can be quite cheaply used to inhibit the use of radio frequency devices. When a building owner is performing renovations it is trivial and fairly cheap to put up a wire screen between the steel studs and drywall. So, no special active devices are needed to inhibit cell phones, pagers, two-way radios, etc.
Is the FCC content protection agnostic (that is, is the FCC opinionated about the "protection" of the bits flowing through the ether)? Do you see this position changing in the near-term/long-term? How does this position get reflected in FCC policy, spectrum sale, cable policy, etc.?
The preceding follow-up cuts to half of the heart of the issue: the old guard always objects to new things. The other half of the matter is also worth considering: the up-and-comers always think that everything new is better.
What both extreme sides of this issue miss is that there are many, many of the old-ish guard--like me, a 40 year old high tech worker--who strive to find the middle ground. Not everything new is good, but neither is everything new bad.
Just because technology allows the exchange of kidi-porn to now be done anonymously in near real time doesn't mean the abused kids went unharmed. Just because technology makes it easy to copy CDs doesn't mean that copying other peoples' CDs isn't theft.
Being able to do something doesn't make it right. The fact that something feels good to do it doesn't mean that it is good to do. I am able to run people over with my car, but I don't. I feel good when I insult an ignorant customer service person, but it doesn't help him/her or I to do it.
Wisdom is all about knowing the difference between what one is able to do and what one should do. The process of maturing is all about learning this difference and teaching one's self to modify one's behaviour accordingly.
Sorry this reads like a sermon, but I'm not Heinlein and didactic brain candy isn't my specialty.
At the end of your post you ask, "Is this teaching?" This type of situation (an imposed development toolset) is very much a reflection of the real working world. If you ultimately take a job with an existing company and become part of a pre-established development team, you will probably not have any say in what compiler or environment is being used.
Learn to view these constraints in a positive way---that is, as a challenge---and you will be much happier. That said, don't hesitate to influence others with your experiences in a friendly manner.
The person interviewed for the article states that they "don't filter everything." This means that they do filter something. I personally approve; however, where are all the anti-filtering bigots now? How is it that when this school filters it's OK, but when other institutions filter it's bad?
Slashdot Mirror
I agree, it's the evolution that dies not the use. I regularly make use of other people's half-finished software projects, most of which will never be completed, and this hasn't made them any less valuable to me.
The problem I encounter is that none of these projects has been GPL'ed, and half of them haven't had their source code released. For those for which I have source code, in most instances I have sent the authors patches; but few of the patches have ever been released back into the public code stream. Since the projects are not GPL'ed (or equivalent), I am not able to fork the project and carry it forward into its second life.
My plea to the authors of both the projects is for them to open source them, publish the source code, and announce to their users that they will no longer be maintaining the projects. As long as the projects are free to be carried forward by another maintainer, at their leisure, then someone will eventually pick it up.
I recently had success getting money out of UPS (that they claimed I wasn't owed) by sending a complaint to the Better Business Bureau; they even have a website.
In 1986 David L. Parnas and PC Clements published a paper entitled, A Rational Design Process: How and Why To Fake It. Parnas and Clements present a strategy for imposing overlying order upon the often fractured development process; the goal of which is to produce better software. Doing snippets of work for managers/clients who don't care about quality as much as they care about costs is often a cause of this fracturing.
I couldn't find a copy of the paper online, but it has recently been re-published in Software Fundamentals: Collected Papers by David L. Parnas.
A key to providing backward compatibility is "design intent"; i.e., closely examine the backwards compatibility issue when you are first thinking about creating a piece of software. Internal data structures, external file formats, APIs, etc. are all influenced by the design constraints placed upon a project. If one of those constraints is backward compatibility then these structures will all be built differently than in the case where no backward compatibility is ever required.
.MIF files influences coding decisions.
FrameMaker is a great example of an application that appears to have been architected from day one to provide backward compatibility: every version of FrameMaker imports and exports Maker Interchane Files (.MIF files) and so it is trivial to move files between releases of the application. While I'm sure this causes the developers some headaches from time to time, I know from personal experience that a constant anchor point like
Having done work on an ASCII interchange mechanism for a multiplatform application, I can be fairly certain that the FrameMaker decision isn't very difficult to implement: each release of the application has a pair of small functions, one to walk the internal data structure and emit the ASCII interchange format, and another that parses the ASCII interchange file and produces an internal data structure.
When we designed our application, the ASCII interchange functionality was deemed important; this influenced the internal data structures, which in turn influenced the binary data files. If we had tried to bolt backward compatibility on at a later date (i.e., in version 2.0) it could have been a lot of work; whereas, building it in from day one didn't cause any extra work.
Conscious design intent is the key to making backward compatibility a non-issue.
Definitely not new. The standard Nortel product configuration for secure 802.11b is to put the Baystack wireless access points on the one side of an encrypted VPN firewall (Nortel's Contivity product) and the corporate global WAN on the other.
Sorry for the product plug (I do work there), but as other have pointed too, NASA hasn't "come up with a solution"; more likely they've read our (or our competitor's) data sheets.
I listened to this report when it was broadcast yesterday, via WUNC's ShoutCast web stream. The radio piece is not as negative as the written article; in fact it ends on an upbeat. It really is worth a listen.
The San Francisco Chronicle wrote, Static electricity can discharge more easily through dry, cold air than in humid weather.
This is incorrect. We experience shocks when the air is dry because humid air prevents the static charges from building up in the first place.
I'm slightly better off than the original poster: I have a 10 by 10 office with a door that closes. This allows me to play music without headphones and without disturbing my neighbours. To faciliate tunes I installed a Turtle Beach Audiotron, and I've never looked back---it's wonderful. I play it back through the external PC speakers (a little y-adapter works wonders); which is hi-fi enough for the office. :)
Personally, I think Aerons suck.
McSpew must be a vi bigot. <grin>
Jordy, you're completely missing the point. You have clouded the writer's religious bias against western civilization by bringing facts into the discussion. If the writer had wanted to be deal with facts he would never have written his article in the first place: he only wants us westerners to acknowledge that johnny-come-latelys to the Internet game should have an equal place at the table. In other words, stop the Internet and computer technology from moving forward until everyone's perspectives have been completely accomodated; everyone, that is, except for those who started the revolution!
Well said.
It is interesting to note that none of the concepts advocated by the XP method are new to XP. XP is simply the latest collection of these practices; all of which are good and should be practiced.
NOT to your credit, you've responded negatively and harshly to the poster's concerns. Rather than simply tell of your positive experience with pairing, you denigrade the poster's concern. That isn't the way to win him over to your perspective!
This point and the others you've made all come back to a single underlying problem: most s/w developers don't get any better unless they are forced to. This is a sad comment on the industry in which I work. Geeks, hackers, s/w professionals, etc. all pride themselves on keeping their knowledge level at the leading edge (i.e., they're up on the latest developments) and yet they spend no time on personal discipline. Watching how I do my work so that I can ferret out mistakes and do a better job doesn't appear to be part of how the average person works.
Sigh.
In my experience managing software developers the difficulty is this: after even 10 years writing software, most programmers have no idea how long it will take them to implement a feature specification. At a higher level, most developers don't have any idea how long it will take them to develop the feature spec. in the first place. Go another step and ask them to write a test plan, and you'll discover that most developers don't even know what a test plan is.
Even more disturbing is the fact that after these lackings have been pointed out to the so-called developers, they show no personal initiative to improve their skills. Until I, the manager, force them to improve, they don't. There is still way too much of the "s/w development is an _art_" thinking floating around.
This comment, and the others in this thread (wish I could reply to a collection of comments), all express my own sentiments; however, I do have one additional thought.
People form unions in order to control the corporation they work for. The NetSlaves piece does an excellent job in explaining how business colluded with politicians and they collectively abused their power; hence, unions were the necessary tool to overthrow those in power. In our North American world today, I don't believe it is common for this level of abuse to occur, and so unions exerting that level of control is unnecessary.
Instead of controling your employer, I believe a more ethical approach is to quit and go elsewhere. If a manager keeps losing his employees because he's a jerk, he'll eventually be fired. If a company overworks their employees, they will be unable to keep them. Voting with our feet is the democratic way to express our opinion to a bad employer. Coercing them through a union is simply unethical.
Rather than everyone launching into the usual /. rant about how unfair Sean has been treated, why doesn't the ./ community put together some constructive instructions (a resource book) to help bullied youth (and adults for that matter) respond in a way that sees the bullies stopped and punished. As Sean's story shows, what typically happens is that youth respond in anger and end up having their rights curtailed; leaving the bullies to continue picking on others.
You wrote, "it causes me any harm that your bull banged my cows, you owe me". As the ruling also points out, if a farmer calls Monsanto and complains about "volunteer" plans then Monsanto will come and remove the offending plants at their own expense.
:)
As I point out in my earlier post on this subject, if the farmer had simply made use of all the canola in his field there wouldn't have been a problem. The judge found Monsanto's case to have merit because the farmer culled Monsanto's offspring out of his harvest and only replanted those.
Personally, I think the farmer had every right to do that given the Stray Bull caselaw to which the judge refered. I guess that's why I'm not a judge.
As you hint at, a faraday shield can be quite cheaply used to inhibit the use of radio frequency devices. When a building owner is performing renovations it is trivial and fairly cheap to put up a wire screen between the steel studs and drywall. So, no special active devices are needed to inhibit cell phones, pagers, two-way radios, etc.
Is the FCC content protection agnostic (that is, is the FCC opinionated about the "protection" of the bits flowing through the ether)? Do you see this position changing in the near-term/long-term? How does this position get reflected in FCC policy, spectrum sale, cable policy, etc.?
I completely agree. I took a look at the ballot posted at Sun Sentinel.com and anyone confused by this ballot is probably not qualified to vote!
What both extreme sides of this issue miss is that there are many, many of the old-ish guard--like me, a 40 year old high tech worker--who strive to find the middle ground. Not everything new is good, but neither is everything new bad.
Just because technology allows the exchange of kidi-porn to now be done anonymously in near real time doesn't mean the abused kids went unharmed. Just because technology makes it easy to copy CDs doesn't mean that copying other peoples' CDs isn't theft.
Being able to do something doesn't make it right. The fact that something feels good to do it doesn't mean that it is good to do. I am able to run people over with my car, but I don't. I feel good when I insult an ignorant customer service person, but it doesn't help him/her or I to do it.
Wisdom is all about knowing the difference between what one is able to do and what one should do. The process of maturing is all about learning this difference and teaching one's self to modify one's behaviour accordingly.
Sorry this reads like a sermon, but I'm not Heinlein and didactic brain candy isn't my specialty.
At the end of your post you ask, "Is this teaching?" This type of situation (an imposed development toolset) is very much a reflection of the real working world. If you ultimately take a job with an existing company and become part of a pre-established development team, you will probably not have any say in what compiler or environment is being used.
Learn to view these constraints in a positive way---that is, as a challenge---and you will be much happier. That said, don't hesitate to influence others with your experiences in a friendly manner.
Best of luck on the course.
The person interviewed for the article states that they "don't filter everything." This means that they do filter something. I personally approve; however, where are all the anti-filtering bigots now? How is it that when this school filters it's OK, but when other institutions filter it's bad?
Gotta love the hypocracy...