There are aspects that can be evolved, and some that can't.
And which would those be?
And can you prove that they're impossible to change? Or are you only saying that you don't know how to change them and that you doubt anybody else knows either?
"Quick & Dirty" is not necessarily the opposite of doing things properly.
Agreed. A short-cycle iterative process is quick, but it need not be dirty. If you pick something disciplined, like XP, it will be very clean.
If you can deliver new features every week without compromising on quality (and an XP team can indeed do that), then that may make your bosses just as happy. Especially if you do the ones with the highest business value first. As I mention elsewhere in this thread, it makes mine even happier than under classic methods.
The most important of which is that it does not recognize the need for architectural design.
Wrong!
XP practitioners feel that architecture is so important that we don't let an hour go by without thinking of it. We change the design as we go to suit the current code base. It's called refactoring.
Doing XP, the designs of my programs are much, much better than they used to be. And it's faster. Much faster.
That's for three big reasons.
When you do all your architecture up front, there's a lot of head-scratching and puzzlement; you have to make a lot of guesses about the future, and those are scary and hard. If you wait until you're the problem comes to the fore, it's generally pretty easy; you have a lot hard data and actual experience, so the solutions come quickly.
Another is that if you only do your architecture in phases, during the time between phases, the factors that guided your architecture will evolve. By the time you reach the beginning of the next architecture phase, the current architecture is out of date. You then have to do a lot of work to get to the new architecture. That's like waiting until every dish in the kitchen is dirty before washing any; rather than scraping off dried gunk, it's easier if you just wash them as you go.
The third is that you don't have to over-generalize up front. With XP, you write only the code you need today. Tomorrow, if an object is insufficiently general for a new feature, you can add the generality then. Unless you are a 100% perfect guesser, reduced speculative work means reduced waste.
It sounds crazy and takes a bit of practice, but it works stupendously well
Do not take the logical step and attempt to become a disciple of XP. You will either find yourself doing some of the stupidest things imaginable, or you will go insane.
Personally, I don't think anybody should be a disciple of anything.
But XP works for me, and I know quite a number of other people who it works for. Just yesterday I was pulled in a meeting at one of my clients; the CEO wanted to tell their two biggest investors how well it was working for them, and she wanted me to explain it to them.
She's excited because we're delivering solid software with very low bug counts. We give them new versions every week. They can see the software progressing. And they love the fact that they can completely change what's on the schedule for next week or next month without a peep from us.
If you've heard of XP and think it's a good idea, do not make the mistake of reading anything about it.
Sounds like you're looking for some disciples yourself!
This is one reason why we as a society need to find ways to get rid of this need for greed and wealth and money in general. Otherwise things just keep running into the ground.
Don't be silly.
Suppose we find some magic way to get rid of money and the need for it. Anybody who still programs does it either because a) it entertains them, or b) it benefits someone. If it's for entertainment, fine, they can make whatever they please. But if it benefits someone, then the programmer always has to face the tradeoff of benefiting them some right away or benefiting them more later.
Imagine, for example, that you've got a five-year grant writing educational software. You have no pressure to deliver anything, so you could wait until the fifth year to deliver something fantastic. Or you could push something quick and dirty out right away and educate five years worth of kids that would otherwise miss out. A programmer who is doing something that matters should always feel time pressure, even if it's only self-imposed.
Yeah, they seem pretty much invulnerable. We used a bunch of them for an art project in the Black Rock Desert. I have pictures of me coding away during a dust storm. The laptops all survived happily.
Ok, to bring another level to it. Why is running an unknown executable dangerous?
It's pretty safe running unknown Java Applets in our browsers these days, barring the occasional VM bug. Why can't we run random executables without worrying that they'll delete everything/spam/etc.
Why the assumption that running a random executable is dangerous?
Defining what an app is allowed to do is pretty tricky. That's especially true if you want to be able to bubble up decisions to the user.
Suppose that somebody sends you an applet that nominally shows, say, the latest sports scores, but in really cool way. When you run it, how can a security manager tell the difference between a legitimate hit to a web site to get the data and an illegitimate one to send out spams? And what questions can it ask of a novice user where the user will make the right decision?
The issue is made a lot worse by the crappiness of many user interfaces. There are an awful lot of programs that put up stupid, confusing, or useless dialog boxes; people are generally in the habit of clicking "ok" just to get on with things.
It's their right to send it to you, it's your right to block it.
By the same theory, it's my right to stand outside your house at 3 am and shout through a megaphone, right? After all, it's your right to brick up your windows and install more soundproofing.
You are misunderstanding the situation, I think. Were I to say, "In the natural world, we find some phenomena P; ergo we should live our lives with the assumption that P is good, because P occurs in the natural world", I would be following the line of logic referred to as the Naturalistic Fallacy. In short, the NF is deriving what ought to be from what is, as you point out.
However, I am making no claims about the natural world and deriving moral value from it. My claim is that life is a zero sum game: you are born, you die. The universe expands, it contracts. That's it -- there is no moral value being assigned whatsoever.
As any programmer can tell you, assigning a value of zero is still assigning a value. You are saying that because of certain facts about the natural the world, people shouldn't get worked up about spam. You're taking an is, with which I agree, and asserting an ought, with which I don't. You're welcome to call that whatever you like; I'd call the naturalistic fallacy, but please call it bacon (either Sir Francis or hickory-smoked) if it suits you.
Either way, perhaps you can drop the waffle about the universe, and just say that you don't think human life has any value. Then I can say, "well I do, and so do most voters and lawmakers" and we can move on.
I think your interpretation is that an absence of moral valuation is tantamount to assigning moral value. I disagree. It's a line of reasoning on par with saying, "atheism is a belief!"
Atheism, defined as disbelief in or denial of existence of God or gods is indeed a belief, by which I mean a unproved assertion about the nature of reality. So yes, it's the same line of argument. Unless, of course, you have some proof of the nonexistence of God, in which case you should really write a book about it.
Condescending comments about Google aside, the responsibility of backing one's facts up is left to the person making use of them.
Communication is a two-way street. These studies are well known to people who study the issue; I was hinting that maybe you should do a little more research before holding forth, or at least before demanding that I do the work for you. Since you couldn't quite manage, I did indeed back the facts up.
Looking at the ones that you provided, my argument is not swayed: bandwidth is a questionable cost, generally set at what the market can bear rather than the actual cost of delivery.
Uh, all costs are set by what the market can bear. That's how capitalism works. Bandwidth might be a questionable cost to somebody who doesn't pay a bandwidth bill. But for those of us who do, it's a real cost.
"Wasted time" is a convinient shock value technique, but it's also questionable. *You* decided to use email; your time was not stolen from you.
Given that I started using email before spammers started spamming, it seems pretty weird to say that I chose to be spammed.
But I guess your rule would apply to telephone solicitations, too. Would that make you opposed to the do-not-call registry currently being implemented?
And heck, running with your theory, it seems that kidnapping shouldn't be a crime, either. Or harrassment. After all, it's only time and bother, and with sufficient effort people can choose to isolate themselves from those risks.
The "projections" of doom and gloom from a company [...] are suspect at best; I am not at all convinced that spam is going to "overwhelm email".
Spam is circa 50% of email, and growing rapidly. Brightmail has made no projections that I am aware of, but they don't have to; there's no reason to expect that the trend will change on its own.
if you want to use the medium, you have to expect that there is some noise to the signal.
There are two things wrong with this. One is the comparison with analog communication, where the signal/noise stuff comes from. It's
If you want to criticize my understanding of philosophy, get yours right first.
I quote Frans de Waal, from Good Natured: the origins of Right and Wrong in Humans and Other Animals:
Known as the naturalistic fallacy, the problem of deriving norms from nature is very old indeed. It has to do with the impossibility of translating 'is' language (how things are) into 'ought' language (how things ought to be).
You asserted that life is "inherently meaningless", a proposition with which I agree; it's all just molecules bumping around. But that doesn't mean anything about how we should act. By suggesting otherwise, you are making a classic philosophical mistake.
Spam is not a "major societal problem." Hunger, AIDS, and the abuse of our civil liberties are examples of major societal problems.
It depends on how you look at it. Spam is threatening to overwhelm email; left unchecked, it will. The Internet, and related distributed media like SMS, shift political power substantially back towards ordinary people, as demonstrated both by anti-war organizing in the US and the troubles these media are giving repressive goverments around the world.
Spammers threaten that democratic shift by their increasing ability ability to drown out real communication, which is already causing marginal internet users to abandon email altogether. Worse, we are inviting governments to get involved in regulating something that, spammers aside, was largely self-regulating. This is unlikely to help civil liberties.
Certainly, spam is not as big a deal as AIDS, but the resources spent on dealing with the two turn out to be in the same ballpark. Just this week, the UN reported that total AIDS spending this year in low- and middle-income countries will total $4.7 billion. By 2005, they expect to need about twice that.
By forcing people to waste billions of dollars (and vast amounts of personal and governmental attention) on spam, the spammers are consuming resources that could be put to productive use, like plugging that gap in AIDS funding.
Undocumented claims of cost are not impressive
Sorry, I thought you had heard about Google. But let me help you out. In early 2001, in The European Commission estimated the direct costs of spam to be circa 10 billion euros ($11.6 billion) per year, not counting the value of time of the recipients. Ferris Research comes up with a similar number for 2003 just for costs to US corporations. A writer for the Guardian, trying to include the value of the wasted time, makes an off-the-cuff estimate of $100 billion.
I don't buy the higher number, but it's hard to dispute that the direct costs for spam are in the billions. And if putting CEOs in jail for wasting billions in order to steal millions seems fair, then doing the same to spammers seems only proportionate.
Repeat after me: your life, just like mine and most everyone else's, is inherently meaningless.
Hi! Philosophers know this as the naturalistic fallacy. The way the world is implies nothing about the way we should choose to make it. You are welcome to choose a zero value for human life. I pick bigger ones, as do most people.
Spam is annoying. Spam is nothing more than that -- it does not deserve "hard jail time".
No, Britney Spears is annoying. Spam is a major societal problem.
From the estimates I've seen, the worldwide cost of spam is$10-$50 billion/year, and it's still growing unchecked. As this article suggests, it seems to be moving from the control of low-lifes to outright criminals. I guess that's not surprising, given how much of the stuff advertised via spam is either fraudulent or illegal.
When you compare the costs of spam to some of the recent large business bankruptcies, it's clear that spam in in the same league. People are clamoring for jail time for the recent set of CEOs/con-men; why shouldn't spammers, who cause a similarly big problem, face similarly big sentences?
Paypal donations to hi-tech hit squads, a la Tom Clancy and his Mr. Clark, to track down and eliminate, with EXTREME prejudice, any and all spammers, anywhere in the world.
There's a problem with knowing who to pay. Of ourse, you only want to pay for results, so some neutral third party should collect the cash and hold the bounties.
But once the spammer is dead, how do you know who to pay? And remember, if you pay the wrong person, then there will be a disgruntled contract killer out there!
Fuck praise and acknowledgement, fuck them in their stupid asses. Show me the money, and stop making me work 'till midnight on Friday.
Hi! You are on the fast road to burnout. In my experience, if you don't change things so that you are happy enough that you can start recovering the enjoyment you used to find in your work, you will end up hating utterly both the work and the job, so much so that even years later the thought of doing the work will make your stomach lurch like biting into rotten meat.
It sounds like you feel like you are doing far more than they are paying you for. Bring that back into balance. The right way depends on the situation, but do it pronto or you'll end up quitting in a huff or getting fired for being surly.
If you want to know more, ask here or drop me a private email.
Q. I feel inadequate, I have thousands of users asking for features, but I can't deliver _and_ keep my family fed. -- Frantic, IL
A great answer to this problem is to learn how to say, "Patches welcome!" and mean it. The fact that a lot of other people want something does not mean that you must work on it.
Some people of course then say, "But I can't write code!" The proper response to that is, "Would you like to hire me to work on it?" Or possibly, "Perhaps other people want the same thing. See if you can get together enough contributions to pay for it."
The Buddhists teach that desire is infinite. That accords with my own experience: what people really want is to have everything, for free, right now. An important trick for every programmer to learn is to let other people do the work of managing their own desires. For example, I have learned to never ask a client if they want a feature, or when they want a feature. Instead, I ask them what the most important feature is, and I work on that one first. When it's done, I ask them what the next most important feature is.
In addition to all of this, what the fuck does the programmers opinion of the customers even matter?
With every line of code a programmer writes, he is affecting the customer, directly or indirectly. (If he isn't, then why have that line of code?) To build good, usable systems, you must have sympathy for and understanding of the users.
If I had somebody on my team who hated the customers or had a lot of contempt for them, I'd get 'em out of there, pronto. That attitude is contagious. To my mind, that's because it's lazy; tearing down is always easier than building up.
To them I say, work in the tech sector for the last 10 years and try to not turn out even MORE sarcastic/pessimistic then I.
I have worked in the tech sector for longer. I still do it because I like it, and I've found ways to make it sane and enjoyable. That's not to say it is a bed of roses, or that it's always fun, but I do good work that I'm proud of, and have fun along the way.
Many household devices today use more power when their state is changed than they would if they were just left on constantly.
Go get yourself a meter like the WattsUp and gather some stats. In my experience, for computers there is an initial power surge that is maybe 2-3x normal draw, and lasts anywhere from 20 seconds to a couple of minutes. So worst case, if you will be turning your computer on again within 6 minutes, you probably should leave it on. Otherwise, turning it off will save power.
For screens, it's more complicated; CRTs draw more while warming up, but only for 15 seconds or so. But they draw less when showing a fully black screen, and different resolutions draw different amounts. Also, modern CRTs have assorted sleep modes. So whether or not to turn off a CRT depends on your usage patterns. For LCDs, I have no data.
I was also interested to note that high CPU usage produces measurable extra power usage. On a dual-processor P3/733 system, each processor pulls an extra 10 watts under load. So it turns out that things like SetiAtHome aren't free.
My mother, for instance, wastes more power than she saves by going around turning off all her fluorescent lights.
A common misconception, but not true. See this article for the details. They recommend leaving them on if you'll need them again within 15 minutes. But this isn't because of power usage; it's because turning them off and on too often reduces bulb life.
Aren't LCD monitors designed in the same way? They only use power when they are updated?
You'll note that in a dark room, you can see the LCD just fine. This means that it's producing light, which takes power. According to this week's Economist, "an LCD is only 10-15% efficient at converting energy from its power source into a readable image."
it looks like it included ROM images. That'd probably be why the DMCA was invoked.
That could well be; it looks like the wayback machine hasn't cached the pages involved. But some ROM copies are legal and encouraged; I own an Addams' Family machine, and the manufacturer posted ROM updates on their web site for it. Anybody know what was actually there?
I'd wager that an afternoon spent perusing books on small claims and how to collect would give you all the information you need.
Yes, but then none of us would know the scoop. Plus, fellow geeks who have been through it may provide advice that wouldn't turn up in an afternoon at the library.
That's not to say people shouldn't do their own research, of course. But when I'm reading in the "Ask Slashdot" section, I think questions like this are great.
I wonder how common it is that programmers come to hate programming or even computers in general.
I've felt that at times. For me, it was always about the work and the work environment.
Years ago, I was a sysadmin, mainly because that was the work available. But in working 70-hour weeks for a couple of financial companies, I completely burned out on it. Even now, if I have to do more than a couple of hours of it, I get immensely surly.
So I switched to full-time development, which was what I preferred. For a while, that was great, too, but after a couple of death-march projects I was getting burned out on that, too. It made me sad; I really like programming, but forcing myself to program for 60 hours a week for unappreciative jerks was somehow taking the fun out of it.:-)
Over the last few years, I've switching to working only in projects using one of the Agile methods, like Extreme Programming. The low-level practices like test-first development and pair programming make coding much more fun, and the high-level practices involving planning and scheduling make it so that 40-hour weeks are the norm, and both I and my clients have confidence that what I'm working on matters.
So my tip to people: if you are starting to get burnt out on anything you love doing, then change it so that doing it is more fun than stressful. Any animal will learn to avoid things that are painful, and if you're spending 60 hours a week mainly in pain, that animal part will eventually win out, no matter how much you feel like you should stick with the job.
As I said, sometimes the "first version is meant to be thrown away", so it doesn't matter how many bugs.
Ok, so you spend a year making the first version. But you do it in such a rush that the code is stinky. It barely made it out the door.
Now you've got to do version 2.0. You tell the bosses, "Ok, you said we could throw the code away. So it'll take us a year of regular-time work to get to where we are now; the next version should be ready in 18-24 months."
What has always happened in my experience is that the managers turn purple, say that it's impossible, and say that the team should keep running with the old code and get done by some imgainary marketing deadline. Then they puff up with false charm and say how much faith they have in you; that you all pulled it off last time, so of course you'll do the same this time.
Then, because you're working with crappy, rushed code, schedules start slipping. The managers demand overtime, because they think that worked before. And the cycle carries on.
The only time I see people ready to change is right after they've been burnt on this. It's like dealing with alcoholics: they'll only change when they hit bottom, when they are defeated.
The better strategy is still to ship early, but with a solid code base and only basic features. If you solve the most critical business needs first, people will deal with limited software for a while. And if you release new versions regularly, with low bug counts and frequent improvements, you will win trust from customers and managers.
The time-to-market is more important in introducing a product. Moreover, the team can take a 2-5 day break, and come back to code version 2.0 at 8/5 pace.
After working at a furious, burnout-inducing pace for months, a 2-5 day break will just start to repair things. The times I've seen this happen, it takes a couple of months for a team to get back to normal. Until then, productivity is low, everybody is grouchy, personal relationships are strained, and everyody is listless.
For projects, the more the no. of bugs, the better it is, because they can keep billing the client for the mythical man-hours put in for fixing them. Project-companies with hourly billing gain both ways (12/7 followed by bug-fixing cycles).
Hey, you can't go giving away Accenture corporate secrets like that.
Yes! And let me name names here: Cingular was the one spamming me. When I called them up, they offered to stop sending them to me, but said that they were determined to keep sending spam to everybody who didn't complain. I now use Sprint, who haven't spammed in the six months I've been using them.
Java should been designed from the start to enforce getter/setter access to instance variables.
Yes. In my dream world, somebody at Sun will get a fucking clue and make getter/setter stuff implicit based on keywords when you declare the variables. Then if you need to override the default getter/setter behavior, you just explicitly declare the methods.
Then we can make the call implicit, throwing out all the foo.getBar().getBaz() crap and just make it foo.bar.baz.
At a guess, that would remove about half the lines of code in Java programs, all of which just clutters things up. And it could be done in a way that is completely backwards compatible, so that all old-style Java would still work fine in the new world.
Of course, that won't advance their enterprise penetration one bit, so it will never happen. If anything, enterprise shops like to churn out reams of overcomplicated code, as if they get paid by the line. Which, now that I think of it, explains the rampant use of EJBs.
Slashdot Mirror
There are aspects that can be evolved, and some that can't.
And which would those be?
And can you prove that they're impossible to change? Or are you only saying that you don't know how to change them and that you doubt anybody else knows either?
"Quick & Dirty" is not necessarily the opposite of doing things properly.
Agreed. A short-cycle iterative process is quick, but it need not be dirty. If you pick something disciplined, like XP, it will be very clean.
If you can deliver new features every week without compromising on quality (and an XP team can indeed do that), then that may make your bosses just as happy. Especially if you do the ones with the highest business value first. As I mention elsewhere in this thread, it makes mine even happier than under classic methods.
Wrong!
XP practitioners feel that architecture is so important that we don't let an hour go by without thinking of it. We change the design as we go to suit the current code base. It's called refactoring.
Doing XP, the designs of my programs are much, much better than they used to be. And it's faster. Much faster.
That's for three big reasons.
- When you do all your architecture up front, there's a lot of head-scratching and puzzlement; you have to make a lot of guesses about the future, and those are scary and hard. If you wait until you're the problem comes to the fore, it's generally pretty easy; you have a lot hard data and actual experience, so the solutions come quickly.
- Another is that if you only do your architecture in phases, during the time between phases, the factors that guided your architecture will evolve. By the time you reach the beginning of the next architecture phase, the current architecture is out of date. You then have to do a lot of work to get to the new architecture. That's like waiting until every dish in the kitchen is dirty before washing any; rather than scraping off dried gunk, it's easier if you just wash them as you go.
- The third is that you don't have to over-generalize up front. With XP, you write only the code you need today. Tomorrow, if an object is insufficiently general for a new feature, you can add the generality then. Unless you are a 100% perfect guesser, reduced speculative work means reduced waste.
It sounds crazy and takes a bit of practice, but it works stupendously wellDo not take the logical step and attempt to become a disciple of XP. You will either find yourself doing some of the stupidest things imaginable, or you will go insane.
Personally, I don't think anybody should be a disciple of anything.
But XP works for me, and I know quite a number of other people who it works for. Just yesterday I was pulled in a meeting at one of my clients; the CEO wanted to tell their two biggest investors how well it was working for them, and she wanted me to explain it to them.
She's excited because we're delivering solid software with very low bug counts. We give them new versions every week. They can see the software progressing. And they love the fact that they can completely change what's on the schedule for next week or next month without a peep from us.
If you've heard of XP and think it's a good idea, do not make the mistake of reading anything about it.
Sounds like you're looking for some disciples yourself!
This is one reason why we as a society need to find ways to get rid of this need for greed and wealth and money in general. Otherwise things just keep running into the ground.
Don't be silly.
Suppose we find some magic way to get rid of money and the need for it. Anybody who still programs does it either because a) it entertains them, or b) it benefits someone. If it's for entertainment, fine, they can make whatever they please. But if it benefits someone, then the programmer always has to face the tradeoff of benefiting them some right away or benefiting them more later.
Imagine, for example, that you've got a five-year grant writing educational software. You have no pressure to deliver anything, so you could wait until the fifth year to deliver something fantastic. Or you could push something quick and dirty out right away and educate five years worth of kids that would otherwise miss out. A programmer who is doing something that matters should always feel time pressure, even if it's only self-imposed.
Yeah, they seem pretty much invulnerable. We used a bunch of them for an art project in the Black Rock Desert. I have pictures of me coding away during a dust storm. The laptops all survived happily.
Ok, to bring another level to it. Why is running an unknown executable dangerous?
It's pretty safe running unknown Java Applets in our browsers these days, barring the occasional VM bug. Why can't we run random executables without worrying that they'll delete everything/spam/etc.
Why the assumption that running a random executable is dangerous?
Defining what an app is allowed to do is pretty tricky. That's especially true if you want to be able to bubble up decisions to the user.
Suppose that somebody sends you an applet that nominally shows, say, the latest sports scores, but in really cool way. When you run it, how can a security manager tell the difference between a legitimate hit to a web site to get the data and an illegitimate one to send out spams? And what questions can it ask of a novice user where the user will make the right decision?
The issue is made a lot worse by the crappiness of many user interfaces. There are an awful lot of programs that put up stupid, confusing, or useless dialog boxes; people are generally in the habit of clicking "ok" just to get on with things.
It's their right to send it to you, it's your right to block it.
By the same theory, it's my right to stand outside your house at 3 am and shout through a megaphone, right? After all, it's your right to brick up your windows and install more soundproofing.
You are misunderstanding the situation, I think. Were I to say, "In the natural world, we find some phenomena P; ergo we should live our lives with the assumption that P is good, because P occurs in the natural world", I would be following the line of logic referred to as the Naturalistic Fallacy. In short, the NF is deriving what ought to be from what is, as you point out.
However, I am making no claims about the natural world and deriving moral value from it. My claim is that life is a zero sum game: you are born, you die. The universe expands, it contracts. That's it -- there is no moral value being assigned whatsoever.
As any programmer can tell you, assigning a value of zero is still assigning a value. You are saying that because of certain facts about the natural the world, people shouldn't get worked up about spam. You're taking an is, with which I agree, and asserting an ought, with which I don't. You're welcome to call that whatever you like; I'd call the naturalistic fallacy, but please call it bacon (either Sir Francis or hickory-smoked) if it suits you.
Either way, perhaps you can drop the waffle about the universe, and just say that you don't think human life has any value. Then I can say, "well I do, and so do most voters and lawmakers" and we can move on.
I think your interpretation is that an absence of moral valuation is tantamount to assigning moral value. I disagree. It's a line of reasoning on par with saying, "atheism is a belief!"
Atheism, defined as disbelief in or denial of existence of God or gods is indeed a belief, by which I mean a unproved assertion about the nature of reality. So yes, it's the same line of argument. Unless, of course, you have some proof of the nonexistence of God, in which case you should really write a book about it.
Condescending comments about Google aside, the responsibility of backing one's facts up is left to the person making use of them.
Communication is a two-way street. These studies are well known to people who study the issue; I was hinting that maybe you should do a little more research before holding forth, or at least before demanding that I do the work for you. Since you couldn't quite manage, I did indeed back the facts up.
Looking at the ones that you provided, my argument is not swayed: bandwidth is a questionable cost, generally set at what the market can bear rather than the actual cost of delivery.
Uh, all costs are set by what the market can bear. That's how capitalism works. Bandwidth might be a questionable cost to somebody who doesn't pay a bandwidth bill. But for those of us who do, it's a real cost.
"Wasted time" is a convinient shock value technique, but it's also questionable. *You* decided to use email; your time was not stolen from you.
Given that I started using email before spammers started spamming, it seems pretty weird to say that I chose to be spammed.
But I guess your rule would apply to telephone solicitations, too. Would that make you opposed to the do-not-call registry currently being implemented?
And heck, running with your theory, it seems that kidnapping shouldn't be a crime, either. Or harrassment. After all, it's only time and bother, and with sufficient effort people can choose to isolate themselves from those risks.
The "projections" of doom and gloom from a company [...] are suspect at best; I am not at all convinced that spam is going to "overwhelm email".
Spam is circa 50% of email, and growing rapidly. Brightmail has made no projections that I am aware of, but they don't have to; there's no reason to expect that the trend will change on its own.
if you want to use the medium, you have to expect that there is some noise to the signal.
There are two things wrong with this. One is the comparison with analog communication, where the signal/noise stuff comes from. It's
I quote Frans de Waal, from Good Natured: the origins of Right and Wrong in Humans and Other Animals: You asserted that life is "inherently meaningless", a proposition with which I agree; it's all just molecules bumping around. But that doesn't mean anything about how we should act. By suggesting otherwise, you are making a classic philosophical mistake.
Spam is not a "major societal problem." Hunger, AIDS, and the abuse of our civil liberties are examples of major societal problems.
It depends on how you look at it. Spam is threatening to overwhelm email; left unchecked, it will. The Internet, and related distributed media like SMS, shift political power substantially back towards ordinary people, as demonstrated both by anti-war organizing in the US and the troubles these media are giving repressive goverments around the world.
Spammers threaten that democratic shift by their increasing ability ability to drown out real communication, which is already causing marginal internet users to abandon email altogether. Worse, we are inviting governments to get involved in regulating something that, spammers aside, was largely self-regulating. This is unlikely to help civil liberties.
Certainly, spam is not as big a deal as AIDS, but the resources spent on dealing with the two turn out to be in the same ballpark. Just this week, the UN reported that total AIDS spending this year in low- and middle-income countries will total $4.7 billion. By 2005, they expect to need about twice that.
By forcing people to waste billions of dollars (and vast amounts of personal and governmental attention) on spam, the spammers are consuming resources that could be put to productive use, like plugging that gap in AIDS funding.
Undocumented claims of cost are not impressive
Sorry, I thought you had heard about Google. But let me help you out. In early 2001, in The European Commission estimated the direct costs of spam to be circa 10 billion euros ($11.6 billion) per year, not counting the value of time of the recipients. Ferris Research comes up with a similar number for 2003 just for costs to US corporations. A writer for the Guardian, trying to include the value of the wasted time, makes an off-the-cuff estimate of $100 billion.
I don't buy the higher number, but it's hard to dispute that the direct costs for spam are in the billions. And if putting CEOs in jail for wasting billions in order to steal millions seems fair, then doing the same to spammers seems only proportionate.
Repeat after me: your life, just like mine and most everyone else's, is inherently meaningless.
Hi! Philosophers know this as the naturalistic fallacy. The way the world is implies nothing about the way we should choose to make it. You are welcome to choose a zero value for human life. I pick bigger ones, as do most people.
Spam is annoying. Spam is nothing more than that -- it does not deserve "hard jail time".
No, Britney Spears is annoying. Spam is a major societal problem.
From the estimates I've seen, the worldwide cost of spam is$10-$50 billion/year, and it's still growing unchecked. As this article suggests, it seems to be moving from the control of low-lifes to outright criminals. I guess that's not surprising, given how much of the stuff advertised via spam is either fraudulent or illegal.
When you compare the costs of spam to some of the recent large business bankruptcies, it's clear that spam in in the same league. People are clamoring for jail time for the recent set of CEOs/con-men; why shouldn't spammers, who cause a similarly big problem, face similarly big sentences?
Paypal donations to hi-tech hit squads, a la Tom Clancy and his Mr. Clark, to track down and eliminate, with EXTREME prejudice, any and all spammers, anywhere in the world.
There's a problem with knowing who to pay. Of ourse, you only want to pay for results, so some neutral third party should collect the cash and hold the bounties.
But once the spammer is dead, how do you know who to pay? And remember, if you pay the wrong person, then there will be a disgruntled contract killer out there!
Fuck praise and acknowledgement, fuck them in their stupid asses. Show me the money, and stop making me work 'till midnight on Friday.
Hi! You are on the fast road to burnout. In my experience, if you don't change things so that you are happy enough that you can start recovering the enjoyment you used to find in your work, you will end up hating utterly both the work and the job, so much so that even years later the thought of doing the work will make your stomach lurch like biting into rotten meat.
It sounds like you feel like you are doing far more than they are paying you for. Bring that back into balance. The right way depends on the situation, but do it pronto or you'll end up quitting in a huff or getting fired for being surly.
If you want to know more, ask here or drop me a private email.
Heh. Is it: Or Probably a bunch of each.
Q. I feel inadequate, I have thousands of users asking for features, but I can't deliver _and_ keep my family fed. -- Frantic, IL
A great answer to this problem is to learn how to say, "Patches welcome!" and mean it. The fact that a lot of other people want something does not mean that you must work on it.
Some people of course then say, "But I can't write code!" The proper response to that is, "Would you like to hire me to work on it?" Or possibly, "Perhaps other people want the same thing. See if you can get together enough contributions to pay for it."
The Buddhists teach that desire is infinite. That accords with my own experience: what people really want is to have everything, for free, right now. An important trick for every programmer to learn is to let other people do the work of managing their own desires. For example, I have learned to never ask a client if they want a feature, or when they want a feature. Instead, I ask them what the most important feature is, and I work on that one first. When it's done, I ask them what the next most important feature is.
In addition to all of this, what the fuck does the programmers opinion of the customers even matter?
With every line of code a programmer writes, he is affecting the customer, directly or indirectly. (If he isn't, then why have that line of code?) To build good, usable systems, you must have sympathy for and understanding of the users.
If I had somebody on my team who hated the customers or had a lot of contempt for them, I'd get 'em out of there, pronto. That attitude is contagious. To my mind, that's because it's lazy; tearing down is always easier than building up.
To them I say, work in the tech sector for the last 10 years and try to not turn out even MORE sarcastic/pessimistic then I.
I have worked in the tech sector for longer. I still do it because I like it, and I've found ways to make it sane and enjoyable. That's not to say it is a bed of roses, or that it's always fun, but I do good work that I'm proud of, and have fun along the way.
Why would you keep doing something you hate?
Many household devices today use more power when their state is changed than they would if they were just left on constantly.
Go get yourself a meter like the WattsUp and gather some stats. In my experience, for computers there is an initial power surge that is maybe 2-3x normal draw, and lasts anywhere from 20 seconds to a couple of minutes. So worst case, if you will be turning your computer on again within 6 minutes, you probably should leave it on. Otherwise, turning it off will save power.
For screens, it's more complicated; CRTs draw more while warming up, but only for 15 seconds or so. But they draw less when showing a fully black screen, and different resolutions draw different amounts. Also, modern CRTs have assorted sleep modes. So whether or not to turn off a CRT depends on your usage patterns. For LCDs, I have no data.
I was also interested to note that high CPU usage produces measurable extra power usage. On a dual-processor P3/733 system, each processor pulls an extra 10 watts under load. So it turns out that things like SetiAtHome aren't free.
My mother, for instance, wastes more power than she saves by going around turning off all her fluorescent lights.
A common misconception, but not true. See this article for the details. They recommend leaving them on if you'll need them again within 15 minutes. But this isn't because of power usage; it's because turning them off and on too often reduces bulb life.
Aren't LCD monitors designed in the same way? They only use power when they are updated?
You'll note that in a dark room, you can see the LCD just fine. This means that it's producing light, which takes power. According to this week's Economist, "an LCD is only 10-15% efficient at converting energy from its power source into a readable image."
If you want to check out your theory, you can look at Chilling Effects, an archive of threat letters like this.
it looks like it included ROM images. That'd probably be why the DMCA was invoked.
That could well be; it looks like the wayback machine hasn't cached the pages involved. But some ROM copies are legal and encouraged; I own an Addams' Family machine, and the manufacturer posted ROM updates on their web site for it. Anybody know what was actually there?
I'd wager that an afternoon spent perusing books on small claims and how to collect would give you all the information you need.
Yes, but then none of us would know the scoop. Plus, fellow geeks who have been through it may provide advice that wouldn't turn up in an afternoon at the library.
That's not to say people shouldn't do their own research, of course. But when I'm reading in the "Ask Slashdot" section, I think questions like this are great.
I wonder how common it is that programmers come to hate programming or even computers in general.
:-)
I've felt that at times. For me, it was always about the work and the work environment.
Years ago, I was a sysadmin, mainly because that was the work available. But in working 70-hour weeks for a couple of financial companies, I completely burned out on it. Even now, if I have to do more than a couple of hours of it, I get immensely surly.
So I switched to full-time development, which was what I preferred. For a while, that was great, too, but after a couple of death-march projects I was getting burned out on that, too. It made me sad; I really like programming, but forcing myself to program for 60 hours a week for unappreciative jerks was somehow taking the fun out of it.
Over the last few years, I've switching to working only in projects using one of the Agile methods, like Extreme Programming. The low-level practices like test-first development and pair programming make coding much more fun, and the high-level practices involving planning and scheduling make it so that 40-hour weeks are the norm, and both I and my clients have confidence that what I'm working on matters.
So my tip to people: if you are starting to get burnt out on anything you love doing, then change it so that doing it is more fun than stressful. Any animal will learn to avoid things that are painful, and if you're spending 60 hours a week mainly in pain, that animal part will eventually win out, no matter how much you feel like you should stick with the job.
As I said, sometimes the "first version is meant to be thrown away", so it doesn't matter how many bugs.
Ok, so you spend a year making the first version. But you do it in such a rush that the code is stinky. It barely made it out the door.
Now you've got to do version 2.0. You tell the bosses, "Ok, you said we could throw the code away. So it'll take us a year of regular-time work to get to where we are now; the next version should be ready in 18-24 months."
What has always happened in my experience is that the managers turn purple, say that it's impossible, and say that the team should keep running with the old code and get done by some imgainary marketing deadline. Then they puff up with false charm and say how much faith they have in you; that you all pulled it off last time, so of course you'll do the same this time.
Then, because you're working with crappy, rushed code, schedules start slipping. The managers demand overtime, because they think that worked before. And the cycle carries on.
The only time I see people ready to change is right after they've been burnt on this. It's like dealing with alcoholics: they'll only change when they hit bottom, when they are defeated.
The better strategy is still to ship early, but with a solid code base and only basic features. If you solve the most critical business needs first, people will deal with limited software for a while. And if you release new versions regularly, with low bug counts and frequent improvements, you will win trust from customers and managers.
The time-to-market is more important in introducing a product. Moreover, the team can take a 2-5 day break, and come back to code version 2.0 at 8/5 pace.
After working at a furious, burnout-inducing pace for months, a 2-5 day break will just start to repair things. The times I've seen this happen, it takes a couple of months for a team to get back to normal. Until then, productivity is low, everybody is grouchy, personal relationships are strained, and everyody is listless.
For projects, the more the no. of bugs, the better it is, because they can keep billing the client for the mythical man-hours put in for fixing them. Project-companies with hourly billing gain both ways (12/7 followed by bug-fixing cycles).
Hey, you can't go giving away Accenture corporate secrets like that.
Yes! And let me name names here: Cingular was the one spamming me. When I called them up, they offered to stop sending them to me, but said that they were determined to keep sending spam to everybody who didn't complain. I now use Sprint, who haven't spammed in the six months I've been using them.
Java should been designed from the start to enforce getter/setter access to instance variables.
Yes. In my dream world, somebody at Sun will get a fucking clue and make getter/setter stuff implicit based on keywords when you declare the variables. Then if you need to override the default getter/setter behavior, you just explicitly declare the methods.
Then we can make the call implicit, throwing out all the foo.getBar().getBaz() crap and just make it foo.bar.baz.
At a guess, that would remove about half the lines of code in Java programs, all of which just clutters things up. And it could be done in a way that is completely backwards compatible, so that all old-style Java would still work fine in the new world.
Of course, that won't advance their enterprise penetration one bit, so it will never happen. If anything, enterprise shops like to churn out reams of overcomplicated code, as if they get paid by the line. Which, now that I think of it, explains the rampant use of EJBs.
IntelliJ IDEA just plain rocks. I don't know how I coded without it before.
Let me give a hearty amen. It's so amazing that a colleague even dropped Emacs for it. That's like quitting the Borg.