What is wrong is when companies who make copy-protecting products don't disclose the restrictions to the consumers. Like Apple's recent happy-happy web pages on their new DVD-writing drive, announced this month (http://www.apple.com/idvd/). It's full of glowing info about how you can write DVDs based on your own DV movie recordings, etc. What it quietly neglects to say is that you can't use it to copy or time-shift or record any audio or video copyrighted by major companies. Even if you have the legal right to do so, the technology will prevent you. They don't say that you can't use it to mix and match video tracks from various artists, the way your CD burner will. It doesn't say that you can't copy-protect your own disks that it burns; that's a right the big manufacturers have reserved to themselves. They're not selling you a DVD-Authoring drive, which is for "professional use only". They're selling you a DVD-General drive, which cannot record the key-blocks needed to copy-protect your own recordings, nor can a DVD-General disc be used as a master to press your own DVDs in quantity. These distinctions are not even glossed over; they are simply ignored, not mentioned, invisible until after you buy the product.
"Having an axe to grind" is entirely irrelevant. Their motives (and identity) are their business, and we shouldn't care whether they're praiseworthy. The merit their arguments may have is the only question worthy of public discussion.
This is one of those things that is true in theory but false in practice.
Were all participants in a public discussion sane and reasonable people, you might be right. Had I infinite time and infinite patience, you would certainly be right. But none of these things are true.
In practice, if someone does have an axe to grind, they won't be convinced by any rational argument about the topic, as their motivation for continuing the argument has nothing to do with getting at the truth. Try arguing with a PR flack or a lawyer sometime; it is their job to argue a point until the end of time, twisting and dodging to avoid even getting in the vicinity of the truth.
I dunno about you, but I'm mortal. I have a limited amount of time to spend on this planet, and I have stuff to do. I'm glad to discuss thing with people who are, like me, willing to learn and change their viewpoints. But I have pretty much given up arguing with crazy people; I've only got 40 or 50 years left, and I have a lot to do.
X86, and NEXTSTEP/OPENSTEP (OSX's ancestor) always had support for X86.
For the record, that's not true; the original OS was for NeXT hardware only. My memory is pretty fuzzy here, but I think they launched the X86 version at the same NeXTworld Expo that they announced that they were going to stop making hardware. Was that '93? And the first NeXT boxes I recall were in '88 or '89, so that's 4 or 5 years on proprietary hardware.
My personal bet is that they will get the OS working in the lab as a "just in case" plan; given its cross-platform history, I think it won't be much work (except, of course, for hardware drivers, which will be a nightmare, just like they were with the x86 NextStep).
But they won't ever release it until Apple itself is forced out of the hardware business. Remember that Jobs is the guy who killed the Mac clone business; doing an X86 version of their OS is even worse, as their are no hardware license fees. But it will come to pass sooner or later.
It really saddens me, as I'm very fond of Apple, but they're caught in a vicious circle that I don't think they'll ever break out of.
A recent Slashdot article pointed to a long essay by John Gilmore, originally found on cryptome.org where, among other things, he basically claims that MP3 players don't record because their manufacturers are afraid that they'll get the pants sued off them.
It seems plausible, but does anybody have facts to back it up?
Actually, that's not an ad hominem attack. An ad hominem attack is one where you attack the arguer on the basis of something both personal and irrelevant. For example, calling you ugly and smelly would be an ad hominem attack. The claim that you have an axe to grind, however, may be personal but it's sure not irrelevant.
And really, the guy has a point. Your first post in this thread is titled "New Age Programming B.S."; it's a full-tilt screed against a book you obviously haven't read. Why would you do that?
Is it because you know the author to be a charlatan and a cad? Is it because, although you didn't read the book on XP, you did try its techniques faithfully and found them not to work? Is it because you are the author of a study on XP that shows it to be a fraud? If so, you never mentioned it.
So when somebody posts a rant about a book that he hasn't read and doesn't back his frothing up with some other justification, it is reasonable to presume that you indeed do have an axe to grind.
Indeed, I find it really weird that of all the negative posts in this thread, almost none of them are from people who have actually tried the XP methods on a project. It seems like there's a lot of axe-grinding going on, although that's nothing new for slashdot.
The problem with books like these is that I cannot tell at whom they are aimed.
Beck's book is aimed at all members of a development team, for the simple fact that XP is a team-oriented approach. It covers a broad range of areas because he feels that the value comes not in the indivdual pieces but in the way they reinforce one another. E.g., refactoring without good unit tests is dangerous. Common code ownership is very risky without the good communication promoted pair programming. Limited planning is very risky without short release cycles. And so on.
Someone who is an experienced software manager is unlikely to need to an all-encompassing book like XP.
There are two problems with this statement. One is the implied suggestion that an overwhelming majority of software managers are so experienced that they know the basics solidly. The second is that there is some all-encompassing framework that is so well established that all good managers share the same view of software development.
The truth is that neither is true. I'm not sure where you work, but I've been doing development for 15 years, and I'd say that good project managers, well versed in all important aspects of developing software are the exception, not the rule.
And as to the notion that the foundations of our discipline are so well-settled and obvious that a book with a broad view of the process is useless, I can only laugh. As a developer and the son of a developer, I can assure you that this isn't true. The goals, resources, methods, tools, and methodologies have all changed relentlessly, and that won't stop until Moore's law gives out.
If you've got the twenty-plus years of experience that you claim, you know that almost everything thought of as "fundamental" thirty years ago is different now, and you need only pick up a few CS textbooks to verify that. Even today, a large percentage of software development projects fail utterly, suggesting that, as a profession, we don't really have our acts together.
So bravo for books that are broad in scope! XP may or may not suit your projects (and indeed, I would be surprised to see it working well in an embedded-systems context), at least Beck took a broad look at the process and challenged some sacred cows. I don't buy all of what he's selling, but I found it valuable to read his book.
I'd agree that "prickly" is a good word to describe Bernstein; a while back I wrote a chapter of a book on email and while I was writing it I had nightmares about him reaming me for a minor error. Luckily, the book seems to have escaped his notice.
Having used qmail for a few years, I can indeed say that it is a safe and reliable product. But I wouldn't recommend it for a novice sysadmin; DJB is a really smart guy, and he seems to have little patience for those who aren't.
As to his views on licensing, here is the distribution policy for his software. He strictly forbids distribution of qmail except in forms approved by him:
If you're using POP, typically the MUA downloads and removes all mail from the server. If that's the case with you folks, then you're taking advantage of the client's CPU and storage, rather than the server. That's swell if you already have heavy-duty clients with good backups and your people don't move around much. IMAP makes more sense if you need a central message store, though.
Both are reasonable choices, but it's unfair to compare them in an apples-to-oranges fashion.
Enduring every little typo and thinko (not to mention spending hours at a time with a random coworker) is a totally different beast.
Yeah, god forbid that somebody might notice that you're not perfect. And god forbid that you should be confronted with the fact that your colleagues aren't either. Then those errors might get corrected right away, rather than getting incorporated into the final product.
I agree that pair programming takes some getting used to; at first, it feels pretty hard. Eventually, you get used to it. Either way, it produces better code. If you're mainly interested in putting out good work, you'll adjust. And in the meantime, don't forget to take breaks; you don't have to spend 8 hours in a row manacled to somebody.
In practice, both sides must adapt to make pair programming work. You learn emacs, they learn vi. (Last week, I was learning emacs myself for jst this reason.) You learn to work without highlighting, they learn to work with it. And the organization should do what they can to make things better; seeing more code at once is very helpful, but some people have better eyes than others. So you buy 22" monitors for the shared workstations.
Doing things in group always requires a little compromise, so people who are unable to deal with that shouldn't be doing XP.
A major shortfall that I've seen in XP is that it requires that 'all be equal' in skill and understanding. A constant refactoring of existing code requires that all participants be on the same foot and have access to all the same facts.
That's not true in my experience. It does require programmers to have a semi-sane understanding of how good they are, though. And it requires that everybody have a fair bit of team spirit. Novices must be smart enough to know that they should not be doing major redesign without talking it over with the team first. (And really, the same goes for the experts.)
1. Tightly Focused team, with no distractions from other priorities. (I typically work on 2-3 projects at a time, each at various states. My scheduling precludes any 'shared programming' time.)
This isn't necessarily true, but XP does require a lot of communication between developers on a project. Pair programming and a shared project room are good ways to do this. Solo developers communicating by email is a very bad way to do it; if you're in that condition, XP is a bad choice. So if you have to work on multiple projects in an XP context, you have to rigidly schedule things so that, e.g., all the work on Project A happens in the mornings, and all work on Project B happens in the afternoons.
I'll argue the other way: The lowest skilled team member will drag the team and the project down.
It depends on what you mean by lowest skilled. If you mean "fresh out of school with little experience", then you try to make sure that the novice gets paired up with senior developers for a while. At first, they'll have little to contribute (e.g., "You missed a semicolon") but quickly they become more productive.
If, on the other hand, you mean "never likely to be a good programmer", then yes, they are bad for the project and should be fired. But even in this case, pair programming, good unit tests, shared code ownership, and strong version control limit the damage one rogue idiot can do much more than on a project that doesn't use these techniques.
3. Well targeted goals.
I agree that this is good to have, but it's much less of a problem on an XP project than, say, a traditional Waterfall lifecycle project. A frequent release schedule (XP recommends every 1-3 weeks) is the key. Everybody gets together and sets the goals for the first version. In a couple of weeks, everybody gets together and says "Oh! Now we see that we should really be going Y instead of X" and so you code the next revision that way. When goals are poorly understood, Evolutionary Delivery lifecycles are great for reducing risk.
Beck makes pretty clear that the XP model is not for everybody. He even has a chapter titled When You Shouldn't Try XP.
He also makes many of the same points you make; especially that understanding customer needs is crucial. He goes further to say that the only will way to understand customer needs is to involve them (or, as you say, their representatives) closely in the development process, so that you have lots of feedback.
Because XP has a lot in common with the Evolutionary Delivery lifecycle, it also substantally reduces budget-related risk. Since you are regularly producing high-quality working versions that have successively more features, you always have something to deliver.
So I agree that 'silver bullet' solutions are bad but I disagree that XP is such a solution. It's just a collection of development techniques that are, for the most part, entirely uncontroversial. The only new thing is the emphasis on combining them in a way that they reinforce one another.
I agree that if you have an evil (or willfully clueless) manager, no book will help. But there are a lot of people who manage software projects (or who manage people who manage projects) that are ignorant but willing to learn, especially if it means the difference between success and failure. And for those people, sticking a few books under their noses will help a great deal. For these managers, I give away copies of Rapid Development or The Software Project Survival Guide depending on how technical they are. And if your project is suited to an XP approach, then a book explaining the business case for using XP will help them understand why they should back you, rather then meddling with things they don't get.
the supposed way to go is not to be looking ahead to the next problem
Yeah, this bugged me, too.
The way they talk about it is in pretty absolute terms. Don't look ahead, just focus on the immediate concern, etc, etc. It sounds ridiculous, and when you take it literally, it is ridiculous.
But after a little while, I began to see the problem they were trying to address. It's very easy to say things like "well since we need to display one graph, we should build a whole graphing framework, as we'll probably need to do more graphs eventually." And then you go off and spend a month building a (very nice, very solid) graphing framework for your one graph. But it was fun and interesting and the Right Way To Do Graphing, so you feel good about your work. And once they ask for more graphs, you'll be golden.
But then it turns out that nobody ever asks for more graphs, and so your nice framework never gets used. Worse, people don't use the program much because it's missing features that they need, features that you could have added in that month. So the project gets cancelled and your code goes to waste.
So their point is not don't do work that you need 15 minutes from now but more like don't do work that you won't need for a month. You just figure out what you need to get this version finished and code that. That doesn't mean writing shoddy code to get it out the door, of course; you write good, solid stuff, but nothing more than you need. When the next revision comes, then code that then.
If you haven't experienced refactoring, this still seems ridiculous. But if you already have an lot of unit tests and functional tests, you become confident that you can improve your design incrementally and still have everything work. Which means that painting yourself into a corner is not the problem that it was before.
Personally, I am still getting used to this. But so far it has worked pretty well.
Having tried some of the XP methods, it's my impression that they don't have to be followed precisely, but you do have to be true to the spirit of them. Most of them are valuable on their own, but some methods are dangerous if used wrongly.
One of the important elements of XP is indeed continuous unit testing, integrated into the process. Another is continuous customer involvement. A third is short release cycles. All of these drastically improve feedback, which is a vital underpinning to many of the other techniques.
But another vital component is a good team, one where this is mutual respect and a strong sense of shared goals. In the situation above, people were allegedly wrecking one another's code; this either suggests incompetence or internal political struggles that get expressed in the code. Either way, it's a massive management failure to let rogue workers run unchecked.
XP should absolutely not be used in a group of people that is not working as a team. XP is a process that requires people with a sense of community. 90% of the programmers I know have this. 99% of the good programmers I know have this. But if a manager tries to impose XP, she must do it only with people who can play well with others.
Personally, I'd use some sort of scripting environment, probably Perl, for all of the prototyping, playing around, data translation, and glue work.
And then for serious stuff, I'd use something more structured and formal. Personally, I like Java; it's well known, pretty well supported, good at handling errors, has a reasonable amount of network stuff built in or available, and from the beginning had threading in mind. But I would certainly use some sort of OO language for this, as this kind of work strikes me as well-suited for an OO approach.
Oh, and do your work incrementally! Avoid grand plans; code in an exploratory fashion. If you're doing OO work, the book Refactoring is a great one. And if you're doing incremental design in Java, you will soon grow addicted to unit testing; I have grown to love JUnit, a Java unit testing framework.
But if this is mainly for your own use, use whatever tools you are most familiar with. I find that tackling a new tool and a new problem domain at the same time is generally too much to allow quality work. New problem? Old tool. New tool? Old problem first!
Whatever, boss. The site is pretty clearly Milloy's project. And the whois record still lists him as the owner. So the fact that a number of big polluters pay his bills is still relevant, even if he isn't doing the day-to-day work.
And speaking of which, according to you, who is? And what's your evidence for claiming that Milloy's not in charge?
As another poster pointed out, the latter half of this article claims that the author of junkscience.com was a registered lobbyist for several large firms with dubious environmental records. And at the same time he has been running this website, he was executive director of a (now defunct) non-profit that had members including "Amoco, Chevron, Dow Chemical, Exxon, General Motors, [...] the National Pest Control Association, Occidental Petroleum, Philip Morris" and so on.
Conveniently, the fact that large polluters have been paying his bills for the last several years isn't mentioned on the "about the author" section of his web site. Maybe he's an entirely disinterested scholar who just happens to be funded by a lot of people with a financial interest in opposing environmental regulation, but I'm not convinced.
Bad science sure does happen, but a guy with a financial interest in the outcome is not one I'll take very seriously on the topic.
Actually, I was looking for specific cites for the "facts" of the poster I was responding to. But thanks for the references!
As much as I love the work various libertarian think tanks on social policy and on the theoretical point of government, I'm not very impressed with their output on matters of fact, especially ones where the facts are hard to read.
Here I think their (obvious and admitted) biases are too strong for them to look dispassionately at the facts. Especially when one conclusion would cause them to recommend forcing people to participate in large-scale collective projects of a kind that they clearly abhor. And their claim that scientists might bias their results to get grants, while not entirely without merit, is the pot calling the kettle black. How much do you think CATO's donations would drop if they came out with a book titled "Why We Need A One-World Government To Stop Global Warming?"
At the same time, I find it disconcertaining that a lot of environmental rhetoric has a tremendous amount of counter-cultural, anti-corporate, 'fuck the man'-type reasoning that I have a hard time taking seriously. As a small business owner living in the People's Republic of San Francisco, I feel your pain. Around here, people have vaguely heard of a market economy, but they are pretty unclear on the workings of it.
But the legitimate gripe in that anti-corporate rhetoric is that modern corporate culture is strongly biased towards relentlessly short-term extraction of cash. In its place, this is great, but without appropriate counterbalancing forces, it leads to insane behavior. An example popular with the greens is environmental dumping; for slashdot, the example is spam. Both impose huge costs on everybody for small benefit to a few individuals.
Personally, I don't see why the conservatives don't use this as a prime opportunity to rejig the tax system. Put in place various emissions fees and resource extraction taxes and you could use those to get rid of the the income and capital gains taxes. If we're going to be taxing something, I'd rather tax something unarguably bad (pollution and non-renewable resource consumption) than something pretty good (economic activity and value creation).
Unfortunately, the people pushing this are the true believers. Their beliefs and plans have a fanatical religious quality. Fanaticism doesn't tend to lead to good decision making.
Yeah, I find it kind of wearying myself. It would be nice to see more measured debate on this. I find it hard to trust anybody involved.
Of course, humans beings have an immense and well-demonstrated capacity to ignore anthing that isn't currently biting them in the ass. And American culture doesn't do anything to mitigate this; we are relentlessly focused on the short term.
So if, hypothetically, after careful review of the evidence you decided that global warming was happening, you can see that the shrillness of many environmental activists is a reasonable (if mainly useless) reaction to the fact that the nation that pollutes the most collectively said "so what?" and went out and bought a bunch of SUVs.
Incautious changes to a system that you don't understand can lead to disaster
I agree that much more research is needed, but the notion that CO2 emissions could cause devestating climactic change is theoretically plausible, and a lot of reasonable scientists have concluded that it is happening.
In light of that, wouldn't it be at least reasonable to start hedging our bets?
You got some credentials, pal? Some evidence? Some references? Or are you just running your mouth?
First of all, reducing C02 doesn't really lower greenhouse gases. The biggest greenhouse gas is water vapor, making up 98% of all greenhouse gases.
Yeah, and your heart is only two percent of your body mass. So I guess taking it out wouldn't really lower your functioning, eh?
during the 60s, people worried about a global cooldown.
Yeah, and the shining product of computer science in the 60s was COBOL. So what? In last 30 or 40 years, a lot of new work has been done and a lot of new data unearthed. Oh, and they now have these fancy thingies called computers for working with all of this data. It would be reasonable to think that climatology, like every other science over the last few decades, has improved some.
Third, global temperature depends on where you measure temperature.
This effect is known and can be corrected for. And it has no effect on other ways of measuring historical temperatures, like ice cores and tree rings.
Statistics lie, that's what they're good for.
Spoken like a guy who's never taken a stats class. Statistics, like any other tool, can be wielded wisely or foolishly.
Lastly, scientists don't agree on global warming.
And not all scientists agree on evolution. Does that mean we should just turn the schools over to the fundamentalists?
There was a similar conference earlier this year where scientists decided that they couldn't come up with a solid decision on global warming.
Really? I heard there was a conference earlier this year where scientists decided you were a dork. Talk is cheap, pal; if you want to be taken seriously, give links and references to support all of your assertions of alleged fact.
My employer (who, like me, shall remain nameless) used Viant. What a complete fucking disaster. They couldn't be bothered to really understand what we were doing, or sometimes what their predecessors had done. They had lots of meetings to discuss The Process. The Process involved many, many more meetings [...]
Facinating! (Hey moderators! Moderate the AC post up so others can see the whole thing.) This sounds a lot like Verde.com's experience with sound-alike consulting shop Scient, at least as told in the article How Scient helped Verde.com go from launch to bankruptcy in less than 60 days. And everybody there had to remain anonymous, too.
I broadly agree that putting somebody else in charge of the very heart of your business is a dangerous thing, and I generally discourage it. But people can also tell in-house development disaster stories, so that's no silver bullet. Indeed, I've seen projects fail because management couldn't resist meddling in in-house projects. An external vendor has more power to deflect or channel insane client demands; that power can be very beneficial to a project if used wisely.
One important distinguishing factor is whether or not you have a lot of ongoing development needs. Some projects have a huge amount of inital work and then a much smaller amount of ongoing work; it doesn't make sense to build up a big in-house staff, get them to work as a team, train them to your needs, and then fire half of them when the project is done.
On the other hand, most clients (and non-technical bosses) tend to overestimate the need for a big initial push and underestimate the need for ongoing work. As any developer knows, what people initially imagine they want and what they actually end up wanting once they've been through several iterations of development are usually pretty different. And if you're doing a web site or other Internet-delivered service, you can usually roll new features out gradually, further reducing the need for a huge initial dollop of work. So if your project can use an evolutionary delivery model building an in-house staff can make a lotta sense.
Both options are reasonable choices; both have their risks. The right answer depends on the details.
If you want a useful answer, you have to tell us a lot more. Start with your company's experience and resources. Have you managed outsourced development before? Do you have developers in-house to manage and check their work? Do you have experience in hosting and managing the application if you outsource development?
Then tell us about your business plan and goals. Which set of risks would be worse for your business if the worst happens? How much change do you expect in your requirements? (It's rare that the requirements at the start of the project are the same at the end.) How do you guarantee that once you have v1.0 that you can move to v1.1 and v2.0 without starting from scratch? How likely are your future needs likely to diverge from the ASP's main market?
Then tell us about the different vendors. What kind of reputations to they have? What kind of guarantees will they be willing to make? What are their portfolios like? If they screw up, do they have the resources needed to do it over for free? Will they let you talk to a client where they've done that? If a vendor goes bad, what plans do you have to migrate your clients and your data to a new system?
It sounds like you already broadly know the risks and potential rewards of the two paths; the right choice depends entirely on the details. And if you don't want to give the details to the public, than maybe you should (ahem) hire some of us to help you sort it out.
As for junk mail - why can't you just put your name on the no-junk-mail list?
I will likely give it a try. But there are several plausible reasons why people won't do it.
They don't believe it will work - Up until now, I'd never heard of anyone saying that it worked well, and I've heard complaints that it didn't. And since the general job of marketers is to lie, you can see how people would be skeptical.
It's more fun - You say you keep getting junk mail because it's entertaining. And then you complain that Taco, et al, keep getting junk mail because they entertain themselves with it. You waste $0.50 of the advertiser's money; they waste $0.80. Your high horse looks more like a small pony to me.
Civil disobedience - I would bet that if we put it to a national referendum, junk mail, telemarketing, and spam would be outlawed tomorrow. The DMA and large businesses spend a lot of money keeping junk mail legal, and generally advocating for maximally intrusive marketing. As an individual citizen I can (and do) write my congressman from time to time, but I don't have a lot of faith that my letter means a lot compared to their money. Making it more expensive for them strikes at the heart of this: they only do it because they make a buck on it; once it's not profitable, they'll stop.
It sends a message - Most marketroids believe that intrusive marketing is acceptable to the recipient. This lets them know that some of us think it's rude.
Before this came up, I just recycled all my junk mail, but I'm beginning to think that sending it back is a better idea.
Slashdot Mirror
So caveat emptor.
"Having an axe to grind" is entirely irrelevant. Their motives (and identity) are their business, and we shouldn't care whether they're praiseworthy. The merit their arguments may have is the only question worthy of public discussion.
This is one of those things that is true in theory but false in practice.
Were all participants in a public discussion sane and reasonable people, you might be right. Had I infinite time and infinite patience, you would certainly be right. But none of these things are true.
In practice, if someone does have an axe to grind, they won't be convinced by any rational argument about the topic, as their motivation for continuing the argument has nothing to do with getting at the truth. Try arguing with a PR flack or a lawyer sometime; it is their job to argue a point until the end of time, twisting and dodging to avoid even getting in the vicinity of the truth.
I dunno about you, but I'm mortal. I have a limited amount of time to spend on this planet, and I have stuff to do. I'm glad to discuss thing with people who are, like me, willing to learn and change their viewpoints. But I have pretty much given up arguing with crazy people; I've only got 40 or 50 years left, and I have a lot to do.
X86, and NEXTSTEP/OPENSTEP (OSX's ancestor) always had support for X86.
For the record, that's not true; the original OS was for NeXT hardware only. My memory is pretty fuzzy here, but I think they launched the X86 version at the same NeXTworld Expo that they announced that they were going to stop making hardware. Was that '93? And the first NeXT boxes I recall were in '88 or '89, so that's 4 or 5 years on proprietary hardware.
My personal bet is that they will get the OS working in the lab as a "just in case" plan; given its cross-platform history, I think it won't be much work (except, of course, for hardware drivers, which will be a nightmare, just like they were with the x86 NextStep).
But they won't ever release it until Apple itself is forced out of the hardware business. Remember that Jobs is the guy who killed the Mac clone business; doing an X86 version of their OS is even worse, as their are no hardware license fees. But it will come to pass sooner or later.
It really saddens me, as I'm very fond of Apple, but they're caught in a vicious circle that I don't think they'll ever break out of.
A recent Slashdot article pointed to a long essay by John Gilmore, originally found on cryptome.org where, among other things, he basically claims that MP3 players don't record because their manufacturers are afraid that they'll get the pants sued off them.
It seems plausible, but does anybody have facts to back it up?
Ooh! Great point! I didn't mean to imply otherwise.
Actually, that's not an ad hominem attack. An ad hominem attack is one where you attack the arguer on the basis of something both personal and irrelevant. For example, calling you ugly and smelly would be an ad hominem attack. The claim that you have an axe to grind, however, may be personal but it's sure not irrelevant.
And really, the guy has a point. Your first post in this thread is titled "New Age Programming B.S."; it's a full-tilt screed against a book you obviously haven't read. Why would you do that?
Is it because you know the author to be a charlatan and a cad? Is it because, although you didn't read the book on XP, you did try its techniques faithfully and found them not to work? Is it because you are the author of a study on XP that shows it to be a fraud? If so, you never mentioned it.
So when somebody posts a rant about a book that he hasn't read and doesn't back his frothing up with some other justification, it is reasonable to presume that you indeed do have an axe to grind.
Indeed, I find it really weird that of all the negative posts in this thread, almost none of them are from people who have actually tried the XP methods on a project. It seems like there's a lot of axe-grinding going on, although that's nothing new for slashdot.
The problem with books like these is that I cannot tell at whom they are aimed.
Beck's book is aimed at all members of a development team, for the simple fact that XP is a team-oriented approach. It covers a broad range of areas because he feels that the value comes not in the indivdual pieces but in the way they reinforce one another. E.g., refactoring without good unit tests is dangerous. Common code ownership is very risky without the good communication promoted pair programming. Limited planning is very risky without short release cycles. And so on.
Someone who is an experienced software manager is unlikely to need to an all-encompassing book like XP.
There are two problems with this statement. One is the implied suggestion that an overwhelming majority of software managers are so experienced that they know the basics solidly. The second is that there is some all-encompassing framework that is so well established that all good managers share the same view of software development.
The truth is that neither is true. I'm not sure where you work, but I've been doing development for 15 years, and I'd say that good project managers, well versed in all important aspects of developing software are the exception, not the rule.
And as to the notion that the foundations of our discipline are so well-settled and obvious that a book with a broad view of the process is useless, I can only laugh. As a developer and the son of a developer, I can assure you that this isn't true. The goals, resources, methods, tools, and methodologies have all changed relentlessly, and that won't stop until Moore's law gives out.
If you've got the twenty-plus years of experience that you claim, you know that almost everything thought of as "fundamental" thirty years ago is different now, and you need only pick up a few CS textbooks to verify that. Even today, a large percentage of software development projects fail utterly, suggesting that, as a profession, we don't really have our acts together.
So bravo for books that are broad in scope! XP may or may not suit your projects (and indeed, I would be surprised to see it working well in an embedded-systems context), at least Beck took a broad look at the process and challenged some sacred cows. I don't buy all of what he's selling, but I found it valuable to read his book.
I'd agree that "prickly" is a good word to describe Bernstein; a while back I wrote a chapter of a book on email and while I was writing it I had nightmares about him reaming me for a minor error. Luckily, the book seems to have escaped his notice.
Having used qmail for a few years, I can indeed say that it is a safe and reliable product. But I wouldn't recommend it for a novice sysadmin; DJB is a really smart guy, and he seems to have little patience for those who aren't.
As to his views on licensing, here is the distribution policy for his software. He strictly forbids distribution of qmail except in forms approved by him:
http://cr.yp.to/qmail/dist.html
If you're using POP, typically the MUA downloads and removes all mail from the server. If that's the case with you folks, then you're taking advantage of the client's CPU and storage, rather than the server. That's swell if you already have heavy-duty clients with good backups and your people don't move around much. IMAP makes more sense if you need a central message store, though.
Both are reasonable choices, but it's unfair to compare them in an apples-to-oranges fashion.
Enduring every little typo and thinko (not to mention spending hours at a time with a random coworker) is a totally different beast.
Yeah, god forbid that somebody might notice that you're not perfect. And god forbid that you should be confronted with the fact that your colleagues aren't either. Then those errors might get corrected right away, rather than getting incorporated into the final product.
I agree that pair programming takes some getting used to; at first, it feels pretty hard. Eventually, you get used to it. Either way, it produces better code. If you're mainly interested in putting out good work, you'll adjust. And in the meantime, don't forget to take breaks; you don't have to spend 8 hours in a row manacled to somebody.
In practice, both sides must adapt to make pair programming work. You learn emacs, they learn vi. (Last week, I was learning emacs myself for jst this reason.) You learn to work without highlighting, they learn to work with it. And the organization should do what they can to make things better; seeing more code at once is very helpful, but some people have better eyes than others. So you buy 22" monitors for the shared workstations.
Doing things in group always requires a little compromise, so people who are unable to deal with that shouldn't be doing XP.
A major shortfall that I've seen in XP is that it requires that 'all be equal' in skill and understanding. A constant refactoring of existing code requires that all participants be on the same foot and have access to all the same facts.
That's not true in my experience. It does require programmers to have a semi-sane understanding of how good they are, though. And it requires that everybody have a fair bit of team spirit. Novices must be smart enough to know that they should not be doing major redesign without talking it over with the team first. (And really, the same goes for the experts.)
1. Tightly Focused team, with no distractions from other priorities. (I typically work on 2-3 projects at a time, each at various states. My scheduling precludes any 'shared programming' time.)
This isn't necessarily true, but XP does require a lot of communication between developers on a project. Pair programming and a shared project room are good ways to do this. Solo developers communicating by email is a very bad way to do it; if you're in that condition, XP is a bad choice. So if you have to work on multiple projects in an XP context, you have to rigidly schedule things so that, e.g., all the work on Project A happens in the mornings, and all work on Project B happens in the afternoons.
I'll argue the other way: The lowest skilled team member will drag the team and the project down.
It depends on what you mean by lowest skilled. If you mean "fresh out of school with little experience", then you try to make sure that the novice gets paired up with senior developers for a while. At first, they'll have little to contribute (e.g., "You missed a semicolon") but quickly they become more productive.
If, on the other hand, you mean "never likely to be a good programmer", then yes, they are bad for the project and should be fired. But even in this case, pair programming, good unit tests, shared code ownership, and strong version control limit the damage one rogue idiot can do much more than on a project that doesn't use these techniques.
3. Well targeted goals.
I agree that this is good to have, but it's much less of a problem on an XP project than, say, a traditional Waterfall lifecycle project. A frequent release schedule (XP recommends every 1-3 weeks) is the key. Everybody gets together and sets the goals for the first version. In a couple of weeks, everybody gets together and says "Oh! Now we see that we should really be going Y instead of X" and so you code the next revision that way. When goals are poorly understood, Evolutionary Delivery lifecycles are great for reducing risk.
Clearly, you didn't read the book.
Beck makes pretty clear that the XP model is not for everybody. He even has a chapter titled When You Shouldn't Try XP.
He also makes many of the same points you make; especially that understanding customer needs is crucial. He goes further to say that the only will way to understand customer needs is to involve them (or, as you say, their representatives) closely in the development process, so that you have lots of feedback.
Because XP has a lot in common with the Evolutionary Delivery lifecycle, it also substantally reduces budget-related risk. Since you are regularly producing high-quality working versions that have successively more features, you always have something to deliver.
So I agree that 'silver bullet' solutions are bad but I disagree that XP is such a solution. It's just a collection of development techniques that are, for the most part, entirely uncontroversial. The only new thing is the emphasis on combining them in a way that they reinforce one another.
I agree that if you have an evil (or willfully clueless) manager, no book will help. But there are a lot of people who manage software projects (or who manage people who manage projects) that are ignorant but willing to learn, especially if it means the difference between success and failure. And for those people, sticking a few books under their noses will help a great deal. For these managers, I give away copies of Rapid Development or The Software Project Survival Guide depending on how technical they are. And if your project is suited to an XP approach, then a book explaining the business case for using XP will help them understand why they should back you, rather then meddling with things they don't get.
the supposed way to go is not to be looking ahead to the next problem
Yeah, this bugged me, too.
The way they talk about it is in pretty absolute terms. Don't look ahead, just focus on the immediate concern, etc, etc. It sounds ridiculous, and when you take it literally, it is ridiculous.
But after a little while, I began to see the problem they were trying to address. It's very easy to say things like "well since we need to display one graph, we should build a whole graphing framework, as we'll probably need to do more graphs eventually." And then you go off and spend a month building a (very nice, very solid) graphing framework for your one graph. But it was fun and interesting and the Right Way To Do Graphing, so you feel good about your work. And once they ask for more graphs, you'll be golden.
But then it turns out that nobody ever asks for more graphs, and so your nice framework never gets used. Worse, people don't use the program much because it's missing features that they need, features that you could have added in that month. So the project gets cancelled and your code goes to waste.
So their point is not don't do work that you need 15 minutes from now but more like don't do work that you won't need for a month. You just figure out what you need to get this version finished and code that. That doesn't mean writing shoddy code to get it out the door, of course; you write good, solid stuff, but nothing more than you need. When the next revision comes, then code that then.
If you haven't experienced refactoring, this still seems ridiculous. But if you already have an lot of unit tests and functional tests, you become confident that you can improve your design incrementally and still have everything work. Which means that painting yourself into a corner is not the problem that it was before.
Personally, I am still getting used to this. But so far it has worked pretty well.
Having tried some of the XP methods, it's my impression that they don't have to be followed precisely, but you do have to be true to the spirit of them. Most of them are valuable on their own, but some methods are dangerous if used wrongly.
One of the important elements of XP is indeed continuous unit testing, integrated into the process. Another is continuous customer involvement. A third is short release cycles. All of these drastically improve feedback, which is a vital underpinning to many of the other techniques.
But another vital component is a good team, one where this is mutual respect and a strong sense of shared goals. In the situation above, people were allegedly wrecking one another's code; this either suggests incompetence or internal political struggles that get expressed in the code. Either way, it's a massive management failure to let rogue workers run unchecked.
XP should absolutely not be used in a group of people that is not working as a team. XP is a process that requires people with a sense of community. 90% of the programmers I know have this. 99% of the good programmers I know have this. But if a manager tries to impose XP, she must do it only with people who can play well with others.
Personally, I'd use some sort of scripting environment, probably Perl, for all of the prototyping, playing around, data translation, and glue work.
And then for serious stuff, I'd use something more structured and formal. Personally, I like Java; it's well known, pretty well supported, good at handling errors, has a reasonable amount of network stuff built in or available, and from the beginning had threading in mind. But I would certainly use some sort of OO language for this, as this kind of work strikes me as well-suited for an OO approach.
Oh, and do your work incrementally! Avoid grand plans; code in an exploratory fashion. If you're doing OO work, the book Refactoring is a great one. And if you're doing incremental design in Java, you will soon grow addicted to unit testing; I have grown to love JUnit, a Java unit testing framework.
But if this is mainly for your own use, use whatever tools you are most familiar with. I find that tackling a new tool and a new problem domain at the same time is generally too much to allow quality work. New problem? Old tool. New tool? Old problem first!
Whatever, boss. The site is pretty clearly Milloy's project. And the whois record still lists him as the owner. So the fact that a number of big polluters pay his bills is still relevant, even if he isn't doing the day-to-day work.
And speaking of which, according to you, who is? And what's your evidence for claiming that Milloy's not in charge?
Junkscience.com isn't a mouthpiece for anyone.
As another poster pointed out, the latter half of this article claims that the author of junkscience.com was a registered lobbyist for several large firms with dubious environmental records. And at the same time he has been running this website, he was executive director of a (now defunct) non-profit that had members including "Amoco, Chevron, Dow Chemical, Exxon, General Motors, [...] the National Pest Control Association, Occidental Petroleum, Philip Morris" and so on.
You can verify his lobbyist registration here.
Conveniently, the fact that large polluters have been paying his bills for the last several years isn't mentioned on the "about the author" section of his web site. Maybe he's an entirely disinterested scholar who just happens to be funded by a lot of people with a financial interest in opposing environmental regulation, but I'm not convinced.
Bad science sure does happen, but a guy with a financial interest in the outcome is not one I'll take very seriously on the topic.
Actually, I was looking for specific cites for the "facts" of the poster I was responding to. But thanks for the references!
As much as I love the work various libertarian think tanks on social policy and on the theoretical point of government, I'm not very impressed with their output on matters of fact, especially ones where the facts are hard to read.
Here I think their (obvious and admitted) biases are too strong for them to look dispassionately at the facts. Especially when one conclusion would cause them to recommend forcing people to participate in large-scale collective projects of a kind that they clearly abhor. And their claim that scientists might bias their results to get grants, while not entirely without merit, is the pot calling the kettle black. How much do you think CATO's donations would drop if they came out with a book titled "Why We Need A One-World Government To Stop Global Warming?"
At the same time, I find it disconcertaining that a lot of environmental rhetoric has a tremendous amount of counter-cultural, anti-corporate, 'fuck the man'-type reasoning that I have a hard time taking seriously.
As a small business owner living in the People's Republic of San Francisco, I feel your pain. Around here, people have vaguely heard of a market economy, but they are pretty unclear on the workings of it.
But the legitimate gripe in that anti-corporate rhetoric is that modern corporate culture is strongly biased towards relentlessly short-term extraction of cash. In its place, this is great, but without appropriate counterbalancing forces, it leads to insane behavior. An example popular with the greens is environmental dumping; for slashdot, the example is spam. Both impose huge costs on everybody for small benefit to a few individuals.
Personally, I don't see why the conservatives don't use this as a prime opportunity to rejig the tax system. Put in place various emissions fees and resource extraction taxes and you could use those to get rid of the the income and capital gains taxes. If we're going to be taxing something, I'd rather tax something unarguably bad (pollution and non-renewable resource consumption) than something pretty good (economic activity and value creation).
Unfortunately, the people pushing this are the true believers. Their beliefs and plans have a fanatical religious quality. Fanaticism doesn't tend to lead to good decision making.
Yeah, I find it kind of wearying myself. It would be nice to see more measured debate on this. I find it hard to trust anybody involved.
Of course, humans beings have an immense and well-demonstrated capacity to ignore anthing that isn't currently biting them in the ass. And American culture doesn't do anything to mitigate this; we are relentlessly focused on the short term.
So if, hypothetically, after careful review of the evidence you decided that global warming was happening, you can see that the shrillness of many environmental activists is a reasonable (if mainly useless) reaction to the fact that the nation that pollutes the most collectively said "so what?" and went out and bought a bunch of SUVs.
It's entirely true that complete, specific prediction of real-world "coupled non-linear chaotic system[s]" is not possible.
But look at US economy and the financial markets which are similarly complex, coupled, non-linear, and chaotic. We can make a few observations:
I agree that much more research is needed, but the notion that CO2 emissions could cause devestating climactic change is theoretically plausible, and a lot of reasonable scientists have concluded that it is happening.
In light of that, wouldn't it be at least reasonable to start hedging our bets?
You got some credentials, pal? Some evidence? Some references? Or are you just running your mouth?
First of all, reducing C02 doesn't really lower greenhouse gases. The biggest greenhouse gas is water vapor, making up 98% of all greenhouse gases.
Yeah, and your heart is only two percent of your body mass. So I guess taking it out wouldn't really lower your functioning, eh?
during the 60s, people worried about a global cooldown.
Yeah, and the shining product of computer science in the 60s was COBOL. So what? In last 30 or 40 years, a lot of new work has been done and a lot of new data unearthed. Oh, and they now have these fancy thingies called computers for working with all of this data. It would be reasonable to think that climatology, like every other science over the last few decades, has improved some.
Third, global temperature depends on where you measure temperature.
This effect is known and can be corrected for. And it has no effect on other ways of measuring historical temperatures, like ice cores and tree rings.
Statistics lie, that's what they're good for.
Spoken like a guy who's never taken a stats class. Statistics, like any other tool, can be wielded wisely or foolishly.
Lastly, scientists don't agree on global warming.
And not all scientists agree on evolution. Does that mean we should just turn the schools over to the fundamentalists?
There was a similar conference earlier this year where scientists decided that they couldn't come up with a solid decision on global warming.
Really? I heard there was a conference earlier this year where scientists decided you were a dork. Talk is cheap, pal; if you want to be taken seriously, give links and references to support all of your assertions of alleged fact.
My employer (who, like me, shall remain nameless) used Viant. What a complete fucking disaster. They couldn't be bothered to really understand what we were doing, or sometimes what their predecessors had done. They had lots of meetings to discuss The Process. The Process involved many, many more meetings [...]
Facinating! (Hey moderators! Moderate the AC post up so others can see the whole thing.) This sounds a lot like Verde.com's experience with sound-alike consulting shop Scient, at least as told in the article How Scient helped Verde.com go from launch to bankruptcy in less than 60 days. And everybody there had to remain anonymous, too.
I broadly agree that putting somebody else in charge of the very heart of your business is a dangerous thing, and I generally discourage it. But people can also tell in-house development disaster stories, so that's no silver bullet. Indeed, I've seen projects fail because management couldn't resist meddling in in-house projects. An external vendor has more power to deflect or channel insane client demands; that power can be very beneficial to a project if used wisely.
One important distinguishing factor is whether or not you have a lot of ongoing development needs. Some projects have a huge amount of inital work and then a much smaller amount of ongoing work; it doesn't make sense to build up a big in-house staff, get them to work as a team, train them to your needs, and then fire half of them when the project is done.
On the other hand, most clients (and non-technical bosses) tend to overestimate the need for a big initial push and underestimate the need for ongoing work. As any developer knows, what people initially imagine they want and what they actually end up wanting once they've been through several iterations of development are usually pretty different. And if you're doing a web site or other Internet-delivered service, you can usually roll new features out gradually, further reducing the need for a huge initial dollop of work. So if your project can use an evolutionary delivery model building an in-house staff can make a lotta sense.
For people interested in these topics, I recommend Steve McConnell's Software Project Survival Guide. And if you're a developer, project manager, or somebody else actually working on a project, his Rapid Development is also great. And hey! I hadn't seen this before, but he wrote a magazine article on Managing Outsourced Projects.
Both options are reasonable choices; both have their risks. The right answer depends on the details.
If you want a useful answer, you have to tell us a lot more. Start with your company's experience and resources. Have you managed outsourced development before? Do you have developers in-house to manage and check their work? Do you have experience in hosting and managing the application if you outsource development?
Then tell us about your business plan and goals. Which set of risks would be worse for your business if the worst happens? How much change do you expect in your requirements? (It's rare that the requirements at the start of the project are the same at the end.) How do you guarantee that once you have v1.0 that you can move to v1.1 and v2.0 without starting from scratch? How likely are your future needs likely to diverge from the ASP's main market?
Then tell us about the different vendors. What kind of reputations to they have? What kind of guarantees will they be willing to make? What are their portfolios like? If they screw up, do they have the resources needed to do it over for free? Will they let you talk to a client where they've done that? If a vendor goes bad, what plans do you have to migrate your clients and your data to a new system?
It sounds like you already broadly know the risks and potential rewards of the two paths; the right choice depends entirely on the details. And if you don't want to give the details to the public, than maybe you should (ahem) hire some of us to help you sort it out.
I will likely give it a try. But there are several plausible reasons why people won't do it.
- They don't believe it will work - Up until now, I'd never heard of anyone saying that it worked well, and I've heard complaints that it didn't. And since the general job of marketers is to lie, you can see how people would be skeptical.
- It's more fun - You say you keep getting junk mail because it's entertaining. And then you complain that Taco, et al, keep getting junk mail because they entertain themselves with it. You waste $0.50 of the advertiser's money; they waste $0.80. Your high horse looks more like a small pony to me.
- Civil disobedience - I would bet that if we put it to a national referendum, junk mail, telemarketing, and spam would be outlawed tomorrow. The DMA and large businesses spend a lot of money keeping junk mail legal, and generally advocating for maximally intrusive marketing. As an individual citizen I can (and do) write my congressman from time to time, but I don't have a lot of faith that my letter means a lot compared to their money. Making it more expensive for them strikes at the heart of this: they only do it because they make a buck on it; once it's not profitable, they'll stop.
- It sends a message - Most marketroids believe that intrusive marketing is acceptable to the recipient. This lets them know that some of us think it's rude.
Before this came up, I just recycled all my junk mail, but I'm beginning to think that sending it back is a better idea.