IMHO, only the top 10-20% could actually perform more than a trivial refactoring with the level of competence required to sustain a maintainable design long-term under XP conditions.
To start, maybe. After practice, probably not. And after regular practice with somebody who's good at it, the percentage should be much higher. And I don't know of any methodology besides XP (excepting, perhaps, some of it's cousins) that provide the formal support for assistance and cross-training that XP does through common code ownership and madatory pair programming.
But even suppose you're right, that this is a rare skill, and one that most programmers will never be able to learn. On a team of 5-10 people, you are likely to have one of those people who can handle such a refactoring. That person will end up doing all the hard ones under XP.
My example was simply to point out that, as with more traditional approaches, at some stage XP does simply rely on the human beings to get it right, and there are clearly situations under which they don't, and an XP approach doesn't help.
I still don't quite get your point here. Is it that no method will work with sufficiently bad programmers? True, but not very interesting. Is it that some other methodology or technique is better than XP for dealing with human fallibility? If so, please let us know what it is.
Personally, I think that XP relies much less on individual perfection than other methods do. Between common code ownership, pair programming, and relentless automated testing, there's just much less chance for an idiot to screw things up. But unlike more rigid methods, XP doesn't much get in the way of high achievers.
XP hardly has a monopoly on being able to program like a human being.
Very true, but few other methods support so energetically the development of those skills that so, so many of the programmers out there seem to lack.
There is really nothing particularly "extreme" about "extreme programming". People have used the technique for decades.
That seems wrong in a few ways.
First, although I hate the name, it is quite "extreme". In my experience, compared with teams in the same industries, XP teams are extreme in: number of tests, test coverage, frequency of code changes, frequency of design changes, speed of response to requirements changes, amount of time spent coding (vs in meetings), amount of documentation, and bug counts.
The practices also avocate certain sorts of extreme behavior, including testing everything, YAGNI, continuously changing your design, aggressively polishing your code, always programming in pairs, always telling your customers the truth, never accepting a deadline that you don't have good evidence you can't meet, and always going home on time. These aren't extreme just in their pursuit of "always" and "never", but also in that many people consider them either impossible or heretical.
Certainly, there's nothing new under the sun. And many of these techniques were invented decades ago. But some of the techniques seem to be genuinely new, or at least not written about before XP. But even if these were all old techniques, the way they are put together is fundamentally different. They reinforce one another in ways that are crucial. If you try doing refactoring without doing unit tests, you will be screwed. Pair programming provides a lot of the cohesion that make things like common code ownership, minimal documentation, and aggressive refactoring work in a team environment.
Agile methods like XP are also fundamentally different than the waterfall-derived models in their pursuit of short-cycle, high-feedback iteration. They also strive to create a balance between chaos and rigidity; most other development processes only push in the direction of rigidity. (For why this is important, see something like the book Complexity.)
But don't expect a magic bullet
Amen!
People looking for magic bullets don't have the discipline to pull off XP. There are no quick fixes; the construction of good software requires skill, discipline, and patience no matter what method you use to build it. The method you pick can't provide those qualities; at best, it can reduce the chaos enough for you to improve them.
Sure the right answer is that i should rework the existing code, but the reality is that it is really hard to push a pending project on the stack, refactor some code and rework everything that uses it. In fact it is quite a risk.
If you have good tests, it's not risky at all. And good tests are fundamental to successful refactoring.
But when you discover that two projects need similar code, you basically have three paths: 1) write a good general library, 2) write some common base classes in a library and subclass in the different projects, or 3) fork the code.
For me, the decision depends on how similar the needs are between the two projects. If the designs would be pretty similar, then it's usually worth the time to do 1) or 2); going back and refactoring the old project will improve its design, too. And the more code that you share between projects, the less time you have to spend on maintenance: if a bug appears, you only have to fix it once.
The big problem however is that it does not account for programmer laziness and time constraints.
Larry Wall tells us that the three cardinal virtues of programmers are laziness, impatience, and hubris. It would be a shame to work with a methodology that doesn't support those virtues. Happily, I am a lazy man, and I love XP. The problem you describe isn't one of laziness; it's with short-term thinking and a lack of discipline.
If your tests are good, refactoring's pretty easy; you make the change you like and let your tests tell you if you've screwed anything up. (But it helps if you use an IDE with refactoring support like IntelliJ's IDEA; that takes care of all the donkey work.) If your tests aren't good, then you weren't disciplined in writing them.
If you keep things refactored and your tests are good, then adding new features is easy and low-pain. If you let your design rot and your tests don't cover anything, then adding new features takes a long time and hurts a lot. The truly lazy man will thus take the first path.
Think of it like cleaning the kitchen. The short-term lazy person will dash in, cook a meal, and leave the pans just sitting around. Next time he cooks a meal, the pans are all crusty, so it takes a long time to clean them. The master of laziness washes the dishes right away, as that is the path of minimum work.
Of course, this long-term laziness can be hard to acquire, but things like pair programming, a close team environment, and short iterations help a lot. If your partner notices your laziness right away or a team member will deal with your code next week, you're much, much less likely to write crappy code.
Without the unit testing, how the heck do you know you didn't break something?
The same way you "know" that your unit tests cover everything perfectly: you rely on the competence of your engineers.
Ah, an optimist. But one who clearly hasn't tried automated testing.
I know a lot of good programmers. My dad is a good programmer. I have been programming since I was a kid, for more than 20 years now, so I flatter myself that I am a good programmer, too. But I have never met anybody who writes real unit tests and never sets them off accidentally.
But let's grant the theoretical possibility that you are an ultragenius programmer with the memory of an elephant, the focus of a cat on the hunt, and the endurance of a robot. All relevant chunks of code are in your mind at all points. You never make mistakes, you never forget anything, and you therefore never break unit tests. You can do the most complicated refactorings without dropping a stitch, even though your project consists of thousands of classes and millions of lines of code.
But what happens when one of your (human) coworkers works on your code? What happens when you and a colleague make simultaneous and conflicting changes? What happens when a new version of a library breaks a previous feature? Will you know without automated tests? No.
I used to think that unit tests were a nice idea, but far too time consuming and painful. I was wrong. For anything except the simplest throw-away programs, XP-style test-first programming lets me produce better stuff in less time and have more fun at it.
In all the focus on passing unit tests (which are written first) and constantly refactoring, they have deliberately lessened the focus on a clean, maintainable design, and left it essentially to chance.
Eh?
Refactoring is, according to the subtitle of Martin Fowler's book, "improving the design of existing code." If you are refactoring all the time and still ending up with a sucky design, then you aren't refactoring very well.
You can look at XP as a series of tiny steps repeated over and over:
write a little test
think a little about the design of the code that the test implies
write code until the test passes
look again at the design and notice what is wrong with it
refactor until your design is good
As many programmers have discovered, you can skip testing and design, and just go for the code. Well, at least a little while. Until your code reaches critical mass,at which point you are screwed.
Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
Of course not.
I've never heard of a case nearly this bad with an XP team, although XP newbies will often blow an iteration (i.e., 1-2 weeks) on a big refactoring. This is always a sign that they haven't been doing enough refactoring as they go.
I generally diagnose this as "exessively high tolerance for ugliness and pain". On non-agile projects, one locks down a design and then just codes within that framework for months or years. The first design is never perfect, so one gets used to just hacking around a bad design, bending it to your needs.
In making the transition to XP, developers need to unlearn that behavior. About 80% of this can be solved by never, ever copying and pasting more than a couple of words. The urge to copy and paste code is almost always a sign that your design is bad. And by copying and pasting, one multiplies the ugliness. Instead you must figure out the commonality between the segments of code and abstract something beautiful.
Here they have an appraisal system designed to give the most raises to managers and manager wannabes
This is a classic mistake, and one that's all too common.
Top technical people are an order of magnitude more productive than average ones. Promoting people based mainly on management skills makes sense for management positions, but it tells the geek staff that the company prefers adequate managers to genius techies.
The best recommendation I've heard is to have parallel promotion tracks, so that you can reward your best producers without taking them away from the work they do best.
I don't think it's unreasonable to think that 25% (or more) of a large group doesn't even pull their own weight.
That's certainly true at a large company the first time you do this. But there are a few dangers to the devil-take-the-hindmost approach.
The first is a pretty obvious one: scoring actual peformance is really hard, so most places base this stuff on the appearance of performance or on opinions of your performance, often from people who aren't particularly qualified to judge (e.g., MBAs judging technical peformance). So the people you end up keeping may be the most politically skilled or the most effective bullshitters. Increasing their number may be even worse than the deadweight you had before.
A more subtle one is that if you apply this rule over and over, you will be getting rid of higher and higher quality people. (Simulate it with some random numbers to see what I mean.) That can be very wasteful, especially given the high hidden costs of turnover.
The one that worries me most, though, is that you substantially reduce incentives for internal cooperation. If I know that a third of my team is going to be fired, I have a strong disincentive to help my coworkers shine. For example, the top debugger on a team may never look good on traditional code production metrics, but he may be able to spend an hour to save his coworkers days of hunting. For those following team-oriented approaches to development (including the agile processes like XP), this will destroy the source of most of the potential productivity gains.
I strongly disagree. I would never work for a company where I had to fight for my raises. The company pays me what they think I'm worth (and what they can afford). If I disagree, then I leave.
You should work on your communication skills a little more.
I agree with the basic theory that accepting a counteroffer is risky because it could just be a temporary measure for the employer; they could well feel that they have no choice until, say, the project is done.
On the other hand, you shouldn't assume your managers are perfectly competent and perfectly aware of the current employment market. If you are feeling undervalued, there are many good ways to communicate that to your boss besides turning up and saying, "I've taken another job."
One possible solution: next time you have a performance review, bring in a copy of a salary survey. Then when your boss says you are a top-notch programmer, point out that you are being paid, given location and experience, like an average programmer, not one in the top quartile or decile.
Another approach is to give him a copy of the salary survey and say that you are worried that, say, the junior people on your team are being underpaid. Or you could tell him offhandedly that one of your college buddies just got a job with salary $X, and that you're very happy for him. Or you could tell him a little story about a friend of yours who just jumped ship from a place whose raises hadn't kept up.
They say that squeaky wheels get the oil, and this is often true, especially for the ones that squeak mildly and occasionally. Very squeaky (or very wobbly) wheels tend to get replaced. In communicating with your manager, you should leave him thinking, "Whoops! I am behind on my oiling," not, "Damn that noisy wheel! Where's my hammer?"
The only way it will work is if a small group really lay down the law as to what is and isn't going to happen.
For a large lab, this is true.
But I think this need can be mitigated as long as you a) keep the cluster small, b) charge usage fees for any resources that you can, especially printing, and c) track and publish the use of resources that it's inconvenient or silly to charge for.
I currently run a bandwidth cooperative that has a cabinet, a fat pipe, and about twenty members. For a group this size, name-and-shame fixes most problems; thus, instead of formal bandwidth quotas or charges, it may be enough to post lists of pipe usage and send out the occasional email along the lines of, "Those of you who have noticed slow web connections and full disks, please talk to Joe Bloggs and Jane Smith about their extensive music collections."
In setting up a coop, I had two big surprises:
Everybody says they are willing to help, but most people won't actually do any work unless it solves an immediate problem of theirs, or you badger them into it. Be careful not to let this turn you into an eternally nagging shrew; not only is that no fun, but people will be so used to ignoring trivial gripes that they'll never notice when you have something important to say. A few of my tricks for improving this:
Make everybody in charge of something. Then when person A complains that the trash is overflowing, point them to the list of jobs and say, "Oh, B is in charge of that; talk to him." This will involve breaking the work down into ridiculously small chunks, but it really helps to get people involved.
Accept that the group's standards will be different than yours. If you have the gumption to set this up, you will likely have strong opinions about how things will be. Most other members will not be so concerned or so emotiionally invested, and you can easily blow a gasket if you try to bend the coop to your will.
Hire people. Some tasks will be both too necessary and too burdensome for any coop member to take them on. Be wary of taking them on yourself. Instead try saying, "Hey, does anybody want to do X? Or does anybody know how to break X down into tasks that everybody will do?" When the answer is still no, then say, "Ok, we'll, then we need to hire somebody to do X, so that will go on the bills."
Some people, perfectly nice in all other ways, are not so good about paying their bills. They certainly intend to pay their bills, and will promise to pay soon, but they won't actually do it until forced. We solved this by having clear payment deadlines and then degrading service (e.g., null-routing all their bits for an increasing proportion of each hour).
If you think you might be able to make it work, I'd say that you should go for it. But start small, let it grow gradually, and spread the financial risk around. It's been a very valuable experience for me, and it's the kind of thing that a lot of future employers will love to see on your resume.
I want it to do that Ding-dong, ding-dong... Bong! Bong! Bong! Bong! Bong!... ("Hey, is it five already?") Surely this would not be hard to program but I can't find one out there.
I bought the rights to this technology and had it suppressed. Why? Because for 90% of its users, it would be "Hey, is it half-way through the movie already?"
The next phase of my plan is to make it so that the cellphone that makes noise costs $90 more than the vibrating cellphone. Then I will make it so that all car alarms immediately summon the police. Consumers will perceive this as a security feature and buy it in droves, but they will soon discover that the police, overworked and irritated, will summarily execute anybody who can't work their car alarm, which is apparently almost everybody.
Recognition for commands I could take or leave, but I want something like this guy describes. He's betting $1000 on this:
That by 2020 a wearable device will be available that will use voice recognition capability and high-volume storage to monitor and index conversations you have or conversations which occur in your vicinity for later searching as supplemental memory.
Having one would make my life so much easier, especially for dealing with clients.
Hmmm... On the one hand, the customer is, theoretically, always right. But on the other, as a professional I feel an obligation to not take a customer's money and give them garbage, even if that's what they ask for. I've turned down a number of contracts because I felt the client was clue-deficient and unwilling to listen. Sometimes that's enough to wake the clients up, but often they're quite determined to go off and waste a lotta dough.
When one does tech support, one learns to hear the real question behind the stated question, the real need behind the service requested. I think devlopers should do the same.
the 4GL stuff can't link to C and is because of that not wrappable... no idea.
Yeah, I wish the poster had told us more about what he was up to. I presume this is mainly a text/batch application, in which case even if there's no official way to link you can write a lot of screen scraping and file examination code. I've done this before and had it work adequately.
I mean: not reusing the old code and wrapping it into a modern API(CORBA or whatever) surely has a good reason.
And the reason is likely that somebody heard that Java is what everybody is using these days. If you haven't worked for a large corporation, you cannot believe the amount of money that gets spent on opinions based on zero actual knowledge. I've seen hundreded of thousands of dollars poured down sinkholes obvious to anybody on this site, and I've talked to people who have seen tens of millions vanish in similar ways. Dilbert is, if anything, optimistic.
Unfortunat[e]ly the contractor CAN'T make a regression test suit[e]!
Then they shouldn't even be trying to do the conversion. How else will they know when they are doing it right? Short answer: they won't. They took a contract like this only because they were fools or greedy.
As you say, about the best they will be able to do is some sort of 4GL->Java compiler, that treats Java as an object code format. But that is guaranteed to be about as maintainable as patching binaries. As Martin Fowler says,
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
To have this code be maintainable, a human who understands the purpose of the code will have to do much of the porting.
Personally, I'd favor the wrap-and-replace approach. Build an external Java API that is a good OO version of what the app is supposed to do. Then write a metric shitload of glue to the old code, writing unit tests and regression tests as you go. Then just start scraping out the glue and putting real code in place.
I'm not saying that [no changes to copyright law] are necessary. However, piracy is not an effective way to protest against anti fair-use laws.
Well, it's certainly one you don't like, but you haven't demonstrated that it is effective. Alcohol prohibition and the 55 MPH speed limit were both brought down mainly by widespread disregard of the law and the belated recognition that it's stupid to have laws that the majority of people don't follow. Marijuana prohibition is becoming a good example of this too, especially in other countries.
The difference here is that these people disagree with the model that is being used to fund music production, and yet they are depending on that model, and depend on others to fund it.
If I were to believe that copyrights were morally wrong (which I don't, but let's run with this a bit further), then I still wouldn't see that as hypocritical. As you later note, they could feel that they are doing their fair share to maintain the noosphere. They might be wrong, but that doesn't make them hypocritical.
Harvesting subsidies from those who support a model you don't agree with is [bad]
I'd say it depends a lot on why you do it, and especially on the ratio between your ability to contribute and the amount you contribute.
But this raises an interesting case. Major-label albums generally lose money; they make the difference up on the big hits. So if a music snob, one who dislikes the current cartel system, only buys non-hit music, he's receiving a subsidy from all those teeny-boppers. Is he morally in the wrong?
If Film88 has one copy for each simultaneous viewing, just like a rental store, then would you view it as perfectly legal?
Video stores don't rent out movies that are just out on big-screen.
In English, the word "if" is often used to introduce a hypothetical statement. That was my intention.
Most of the freeloaders have not made any sort of credible argument that this is the case. This line of argument is usually a poorly thought out rationalisation of freeloading, and IMO does not hold water.
Uh, I hate to belabor this, but you don't seem to be getting my point. I agree that most criminals can rationalize why their behavior was ok. But that doesn't make their arguments wrong in all cases; indeed, the most successful rationalizations are ones that are perfectly valid with different intentions.
As to saying you don't think it holds water, that's swell, but if you want other people to take you seriously, you've going to have to show why it doesn't hold water, not just wave your hands around. Try starting by explaining why widespread disobedience of bad laws (e.g., prohibition, the 55 MPH speed limit, Jim Crow laws) isn't an effective way to change the laws. Or explain what you think people should do to effect change in the copyright laws.
If so, it's plausible to conclude that the only way to force the necessary changes to copyright law
But this would imply that it is "necessary" to make changes to copyright law. For those who think outright abolition of copyrights is necessary ("no non-free music should exist"), it's hypocritical to depend on others to fund non-free music.
If you honestly feel that there are no changes needed to copyright law in response to the rise of the computer and the Internet, you're in a pretty small minority. The only question is which changes will happen: the ones that RIAA and the MPAA are buying right now, or the ones that the bulk of the voting public (and such wild-eyed, anti-business radicals as The Economist) think are fair.
I think the people who want to actually banish copyright are also in a pretty small minority. Most of the people who talk that way haven't thought it through; things like the GPL depend on copyright. But for those who honestly hold that view, it's still not hypocritical to depend on others to fund music production, any more than it's hypocritical of them to use Linux without contributing time or money.
Even if it's not hypocritical, it might be parasitical, but even that's not necessarily the case: if one looks at the production of creative work as a contribution to society, then they may feel they are contributing in other ways. Suppose a musician uses all open-source software to produce an album; if the Linux developers listen to that album without paying, then the relationship is clearly symbiotic.
Copyright has always been a limited and temporary right, and the size of the artificial monopoly given to creators has varied over time. The anti-copyright people just believe the proper values of those variables are, as they often have been historically, all zero. This is contrary to traditional economics, but information is not a traditional sort of good.
Personally, I just favor moderate copyright reform, but these points of view that you dismiss so casually are neither ridiculous nor specious.
These do not go so far as to remove incentive to actually purchase though. In the case of the library, or borrowing it from your friend, the item is being treated in a similar way to physical property -- the lender is temporarily without the work.
On the contrary, they often do. There are innumerable books I haven't purchased because they were available at the library. Back when I had a TV, the same applied to checking out videos.
So it doesn't undermine copyright economics any more than borrowing your friends car or renting a car hurts the car market. As for radio play, the radio stations are supposed to compensate the copyright holders.
Both bad analogies. As to the first, I belong to an outfit called City CarShare, which lets me check out a car when I need one. Their studies show that this substantially reduces the purchase of cars. And for the second, one of the major scandals right now is the massive amounts that large music corporations play to buy air time.
But your notion raises an interesting question: If Film88 has one copy for each simultaneous viewing, just like a rental store, then would you view it as perfectly legal? And if that were so, how would you feel about the industry attempts to shut down Movie88 just because it threatens their current iron grip on the distribution channels?
Let's get this straight -- illegaly copying is not "civil disobedience", it is hypocrisy.
No, hypocricy is behaving contrary to your beliefs. Illegal copying is only hypocrisy if they believe they should pay, but don't. That's not true of all of the people involved.
I'm not denying that there are a lot of pathetic freeloaders who are just boosting the music and then spouting the opinion that lets them get the most free stuff. What I'm saying is that just because some of the people spouting those beliefs are parasitic dorks doesn't mean they all are, or that the beliefs are necessarily wrong.
Setting the amoral cheapskates aside, there are a few good reasons to use P2P file sharing. One is to perform the same sort of sharing that happens in the real world. Indeed, I've been considering extending Lincoln Stein's lovely Apache::MP3 module to have explicit checkin/checkout features, just like a library. Another is to use it like a more flexible form of radio, listening to stuff to find out what you would like to buy. Note that the big music companies pay for air time precisely because they believe that it increases sales.
A third is more complex: Suppose you believe that a) the big record companies form a large, price-fixing cartel, b) that their ability to buy whatever laws they like subverts the process of democracy, and c) that the profits of the record companies have damned little to do with the compensation of the creatives that copyright law is supposed to help. If so, it's plausible to conclude that the only way to force the necessary changes to copyright law is to undermine the record company's current revenue model enough to weaken them and bring them to the negotiating table.
As I said, I haven't concluded this yet; I paid for all the music I have. But I do buy most of my stuff from small record companies and independent record stores. It would be nice to think that the media conglomerates would look within and discover a sense of public responsibility, or at least a little enlightened self-interest. But it may take millions of people saying "Hey RIAA! Blow me!" to get copyright law to reflect the realities of the digital age.
Ah, and that was condescension, which you might benefit from looking up as well. Neither that nor personal attacks, however bathetic, make your points somehow more convincing.
That Edison license is still perfectly valid, except for the price fixing, which is now illegal.
And the requirement that one can't sell it or offer it for sale? And the requirement that one can't make copies for any reason? Both are, to the best of my understanding, not part of the standard deal with records these days. Meaning that, uh, exactly none of it is applicable to a normal music purchase now. But if you know differently, please do provide a reference for our edification.
Killing isn't legal just because guns make it safe and easy and hard to track down.
But sadly, wild exaggeration to prove a point through confusion and conflation still is legal,, even though it's pretty easy to track. Is there no justice in this cold, hard world?
Re:Are you a legal man, or a moral man?
on
Live from Iran, Film88
·
· Score: 4, Insightful
Uh, that still doesn't make the forgery analogy right, other than as a scare tactic.
I agree that we should find a scheme to compensate artists fairly. But current copyright law is just a game we all agree to play, not something that Jehovah handed down. Even the current copyright laws create, "the possibility that those who sould be willing to pay the artist to obtain the work will not." Consider the library, for example. Or listening to music on the radio. Or a friend who lends you an album. All perfectly legal, and all create that possibility.
I think the current system is flawed, and I think the ability of the record companies to buy the legislation they like undermines the democratic process so severely that I could see why some people believe civil disobedience is the only route to pressuring the record companies. Personally, I pay for all my music, but the argument on the other side isn't absurd.
That aside, your reply is much more moderate than your post that I was replying to. You were asserting that there is some sort of "right to collect money from you for the privilege of seeing, reading, or hearing his work for the first time." Since you seem to have recovered from that brief seizure and now admit that there is only a temporary right to control the making of copies, it sounds like we agree on most things, and specifically that copyright law is an endlessly mutating attempt to find a fair way to compensate producers of intellectual property.
Many changes to law are proceeded by widespread disregard of a law perceived to be wrong. Take, for example, the 55 MPH national speed limit. Some who violated it were certainly dangerous drivers, but most were safe, ordinary people who recognized the silliness of the law and the impossibility of enforcing it.
I think things like Film88 and P2P sharing, whatever their current legality, are precursors to an upcoming revision of copyright laws that acknowledge the realities of cheap networking and processing power. Personally, I'd just reduce the copyright term and add some compulsory licensing akin to what songwriters have to deal with, so I'm probably not, despite your claim, paticularly radical.
Regardless, time will tell. I have on my desk a 1910 Edison cylindrical record, on which is the following license:
This record is sold by the NATIONAL PHONOGRAPH COMPANY, upon the condition that it shall not be sold to any unauthorized dealer or used for duplication and that it shall not be sold, or offered for sale, by the original or any subsequent purchaser (except ty an authorized jobber to an authorized retail dealer) for less than thirty five (35) cent apiece. UPON ANY BREACH OF SAID CONDITION, THE LICENSE TO USE AND VEND THIS RECORD, IMPLIED FROM SUCH SALE, IMMEDIATELY TERMINATES.
This now sounds archaic and ridiculous; 92 years from now, our current copyright laws are likely to sound just as weird.
he'll nick it from the factory, so nobody really loses out, and Mercedes-Benz have insurance
Insurance rates are just loss rates spread out over large groups. In the physical world, there is still a loss that is not necessarily present with information. Otherwise libaries would have been outlawed long ago for freely giving out valuable copyrighted information.
What the copyright owner is deprived of is his right to collect money from you for the privilege of seeing, reading, or hearing his work for the first time.
So what if I'm at a friend's house and he plays the album for me? If the copyright owner has the right you say, then either I or my friend is stealing. Which is it? Currently that's not enforceable, of course, but the technology to do that is only a few years off. How much should we be compelled to pay for listening to the stereo of some stranger 20 feet up the beach?
Personally, I own all my music and software. But that's not because I slavishly follow all federal laws; it's because I want the musicians and programmers to be able to earn a living doing what they love.
I have little sympathy for the surprisingly large number of whiners who believe that all things should be free because they want them to be free. But you should recognize that the law isn't something handed down on stone tablets; it's the rules of a game that we make up so that playing together is equitable and fun.
Like patent, copyright is an artificial right, recently created, so that creativity is justly rewarded. But the ability of folks like RIAA and the MPAA to buy the laws they want have little to do with rewarding creativity and a lot to do with protecting the bottom lines of giant corporations.
What's going on now is a) the belated recognition by society that those large corporations have too much power, b) the ability to track the sorts of casual duplication that has been going on for years, and c) another in a centuries-long series of renegotiations between producers and consumers of content about what "justly rewarding creativity" really means.
Your viewpoint is one that's on the far end of the spectrum of things. I'd be intrigued to find out what you think should be done to those heartless librarians who are perfectly willing to viciously loan out books, CDs, and DVDs, robbing artists of the right that you assert.
Re:Are you a legal man, or a moral man?
on
Live from Iran, Film88
·
· Score: 3, Insightful
In this example "forgery" serves the same purpose as "copyright violation".
This is a false analogy. Forgery increases the amount of money relative to the amount of goods, making everybody's money worth less. Each forged bill in effect steals a tiny amount of money from every other bill out there.
Forgery is more equivalent to spam clogging the backbones and mail servers. One spam doesn't really hurt anybody, but when they reach a substantial percentage of traffic, then they cost everyone.
I find your argument intreaguing, and it's definitely making me think, but while songs and movies are, at some level information, at another level they're creative works. Would you agree that there's a difference between informing your fellow monkeys about the tiger down by the river, and creating your own song or movie about it?
The two are intertwined, probably inextricably. Storytelling is certainly an art; when the stories are written and not about real people, we call it "literature". But telling a story about real things is just as difficult: you'd be hard-pressed to find a journalist who says that what they do isn't creative.
Or take science. In one sense Einstein just figured out some true facts about the world, just generating pure information. But I remember clearly the moment when I finally got relativity: how beatiful, how subtle! It was as stunning as being knocked on the head. He took a few loose threads and used them to turn the world inside out. Creative, surely.
In E.O. Wilson's book Consilience, he writes
The love of complexity without reductionism makes art; the love of complexity with reductionism makes science.
On this view, they are two sides of the same coin.
Slashdot Mirror
IMHO, only the top 10-20% could actually perform more than a trivial refactoring with the level of competence required to sustain a maintainable design long-term under XP conditions.
To start, maybe. After practice, probably not. And after regular practice with somebody who's good at it, the percentage should be much higher. And I don't know of any methodology besides XP (excepting, perhaps, some of it's cousins) that provide the formal support for assistance and cross-training that XP does through common code ownership and madatory pair programming.
But even suppose you're right, that this is a rare skill, and one that most programmers will never be able to learn. On a team of 5-10 people, you are likely to have one of those people who can handle such a refactoring. That person will end up doing all the hard ones under XP.
My example was simply to point out that, as with more traditional approaches, at some stage XP does simply rely on the human beings to get it right, and there are clearly situations under which they don't, and an XP approach doesn't help.
I still don't quite get your point here. Is it that no method will work with sufficiently bad programmers? True, but not very interesting. Is it that some other methodology or technique is better than XP for dealing with human fallibility? If so, please let us know what it is.
Personally, I think that XP relies much less on individual perfection than other methods do. Between common code ownership, pair programming, and relentless automated testing, there's just much less chance for an idiot to screw things up. But unlike more rigid methods, XP doesn't much get in the way of high achievers.
XP hardly has a monopoly on being able to program like a human being.
Very true, but few other methods support so energetically the development of those skills that so, so many of the programmers out there seem to lack.
There is really nothing particularly "extreme" about "extreme programming". People have used the technique for decades.
That seems wrong in a few ways.
First, although I hate the name, it is quite "extreme". In my experience, compared with teams in the same industries, XP teams are extreme in: number of tests, test coverage, frequency of code changes, frequency of design changes, speed of response to requirements changes, amount of time spent coding (vs in meetings), amount of documentation, and bug counts.
The practices also avocate certain sorts of extreme behavior, including testing everything, YAGNI, continuously changing your design, aggressively polishing your code, always programming in pairs, always telling your customers the truth, never accepting a deadline that you don't have good evidence you can't meet, and always going home on time. These aren't extreme just in their pursuit of "always" and "never", but also in that many people consider them either impossible or heretical.
Certainly, there's nothing new under the sun. And many of these techniques were invented decades ago. But some of the techniques seem to be genuinely new, or at least not written about before XP. But even if these were all old techniques, the way they are put together is fundamentally different. They reinforce one another in ways that are crucial. If you try doing refactoring without doing unit tests, you will be screwed. Pair programming provides a lot of the cohesion that make things like common code ownership, minimal documentation, and aggressive refactoring work in a team environment.
Agile methods like XP are also fundamentally different than the waterfall-derived models in their pursuit of short-cycle, high-feedback iteration. They also strive to create a balance between chaos and rigidity; most other development processes only push in the direction of rigidity. (For why this is important, see something like the book Complexity.)
But don't expect a magic bullet
Amen!
People looking for magic bullets don't have the discipline to pull off XP. There are no quick fixes; the construction of good software requires skill, discipline, and patience no matter what method you use to build it. The method you pick can't provide those qualities; at best, it can reduce the chaos enough for you to improve them.
Sure the right answer is that i should rework the existing code, but the reality is that it is really hard to push a pending project on the stack, refactor some code and rework everything that uses it. In fact it is quite a risk.
If you have good tests, it's not risky at all. And good tests are fundamental to successful refactoring.
But when you discover that two projects need similar code, you basically have three paths: 1) write a good general library, 2) write some common base classes in a library and subclass in the different projects, or 3) fork the code.
For me, the decision depends on how similar the needs are between the two projects. If the designs would be pretty similar, then it's usually worth the time to do 1) or 2); going back and refactoring the old project will improve its design, too. And the more code that you share between projects, the less time you have to spend on maintenance: if a bug appears, you only have to fix it once.
The big problem however is that it does not account for programmer laziness and time constraints.
Larry Wall tells us that the three cardinal virtues of programmers are laziness, impatience, and hubris. It would be a shame to work with a methodology that doesn't support those virtues. Happily, I am a lazy man, and I love XP. The problem you describe isn't one of laziness; it's with short-term thinking and a lack of discipline.
If your tests are good, refactoring's pretty easy; you make the change you like and let your tests tell you if you've screwed anything up. (But it helps if you use an IDE with refactoring support like IntelliJ's IDEA; that takes care of all the donkey work.) If your tests aren't good, then you weren't disciplined in writing them.
If you keep things refactored and your tests are good, then adding new features is easy and low-pain. If you let your design rot and your tests don't cover anything, then adding new features takes a long time and hurts a lot. The truly lazy man will thus take the first path.
Think of it like cleaning the kitchen. The short-term lazy person will dash in, cook a meal, and leave the pans just sitting around. Next time he cooks a meal, the pans are all crusty, so it takes a long time to clean them. The master of laziness washes the dishes right away, as that is the path of minimum work.
Of course, this long-term laziness can be hard to acquire, but things like pair programming, a close team environment, and short iterations help a lot. If your partner notices your laziness right away or a team member will deal with your code next week, you're much, much less likely to write crappy code.
The same way you "know" that your unit tests cover everything perfectly: you rely on the competence of your engineers.
Ah, an optimist. But one who clearly hasn't tried automated testing.
I know a lot of good programmers. My dad is a good programmer. I have been programming since I was a kid, for more than 20 years now, so I flatter myself that I am a good programmer, too. But I have never met anybody who writes real unit tests and never sets them off accidentally.
But let's grant the theoretical possibility that you are an ultragenius programmer with the memory of an elephant, the focus of a cat on the hunt, and the endurance of a robot. All relevant chunks of code are in your mind at all points. You never make mistakes, you never forget anything, and you therefore never break unit tests. You can do the most complicated refactorings without dropping a stitch, even though your project consists of thousands of classes and millions of lines of code.
But what happens when one of your (human) coworkers works on your code? What happens when you and a colleague make simultaneous and conflicting changes? What happens when a new version of a library breaks a previous feature? Will you know without automated tests? No.
I used to think that unit tests were a nice idea, but far too time consuming and painful. I was wrong. For anything except the simplest throw-away programs, XP-style test-first programming lets me produce better stuff in less time and have more fun at it.
Eh?
Refactoring is, according to the subtitle of Martin Fowler's book, "improving the design of existing code." If you are refactoring all the time and still ending up with a sucky design, then you aren't refactoring very well.
You can look at XP as a series of tiny steps repeated over and over:
- write a little test
- think a little about the design of the code that the test implies
- write code until the test passes
- look again at the design and notice what is wrong with it
- refactor until your design is good
As many programmers have discovered, you can skip testing and design, and just go for the code. Well, at least a little while. Until your code reaches critical mass,at which point you are screwed.Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
Of course not.
I've never heard of a case nearly this bad with an XP team, although XP newbies will often blow an iteration (i.e., 1-2 weeks) on a big refactoring. This is always a sign that they haven't been doing enough refactoring as they go.
I generally diagnose this as "exessively high tolerance for ugliness and pain". On non-agile projects, one locks down a design and then just codes within that framework for months or years. The first design is never perfect, so one gets used to just hacking around a bad design, bending it to your needs.
In making the transition to XP, developers need to unlearn that behavior. About 80% of this can be solved by never, ever copying and pasting more than a couple of words. The urge to copy and paste code is almost always a sign that your design is bad. And by copying and pasting, one multiplies the ugliness. Instead you must figure out the commonality between the segments of code and abstract something beautiful.
Here they have an appraisal system designed to give the most raises to managers and manager wannabes
This is a classic mistake, and one that's all too common.
Top technical people are an order of magnitude more productive than average ones. Promoting people based mainly on management skills makes sense for management positions, but it tells the geek staff that the company prefers adequate managers to genius techies.
The best recommendation I've heard is to have parallel promotion tracks, so that you can reward your best producers without taking them away from the work they do best.
I don't think it's unreasonable to think that 25% (or more) of a large group doesn't even pull their own weight.
That's certainly true at a large company the first time you do this. But there are a few dangers to the devil-take-the-hindmost approach.
The first is a pretty obvious one: scoring actual peformance is really hard, so most places base this stuff on the appearance of performance or on opinions of your performance, often from people who aren't particularly qualified to judge (e.g., MBAs judging technical peformance). So the people you end up keeping may be the most politically skilled or the most effective bullshitters. Increasing their number may be even worse than the deadweight you had before.
A more subtle one is that if you apply this rule over and over, you will be getting rid of higher and higher quality people. (Simulate it with some random numbers to see what I mean.) That can be very wasteful, especially given the high hidden costs of turnover.
The one that worries me most, though, is that you substantially reduce incentives for internal cooperation. If I know that a third of my team is going to be fired, I have a strong disincentive to help my coworkers shine. For example, the top debugger on a team may never look good on traditional code production metrics, but he may be able to spend an hour to save his coworkers days of hunting. For those following team-oriented approaches to development (including the agile processes like XP), this will destroy the source of most of the potential productivity gains.
I strongly disagree. I would never work for a company where I had to fight for my raises. The company pays me what they think I'm worth (and what they can afford). If I disagree, then I leave.
You should work on your communication skills a little more.
I agree with the basic theory that accepting a counteroffer is risky because it could just be a temporary measure for the employer; they could well feel that they have no choice until, say, the project is done.
On the other hand, you shouldn't assume your managers are perfectly competent and perfectly aware of the current employment market. If you are feeling undervalued, there are many good ways to communicate that to your boss besides turning up and saying, "I've taken another job."
One possible solution: next time you have a performance review, bring in a copy of a salary survey. Then when your boss says you are a top-notch programmer, point out that you are being paid, given location and experience, like an average programmer, not one in the top quartile or decile.
Another approach is to give him a copy of the salary survey and say that you are worried that, say, the junior people on your team are being underpaid. Or you could tell him offhandedly that one of your college buddies just got a job with salary $X, and that you're very happy for him. Or you could tell him a little story about a friend of yours who just jumped ship from a place whose raises hadn't kept up.
They say that squeaky wheels get the oil, and this is often true, especially for the ones that squeak mildly and occasionally. Very squeaky (or very wobbly) wheels tend to get replaced. In communicating with your manager, you should leave him thinking, "Whoops! I am behind on my oiling," not, "Damn that noisy wheel! Where's my hammer?"
For a large lab, this is true.
But I think this need can be mitigated as long as you a) keep the cluster small, b) charge usage fees for any resources that you can, especially printing, and c) track and publish the use of resources that it's inconvenient or silly to charge for.
I currently run a bandwidth cooperative that has a cabinet, a fat pipe, and about twenty members. For a group this size, name-and-shame fixes most problems; thus, instead of formal bandwidth quotas or charges, it may be enough to post lists of pipe usage and send out the occasional email along the lines of, "Those of you who have noticed slow web connections and full disks, please talk to Joe Bloggs and Jane Smith about their extensive music collections."
In setting up a coop, I had two big surprises:
If you think you might be able to make it work, I'd say that you should go for it. But start small, let it grow gradually, and spread the financial risk around. It's been a very valuable experience for me, and it's the kind of thing that a lot of future employers will love to see on your resume.
I want it to do that Ding-dong, ding-dong... Bong! Bong! Bong! Bong! Bong! ... ("Hey, is it five already?") Surely this would not be hard to program but I can't find one out there.
I bought the rights to this technology and had it suppressed. Why? Because for 90% of its users, it would be "Hey, is it half-way through the movie already?"
The next phase of my plan is to make it so that the cellphone that makes noise costs $90 more than the vibrating cellphone. Then I will make it so that all car alarms immediately summon the police. Consumers will perceive this as a security feature and buy it in droves, but they will soon discover that the police, overworked and irritated, will summarily execute anybody who can't work their car alarm, which is apparently almost everybody.
But the customer asked for that.
Hmmm... On the one hand, the customer is, theoretically, always right. But on the other, as a professional I feel an obligation to not take a customer's money and give them garbage, even if that's what they ask for. I've turned down a number of contracts because I felt the client was clue-deficient and unwilling to listen. Sometimes that's enough to wake the clients up, but often they're quite determined to go off and waste a lotta dough.
When one does tech support, one learns to hear the real question behind the stated question, the real need behind the service requested. I think devlopers should do the same.
the 4GL stuff can't link to C and is because of that not wrappable... no idea.
Yeah, I wish the poster had told us more about what he was up to. I presume this is mainly a text/batch application, in which case even if there's no official way to link you can write a lot of screen scraping and file examination code. I've done this before and had it work adequately.
I'd go to a local meeting of Slashdotters Older Than Average.
That's no fun; if the age restriction is only 16 and up, we couldn't even meet at a bar.
And the reason is likely that somebody heard that Java is what everybody is using these days. If you haven't worked for a large corporation, you cannot believe the amount of money that gets spent on opinions based on zero actual knowledge. I've seen hundreded of thousands of dollars poured down sinkholes obvious to anybody on this site, and I've talked to people who have seen tens of millions vanish in similar ways. Dilbert is, if anything, optimistic.
Unfortunat[e]ly the contractor CAN'T make a regression test suit[e]!
Then they shouldn't even be trying to do the conversion. How else will they know when they are doing it right? Short answer: they won't. They took a contract like this only because they were fools or greedy.
As you say, about the best they will be able to do is some sort of 4GL->Java compiler, that treats Java as an object code format. But that is guaranteed to be about as maintainable as patching binaries. As Martin Fowler says, To have this code be maintainable, a human who understands the purpose of the code will have to do much of the porting.
Personally, I'd favor the wrap-and-replace approach. Build an external Java API that is a good OO version of what the app is supposed to do. Then write a metric shitload of glue to the old code, writing unit tests and regression tests as you go. Then just start scraping out the glue and putting real code in place.
I'm not saying that [no changes to copyright law] are necessary. However, piracy is not an effective way to protest against anti fair-use laws.
Well, it's certainly one you don't like, but you haven't demonstrated that it is effective. Alcohol prohibition and the 55 MPH speed limit were both brought down mainly by widespread disregard of the law and the belated recognition that it's stupid to have laws that the majority of people don't follow. Marijuana prohibition is becoming a good example of this too, especially in other countries.
The difference here is that these people disagree with the model that is being used to fund music production, and yet they are depending on that model, and depend on others to fund it.
If I were to believe that copyrights were morally wrong (which I don't, but let's run with this a bit further), then I still wouldn't see that as hypocritical. As you later note, they could feel that they are doing their fair share to maintain the noosphere. They might be wrong, but that doesn't make them hypocritical.
Harvesting subsidies from those who support a model you don't agree with is [bad]
I'd say it depends a lot on why you do it, and especially on the ratio between your ability to contribute and the amount you contribute.
But this raises an interesting case. Major-label albums generally lose money; they make the difference up on the big hits. So if a music snob, one who dislikes the current cartel system, only buys non-hit music, he's receiving a subsidy from all those teeny-boppers. Is he morally in the wrong?
In English, the word "if" is often used to introduce a hypothetical statement. That was my intention.
Most of the freeloaders have not made any sort of credible argument that this is the case. This line of argument is usually a poorly thought out rationalisation of freeloading, and IMO does not hold water.
Uh, I hate to belabor this, but you don't seem to be getting my point. I agree that most criminals can rationalize why their behavior was ok. But that doesn't make their arguments wrong in all cases; indeed, the most successful rationalizations are ones that are perfectly valid with different intentions.
As to saying you don't think it holds water, that's swell, but if you want other people to take you seriously, you've going to have to show why it doesn't hold water, not just wave your hands around. Try starting by explaining why widespread disobedience of bad laws (e.g., prohibition, the 55 MPH speed limit, Jim Crow laws) isn't an effective way to change the laws. Or explain what you think people should do to effect change in the copyright laws.
But this would imply that it is "necessary" to make changes to copyright law. For those who think outright abolition of copyrights is necessary ("no non-free music should exist"), it's hypocritical to depend on others to fund non-free music.
If you honestly feel that there are no changes needed to copyright law in response to the rise of the computer and the Internet, you're in a pretty small minority. The only question is which changes will happen: the ones that RIAA and the MPAA are buying right now, or the ones that the bulk of the voting public (and such wild-eyed, anti-business radicals as The Economist) think are fair.
I think the people who want to actually banish copyright are also in a pretty small minority. Most of the people who talk that way haven't thought it through; things like the GPL depend on copyright. But for those who honestly hold that view, it's still not hypocritical to depend on others to fund music production, any more than it's hypocritical of them to use Linux without contributing time or money.
Even if it's not hypocritical, it might be parasitical, but even that's not necessarily the case: if one looks at the production of creative work as a contribution to society, then they may feel they are contributing in other ways. Suppose a musician uses all open-source software to produce an album; if the Linux developers listen to that album without paying, then the relationship is clearly symbiotic.
Copyright has always been a limited and temporary right, and the size of the artificial monopoly given to creators has varied over time. The anti-copyright people just believe the proper values of those variables are, as they often have been historically, all zero. This is contrary to traditional economics, but information is not a traditional sort of good.
Personally, I just favor moderate copyright reform, but these points of view that you dismiss so casually are neither ridiculous nor specious.
These do not go so far as to remove incentive to actually purchase though. In the case of the library, or borrowing it from your friend, the item is being treated in a similar way to physical property -- the lender is temporarily without the work.
On the contrary, they often do. There are innumerable books I haven't purchased because they were available at the library. Back when I had a TV, the same applied to checking out videos.
So it doesn't undermine copyright economics any more than borrowing your friends car or renting a car hurts the car market. As for radio play, the radio stations are supposed to compensate the copyright holders.
Both bad analogies. As to the first, I belong to an outfit called City CarShare, which lets me check out a car when I need one. Their studies show that this substantially reduces the purchase of cars. And for the second, one of the major scandals right now is the massive amounts that large music corporations play to buy air time.
But your notion raises an interesting question: If Film88 has one copy for each simultaneous viewing, just like a rental store, then would you view it as perfectly legal? And if that were so, how would you feel about the industry attempts to shut down Movie88 just because it threatens their current iron grip on the distribution channels?
Let's get this straight -- illegaly copying is not "civil disobedience", it is hypocrisy.
No, hypocricy is behaving contrary to your beliefs. Illegal copying is only hypocrisy if they believe they should pay, but don't. That's not true of all of the people involved.
I'm not denying that there are a lot of pathetic freeloaders who are just boosting the music and then spouting the opinion that lets them get the most free stuff. What I'm saying is that just because some of the people spouting those beliefs are parasitic dorks doesn't mean they all are, or that the beliefs are necessarily wrong.
Setting the amoral cheapskates aside, there are a few good reasons to use P2P file sharing. One is to perform the same sort of sharing that happens in the real world. Indeed, I've been considering extending Lincoln Stein's lovely Apache::MP3 module to have explicit checkin/checkout features, just like a library. Another is to use it like a more flexible form of radio, listening to stuff to find out what you would like to buy. Note that the big music companies pay for air time precisely because they believe that it increases sales.
A third is more complex: Suppose you believe that a) the big record companies form a large, price-fixing cartel, b) that their ability to buy whatever laws they like subverts the process of democracy, and c) that the profits of the record companies have damned little to do with the compensation of the creatives that copyright law is supposed to help. If so, it's plausible to conclude that the only way to force the necessary changes to copyright law is to undermine the record company's current revenue model enough to weaken them and bring them to the negotiating table.
As I said, I haven't concluded this yet; I paid for all the music I have. But I do buy most of my stuff from small record companies and independent record stores. It would be nice to think that the media conglomerates would look within and discover a sense of public responsibility, or at least a little enlightened self-interest. But it may take millions of people saying "Hey RIAA! Blow me!" to get copyright law to reflect the realities of the digital age.
The pencil-neck remark was bathos. (Look it up.)
Ah, and that was condescension, which you might benefit from looking up as well. Neither that nor personal attacks, however bathetic, make your points somehow more convincing.
That Edison license is still perfectly valid, except for the price fixing, which is now illegal.
And the requirement that one can't sell it or offer it for sale? And the requirement that one can't make copies for any reason? Both are, to the best of my understanding, not part of the standard deal with records these days. Meaning that, uh, exactly none of it is applicable to a normal music purchase now. But if you know differently, please do provide a reference for our edification.
Killing isn't legal just because guns make it safe and easy and hard to track down.
But sadly, wild exaggeration to prove a point through confusion and conflation still is legal,, even though it's pretty easy to track. Is there no justice in this cold, hard world?
Uh, that still doesn't make the forgery analogy right, other than as a scare tactic.
I agree that we should find a scheme to compensate artists fairly. But current copyright law is just a game we all agree to play, not something that Jehovah handed down. Even the current copyright laws create, "the possibility that those who sould be willing to pay the artist to obtain the work will not." Consider the library, for example. Or listening to music on the radio. Or a friend who lends you an album. All perfectly legal, and all create that possibility.
I think the current system is flawed, and I think the ability of the record companies to buy the legislation they like undermines the democratic process so severely that I could see why some people believe civil disobedience is the only route to pressuring the record companies. Personally, I pay for all my music, but the argument on the other side isn't absurd.
That aside, your reply is much more moderate than your post that I was replying to. You were asserting that there is some sort of "right to collect money from you for the privilege of seeing, reading, or hearing his work for the first time." Since you seem to have recovered from that brief seizure and now admit that there is only a temporary right to control the making of copies, it sounds like we agree on most things, and specifically that copyright law is an endlessly mutating attempt to find a fair way to compensate producers of intellectual property.
Many changes to law are proceeded by widespread disregard of a law perceived to be wrong. Take, for example, the 55 MPH national speed limit. Some who violated it were certainly dangerous drivers, but most were safe, ordinary people who recognized the silliness of the law and the impossibility of enforcing it.
I think things like Film88 and P2P sharing, whatever their current legality, are precursors to an upcoming revision of copyright laws that acknowledge the realities of cheap networking and processing power. Personally, I'd just reduce the copyright term and add some compulsory licensing akin to what songwriters have to deal with, so I'm probably not, despite your claim, paticularly radical.
Regardless, time will tell. I have on my desk a 1910 Edison cylindrical record, on which is the following license: This now sounds archaic and ridiculous; 92 years from now, our current copyright laws are likely to sound just as weird.
he'll nick it from the factory, so nobody really loses out, and Mercedes-Benz have insurance
Insurance rates are just loss rates spread out over large groups. In the physical world, there is still a loss that is not necessarily present with information. Otherwise libaries would have been outlawed long ago for freely giving out valuable copyrighted information.
Nice try, though.
What the copyright owner is deprived of is his right to collect money from you for the privilege of seeing, reading, or hearing his work for the first time.
So what if I'm at a friend's house and he plays the album for me? If the copyright owner has the right you say, then either I or my friend is stealing. Which is it? Currently that's not enforceable, of course, but the technology to do that is only a few years off. How much should we be compelled to pay for listening to the stereo of some stranger 20 feet up the beach?
Personally, I own all my music and software. But that's not because I slavishly follow all federal laws; it's because I want the musicians and programmers to be able to earn a living doing what they love.
I have little sympathy for the surprisingly large number of whiners who believe that all things should be free because they want them to be free. But you should recognize that the law isn't something handed down on stone tablets; it's the rules of a game that we make up so that playing together is equitable and fun.
Like patent, copyright is an artificial right, recently created, so that creativity is justly rewarded. But the ability of folks like RIAA and the MPAA to buy the laws they want have little to do with rewarding creativity and a lot to do with protecting the bottom lines of giant corporations.
What's going on now is a) the belated recognition by society that those large corporations have too much power, b) the ability to track the sorts of casual duplication that has been going on for years, and c) another in a centuries-long series of renegotiations between producers and consumers of content about what "justly rewarding creativity" really means.
Your viewpoint is one that's on the far end of the spectrum of things. I'd be intrigued to find out what you think should be done to those heartless librarians who are perfectly willing to viciously loan out books, CDs, and DVDs, robbing artists of the right that you assert.
In this example "forgery" serves the same purpose as "copyright violation".
This is a false analogy. Forgery increases the amount of money relative to the amount of goods, making everybody's money worth less. Each forged bill in effect steals a tiny amount of money from every other bill out there.
Forgery is more equivalent to spam clogging the backbones and mail servers. One spam doesn't really hurt anybody, but when they reach a substantial percentage of traffic, then they cost everyone.
The two are intertwined, probably inextricably. Storytelling is certainly an art; when the stories are written and not about real people, we call it "literature". But telling a story about real things is just as difficult: you'd be hard-pressed to find a journalist who says that what they do isn't creative.
Or take science. In one sense Einstein just figured out some true facts about the world, just generating pure information. But I remember clearly the moment when I finally got relativity: how beatiful, how subtle! It was as stunning as being knocked on the head. He took a few loose threads and used them to turn the world inside out. Creative, surely.
In E.O. Wilson's book Consilience, he writes On this view, they are two sides of the same coin.