Enron failed because they had a business model based on buying and selling of GOVERNMENT pollution credits and other fabrications of government which failed to be legislated into existence.
I can't fairly evaluate the rest of your post, but I hope it's more accurate than this.
Enron failed primarily because of pervasive accounting fraud, although their overspending on things like bandwidth trading and the outright theiving of people like Andrew Fastow sure didn't help. To anybody who knows the first thing about accounting, the shit they got up to was stunningly foolish. Both their execs and their auditors deserve to spend a decade in the pen. For those interested, a very readable account is Power Failure.
The market worked. Their accounting firm was demonstrated to be corrupt and it failed too. This is what happens in a free market, bad companies fail. To call that a "bad thing" it to try to argue that corrupt, inefficient, or just plain badly run businesses should not fail.
The problem here is with a very long feedback loop, which allows the consequences of failure to be very large.
It can take years for a carefully run fraud to be discovered. It's hard enough to evaluate a company that is disclosing things fully; it's beyond the means of most investors to evaluate a company that has room to lie. For public markets to function well, it's essential that the information companies give to their investors be clear and correct. Otherwise people will put their money in less productive but safer places, like mattresses or government bonds.
I don't think anybody wants to keep companies from failing. But I want companies to report risks and failures honestly. That lets me invest with confidence, and it helps keep little problems from snowballing into big ones.
"Globally aware" people are the kinds that voice thier uneducated opinions about something they don't know. [...] If more people just stuck to being "me-centric" the world would be a better place.
While the logic of the researchers' interpreter tackles only about 20 percent of the problem of full natural language programming, it achieves about 80 percent of the perceived rewards.
Ah, this old thing again.
The hard part about programming isn't turning basic English text in to half-assed code. If it were, then Google have built their company on just-out-of-college scripters and Visual Basic.
[Liu says] "Many subjects immediately identified the simplistic interpretation of the interpreter, and wanted the opportunity to rephrase their original wording to fix the error."
Yes, regular English is insufficient for programming. If a tool like this becomes popular, you'll need still need a special class of people to figure out what is needed and to figure out how to phrase the desire in the precise way that makes this guy's interpreter actually do what they want.
In other words, he hasn't invented a way to eliminate programming or programmers. He's figured out a way to make a programming language that is slightly easier to learn at first. But because it's removed from what computers actually do, much harder to use for anything serious. The hard part about programming isn't the month you spend learning Java syntax, it's the many years you spend learning to write code well.
Their theory appears to be that this will make programming easier to learn. I wish them the best of luck in that goal, but having seen over the years a number of graphical and natural-language programming tools vanish without a trace, I'm not holding my breath.
Are you suggesting that drag and drop programming is a good thing? Maybe it allows for faster implementation but it provides much slower and far more stupid solutions than true programming. I am not even sure that it can be consider true programming.
The problem with tools like that isn't that they aren't really programming. (I agree; they aren't.) It's that people mistake one for the other because for simple projects the results look the same. Because of that, marketroids shamelessly sell low-end, user-targeted tools as equivalent to real code written by professional programmers.
All those companies that went for the easy way out in '97 deserve to suffer the consequences.
True. On the other hand, there are an awful lot of VB apps, Access apps, Perl CGI scripts, and shell scripts that are just fine for the people using them, and always will be.
The problem comes when people try to push tools like that beyond their limits. And no matter how much warning you give that your quick little hack will need to be replaced eventually, people forget that because it *looks* solid. My favorite solution is to make quick hacks look like quick hacks. It's a shame all VB apps don't look like that.
Daimou has indicated that the manager led him to understand the code would remain his, providing such consent, so do emphasize: "...in WRITING."
I strongly agree. And note that this generally doesn't have to be any sort of dramatic signed contract.
After your boss says ok, just go back to your desk and send him a short email summarizing the conversation. Of course, only a lawyer can tell you whether that's legally sufficient under the terms of your contract to let you prevail in court. But from practical experience I can say that having something in writing like that can nip an awful lot of problems in the bud, long before they get to the duelling lawyers stage.
Actually IMO the fact that you are able to sign away rights on something you create in your free time in the first place shows a severe flaw in the system.
Yes, it would be terrible if I could write some software in my free time and then sell it to a publisher.
It could be seen as the company trying to claim ownership of things which he did while employed at another company in the past.
Without seeing the contract, we can't know for sure. But when I've seen contracts like this, you promise the new employer that you won't use or tell them things that belong to other people. So it's likely that if there's a GPL violation here and the original poster's company gets spanked, they can turn around and sue him for breach of contract, as he promised to only give them IP that he was allowed to give them.
Of course, they'd be fools to do that. Unless they're trying to get something else out of him, then he probably doesn't have deep enough pockets to make him worth suing.
So according to you the problem with robbing and plundering is "that it's not a sustainable business model" and that to rob those with the most money would require facing military force?
Hi! I'm delighted that you read the first line of my post. However, your response would have been more productive had you read the rest of it.
My point was that most of the apparent contradictions of capitalism, democracy, and respect for human rights are illusory, and that in the end they are pretty compatible. Short-sighted capitalists rob, but that's not nearly as profitable in the long run as playing nice. Short-sighted people on the other side rail against capitalism, while failing to notice the correlations between capitalism, national wealth, democracy, and respect for human rights.
I agree utterly that robbing and plundering harms others, and that's why we shouldn't do it. My statement was meant to convey that even one's only goal were to make money, they still shouldn't rob and plunder. But I guess you're a little worked up, so maybe the joke was too subtle.
Think about this: If Google is "in the business of making money", not in the business of helping people "find things on the internet", then what are they bothering with all that search engine nonsense for? Wouldn't their duty be to rob and plunder, as the directest route to the cash?
The main problem with robbing and plundering is that it's not such a sustainable business model. There are a limited number of organizations that you can rob $2 billion a year from, and most of them have tanks.
What you and the people you criticize both miss is that with sufficiently large time horizions, being nice and being selfish can be the same thing.
Nature, much more vicious than even the most heartless Harvard MBA, produces incredible amounts of cooperation and altruism. The reason that humans dominate the planet isn't really our ability with language or with tools; it's that we can cooperate on a scale that dwarfs your average ant colony. Google, partly because of their decision to play nice, crushed most of the competition.
Internet access is a "nice to have" convienence but hardly a public necessity (like roads, schools, etc.).
I disagree with that. Schools and libraries are essential to the functioning of a democracy because they help prepare voters. But schools and libraries aren't enough; voters also need fresh information and avenues for participation. This last election showed that the internet is shifting power back to individual citizens, but we'll never see the full flowering of that until access is pretty much universal.
That doesn't mean that the government should promise a T1 in every pot. But it's perfectly possible for cities to provide moderate, limited wireless internet access without noticeably harming the market for wired or wireless broadband. That will allow for all sorts of community coordination, distance learning, self-directed education, and citizen participation that today are restricted to the well off.
No real libertarian would support a govt based wireless muni network.
Real libertarians can support prudent and limited subsidies for internet access for the same reason they can support public libraries and public education: voting is a fundamental right, but it only is meaningful or workable if voters are educated and informed.
Of course, by "real libertarian" I'm assuming you mean a person who would like to see libertarian principles applied in the real world, and not just in badly written novels.
No telcom company will want to compete with your "free" but lousy network.
That is just ridiculous.
Companies compete with free but lousy things from the government all the time. I buy books, movies, and music even though there's plenty available at the library. Private schools make money despite free public schools. Toll roads exist even though they only take you places free roads go. I have a porch light even though there's a street lamp out front. Right next to free public drinking fountains you can find stores selling bottled water. Private security companies don't seem to be bothered by government-subsidized police. And so on, and so on.
There is no reason to think that any practical version of municipal wireless will stifle the increase of high-quality connectivity one tenth as much as obstructionist semi-monopolies like SBC and Comcast do.
No one is going to go back to VHS quality just because they can download it faster over the Internet.
Maybe I'm unusual but I'm perfectly happy with download-quality video for most movies. When I rent something and don't watch it before I return it, I'll sometimes copy it to CD until I get the time. It seems fine to me on my mid-range gear. For the kinds of things where picture quality really matters (like, say, a Peter Greenaway film) I'd rather see it in the theater anyhow.
What I really want is a cross between a theater, a bar, and a video store. Imagine a place with a variety of different sized rooms, from 2 seats to 30, all of them equipped with kick-ass AV. Up front, they have beer on tap and good stock of movies and console titles. There's no way I'll drop a few grand on a system I use five hours a month, but I'd happily rent out a room so I and a dozen pals can do a movie night.
What happens when IntelliJ stops supporting your version of IDEA and you have to upgrade with money you don't have? Etc.
I generally prefer open tools as well, but I think you take this too far.
My time is worth something, both to me and to my clients. If using commercial tools let me get sufficiently more done, then they pay for themselves. For personal projects, of course, there's no requirement to be efficient (although it's probably a good idea). But for client work, I feel like there's obligation to trade money for time if it results in a net money savings for them.
And IntelliJ's IDEA in particular is a good deal. Their base license prices are very reasonable, and every year they have a sale on personal licenses where you can get it for a couple hundred bucks. For me, I've probably paid 15 cents per hour that I've used IDEA. I'm glad to help support guys that do such good work.
If this is how you judge technology you'll never jump on a new thing, because the existing one has broader support, more developers, more employers etc. Stupid stupid stupid!
Hi! It looks like you've run out of your meds. Perhaps you should see if your pharmacy has auto-refill service available.
You'll note that I didn't say that those are the only factors one should ever consider. I just said that those are why I currently use Java over C#.
For my hobby projects, I'm perfectly glad to use weird or cutting-edge stuff. But for work for my clients, I think it's vital to take business factors into account. It's very rare that an ultra-new technology provides so much business benefit that it completely outweighs things like vendor support, tools support, and being able to find people who know the tech.
I agree completely that we techies should collaborate vigorously. I also agree that letting salespeople control the product plan, especially when they arbitrary schedules based on their own fantasies, is a mistake.
But I disagree that techies are qualified, simply on the basis of raw intelligence, to make business decisions. A good product manager is just as smart as the programmers. There's no reason to think they could step in and dictate development, just like there's no reason to think that your average developer is qualified to do all the things a good product manager does.
If you've been working with dumb product managers or salesmen who think they can pretend to be product managers, that's the problem you should solve.
There is no agile way of producing this documentation.
XP teams have been blessed up to CMM level 3 with only minor additions. See the papers from Agile conference proceedings (and also from CMM people like Mark Paulk) for details.
There are indeed plenty of relatively agile ways to produce necessary documentation. It's the unnecessary documentation, the stuff that nobody ever reads, that agile methods tend to leave out. But I'd say that leaving out pointless work is a process feature, not a process bug.
The telephone game only applies when there's no redundancy, no verification of transmission, and mindless repetition of received transmissions. On an XP team, everybody's in the same room and talking, over time, to everybody else. If I hear one thing from one person and one from another, I'll grab 'em both and we'll work it out.
Often we do that by turning to the product manager, who sits in with the developers so that they can provide immediate answers to things that would indeed otherwise turn in to telephone-game nonsense.
That's a reasonable theory. It sure doesn't sound like my XP experiences. Perhaps you can tell me more about how they did XP.
felt like I was often having to interpret and 'guess-timate' a lot.
Extreme Programming requires an on-site product manager. Why would you have to guess if the guy who can decide is ten feet away? And if the product manager was, as XP recommends, defining the acceptance tests, where was the room for mystery?
the apps tended to have a lot of bugs
Extreme Programming requires two levels of testing (acceptance tests and unit tests) and continuous code review (via pair programming and collective code ownership). Further, with weekly iterations and frequent releases, both the product manager and the end users should be seeing running code on a regular basis. My last few XP projects have all been under one bug per developer-month.
At your shop, how do you feel those bugs slipped past all those safeguards?
things always went late
In XP the project is generally time-boxed, and data from early iterations is used to come up with the final plan. Thus, features get added or removed to make a date. On the projects I've been on, velocity has generally plateaued in the first 6-8 weeks, which gives you good data to predict the rest of the schedule. How was your project different?
And it's frustrating for a team to be in the hotseat when there's no document saying 'it says right here, you promised X by date Y.'
Take a look at some XP teamrooms. As you can see, the plan in these is on the wall for everybody to inspect. And the plan should be updated every week through a joint effort by the product manager and the rest of the team.
I'm curious is XP 'sold' as working on large apps, or is it really most suited to smaller projects, and/or minor enhancements to existing applications ?
It's sold as working for teams of up to 12 for both new and old development for projects of indefinite duration (but generally a minimum of a couple of weeks). Some people have it working with many more people, either through larger teams or through many collaborating teams.
But really, it sounds like the places you describe weren't doing XP. Perhaps you could look through a list of XP practices and tell us how many were used on the projects you saw?
This may seem like pie in the sky and "hardened" devs are sure to line up telling me it never really happens that way. However, I know for a fact that it does.
Having tried Extreme Programming, I can testify. On a recent project, we had pretty much 100% test coverage. After 36 developer-months of happy construction and no formal QA, we released to the public and have had a total of 2 bugs in production and zero downtime in the five months since launch. The CEO, a Silicon Valley veteran, said he's never seen anything work so well.
The code is excellent, and the test cases do indeed clearly document what things are for. The unit tests explain the code from the developer perspective, and the acceptance tests say what the product manager thinks the project should do. Aside from a stack of story cards,some HTML mockups, and the product manager in the room, the tests were all the spec we needed.
Of course, hardened developers won't believe me either until they give it a fair try. My bet: sincerely try the full set of XP practices for eight weeks, and you'll keep at least 80% of them. Yes, pair programming included.
Most developers can make software that the cutomer wants if they actually talked to the customer, but sales and marketing people somehow think that developers don't have perople skills to deal with customers... it is a sad world when someone with a business degree tries to make a technical decision.
Quick tip: what to make isn't a technical decision; it's a business decision. HOW to make it is the domain of us techies.
Slashdot Mirror
Enron failed because they had a business model based on buying and selling of GOVERNMENT pollution credits and other fabrications of government which failed to be legislated into existence.
I can't fairly evaluate the rest of your post, but I hope it's more accurate than this.
Enron failed primarily because of pervasive accounting fraud, although their overspending on things like bandwidth trading and the outright theiving of people like Andrew Fastow sure didn't help. To anybody who knows the first thing about accounting, the shit they got up to was stunningly foolish. Both their execs and their auditors deserve to spend a decade in the pen. For those interested, a very readable account is Power Failure.
The market worked. Their accounting firm was demonstrated to be corrupt and it failed too. This is what happens in a free market, bad companies fail. To call that a "bad thing" it to try to argue that corrupt, inefficient, or just plain badly run businesses should not fail.
The problem here is with a very long feedback loop, which allows the consequences of failure to be very large.
It can take years for a carefully run fraud to be discovered. It's hard enough to evaluate a company that is disclosing things fully; it's beyond the means of most investors to evaluate a company that has room to lie. For public markets to function well, it's essential that the information companies give to their investors be clear and correct. Otherwise people will put their money in less productive but safer places, like mattresses or government bonds.
I don't think anybody wants to keep companies from failing. But I want companies to report risks and failures honestly. That lets me invest with confidence, and it helps keep little problems from snowballing into big ones.
"Globally aware" people are the kinds that voice thier uneducated opinions about something they don't know. [...] If more people just stuck to being "me-centric" the world would be a better place.
I hope to god you're being intentionally ironic.
While the logic of the researchers' interpreter tackles only about 20 percent of the problem of full natural language programming, it achieves about 80 percent of the perceived rewards.
Ah, this old thing again.
The hard part about programming isn't turning basic English text in to half-assed code. If it were, then Google have built their company on just-out-of-college scripters and Visual Basic.
[Liu says] "Many subjects immediately identified the simplistic interpretation of the interpreter, and wanted the opportunity to rephrase their original wording to fix the error."
Yes, regular English is insufficient for programming. If a tool like this becomes popular, you'll need still need a special class of people to figure out what is needed and to figure out how to phrase the desire in the precise way that makes this guy's interpreter actually do what they want.
In other words, he hasn't invented a way to eliminate programming or programmers. He's figured out a way to make a programming language that is slightly easier to learn at first. But because it's removed from what computers actually do, much harder to use for anything serious. The hard part about programming isn't the month you spend learning Java syntax, it's the many years you spend learning to write code well.
Their theory appears to be that this will make programming easier to learn. I wish them the best of luck in that goal, but having seen over the years a number of graphical and natural-language programming tools vanish without a trace, I'm not holding my breath.
Are you suggesting that drag and drop programming is a good thing? Maybe it allows for faster implementation but it provides much slower and far more stupid solutions than true programming. I am not even sure that it can be consider true programming.
The problem with tools like that isn't that they aren't really programming. (I agree; they aren't.) It's that people mistake one for the other because for simple projects the results look the same. Because of that, marketroids shamelessly sell low-end, user-targeted tools as equivalent to real code written by professional programmers.
All those companies that went for the easy way out in '97 deserve to suffer the consequences.
True. On the other hand, there are an awful lot of VB apps, Access apps, Perl CGI scripts, and shell scripts that are just fine for the people using them, and always will be.
The problem comes when people try to push tools like that beyond their limits. And no matter how much warning you give that your quick little hack will need to be replaced eventually, people forget that because it *looks* solid. My favorite solution is to make quick hacks look like quick hacks. It's a shame all VB apps don't look like that.
Daimou has indicated that the manager led him to understand the code would remain his, providing such consent, so do emphasize: "...in WRITING."
I strongly agree. And note that this generally doesn't have to be any sort of dramatic signed contract.
After your boss says ok, just go back to your desk and send him a short email summarizing the conversation. Of course, only a lawyer can tell you whether that's legally sufficient under the terms of your contract to let you prevail in court. But from practical experience I can say that having something in writing like that can nip an awful lot of problems in the bud, long before they get to the duelling lawyers stage.
Actually IMO the fact that you are able to sign away rights on something you create in your free time in the first place shows a severe flaw in the system.
Yes, it would be terrible if I could write some software in my free time and then sell it to a publisher.
It could be seen as the company trying to claim ownership of things which he did while employed at another company in the past.
Without seeing the contract, we can't know for sure. But when I've seen contracts like this, you promise the new employer that you won't use or tell them things that belong to other people. So it's likely that if there's a GPL violation here and the original poster's company gets spanked, they can turn around and sue him for breach of contract, as he promised to only give them IP that he was allowed to give them.
Of course, they'd be fools to do that. Unless they're trying to get something else out of him, then he probably doesn't have deep enough pockets to make him worth suing.
Sorry, I mistook you for somebody who was here to have a discussion, rather than just grandstanding. I'll try not to make that mistake in the future.
So according to you the problem with robbing and plundering is "that it's not a sustainable business model" and that to rob those with the most money would require facing military force?
Hi! I'm delighted that you read the first line of my post. However, your response would have been more productive had you read the rest of it.
My point was that most of the apparent contradictions of capitalism, democracy, and respect for human rights are illusory, and that in the end they are pretty compatible. Short-sighted capitalists rob, but that's not nearly as profitable in the long run as playing nice. Short-sighted people on the other side rail against capitalism, while failing to notice the correlations between capitalism, national wealth, democracy, and respect for human rights.
I agree utterly that robbing and plundering harms others, and that's why we shouldn't do it. My statement was meant to convey that even one's only goal were to make money, they still shouldn't rob and plunder. But I guess you're a little worked up, so maybe the joke was too subtle.
Given that, I can't tell you how pleased I am to discover that I'm not a real Star Trek fan.
Think about this: If Google is "in the business of making money", not in the business of helping people "find things on the internet", then what are they bothering with all that search engine nonsense for? Wouldn't their duty be to rob and plunder, as the directest route to the cash?
The main problem with robbing and plundering is that it's not such a sustainable business model. There are a limited number of organizations that you can rob $2 billion a year from, and most of them have tanks.
What you and the people you criticize both miss is that with sufficiently large time horizions, being nice and being selfish can be the same thing.
Nature, much more vicious than even the most heartless Harvard MBA, produces incredible amounts of cooperation and altruism. The reason that humans dominate the planet isn't really our ability with language or with tools; it's that we can cooperate on a scale that dwarfs your average ant colony. Google, partly because of their decision to play nice, crushed most of the competition.
Internet access is a "nice to have" convienence but hardly a public necessity (like roads, schools, etc.).
I disagree with that. Schools and libraries are essential to the functioning of a democracy because they help prepare voters. But schools and libraries aren't enough; voters also need fresh information and avenues for participation. This last election showed that the internet is shifting power back to individual citizens, but we'll never see the full flowering of that until access is pretty much universal.
That doesn't mean that the government should promise a T1 in every pot. But it's perfectly possible for cities to provide moderate, limited wireless internet access without noticeably harming the market for wired or wireless broadband. That will allow for all sorts of community coordination, distance learning, self-directed education, and citizen participation that today are restricted to the well off.
No real libertarian would support a govt based wireless muni network.
Real libertarians can support prudent and limited subsidies for internet access for the same reason they can support public libraries and public education: voting is a fundamental right, but it only is meaningful or workable if voters are educated and informed.
Of course, by "real libertarian" I'm assuming you mean a person who would like to see libertarian principles applied in the real world, and not just in badly written novels.
No telcom company will want to compete with your "free" but lousy network.
That is just ridiculous.
Companies compete with free but lousy things from the government all the time. I buy books, movies, and music even though there's plenty available at the library. Private schools make money despite free public schools. Toll roads exist even though they only take you places free roads go. I have a porch light even though there's a street lamp out front. Right next to free public drinking fountains you can find stores selling bottled water. Private security companies don't seem to be bothered by government-subsidized police. And so on, and so on.
There is no reason to think that any practical version of municipal wireless will stifle the increase of high-quality connectivity one tenth as much as obstructionist semi-monopolies like SBC and Comcast do.
No one is going to go back to VHS quality just because they can download it faster over the Internet.
Maybe I'm unusual but I'm perfectly happy with download-quality video for most movies. When I rent something and don't watch it before I return it, I'll sometimes copy it to CD until I get the time. It seems fine to me on my mid-range gear. For the kinds of things where picture quality really matters (like, say, a Peter Greenaway film) I'd rather see it in the theater anyhow.
What I really want is a cross between a theater, a bar, and a video store. Imagine a place with a variety of different sized rooms, from 2 seats to 30, all of them equipped with kick-ass AV. Up front, they have beer on tap and good stock of movies and console titles. There's no way I'll drop a few grand on a system I use five hours a month, but I'd happily rent out a room so I and a dozen pals can do a movie night.
What happens when IntelliJ stops supporting your version of IDEA and you have to upgrade with money you don't have? Etc.
I generally prefer open tools as well, but I think you take this too far.
My time is worth something, both to me and to my clients. If using commercial tools let me get sufficiently more done, then they pay for themselves. For personal projects, of course, there's no requirement to be efficient (although it's probably a good idea). But for client work, I feel like there's obligation to trade money for time if it results in a net money savings for them.
And IntelliJ's IDEA in particular is a good deal. Their base license prices are very reasonable, and every year they have a sale on personal licenses where you can get it for a couple hundred bucks. For me, I've probably paid 15 cents per hour that I've used IDEA. I'm glad to help support guys that do such good work.
If this is how you judge technology you'll never jump on a new thing, because the existing one has broader support, more developers, more employers etc. Stupid stupid stupid!
Hi! It looks like you've run out of your meds. Perhaps you should see if your pharmacy has auto-refill service available.
You'll note that I didn't say that those are the only factors one should ever consider. I just said that those are why I currently use Java over C#.
For my hobby projects, I'm perfectly glad to use weird or cutting-edge stuff. But for work for my clients, I think it's vital to take business factors into account. It's very rare that an ultra-new technology provides so much business benefit that it completely outweighs things like vendor support, tools support, and being able to find people who know the tech.
I'm not saying you shouldn't use C#, but here are some of the reasons I continue to use Java:
Quitting caffiene was hard for about a week (3 days of headaches and 4 days of craving sodas) but I sleep better and wake up without needing my alarm.
Quick tip: if you taper off caffeine, ending with circa 1/2 cup of soda per day for a few days, you can generally avoid the headaches.
Also, one of the best things I did for my health was to stop using my alarm clock most of the time. That forced me to go to bed on time.
Sorry, I guess my quick tip was too quick.
I agree completely that we techies should collaborate vigorously. I also agree that letting salespeople control the product plan, especially when they arbitrary schedules based on their own fantasies, is a mistake.
But I disagree that techies are qualified, simply on the basis of raw intelligence, to make business decisions. A good product manager is just as smart as the programmers. There's no reason to think they could step in and dictate development, just like there's no reason to think that your average developer is qualified to do all the things a good product manager does.
If you've been working with dumb product managers or salesmen who think they can pretend to be product managers, that's the problem you should solve.
The idea that you can simply "pass words from man to man" is dangerous - if that is what they're saying.
That idea alone is indeed dangerous. In the context of the other XP practices, it works very well.
Let's re-word this a la Imagine...
Yes, if people did as you imagine, it would suck. Fortunately, that's not what happens on a good XP project.
There is no agile way of producing this documentation.
XP teams have been blessed up to CMM level 3 with only minor additions. See the papers from Agile conference proceedings (and also from CMM people like Mark Paulk) for details.
There are indeed plenty of relatively agile ways to produce necessary documentation. It's the unnecessary documentation, the stuff that nobody ever reads, that agile methods tend to leave out. But I'd say that leaving out pointless work is a process feature, not a process bug.
The telephone game only applies when there's no redundancy, no verification of transmission, and mindless repetition of received transmissions. On an XP team, everybody's in the same room and talking, over time, to everybody else. If I hear one thing from one person and one from another, I'll grab 'em both and we'll work it out.
Often we do that by turning to the product manager, who sits in with the developers so that they can provide immediate answers to things that would indeed otherwise turn in to telephone-game nonsense.
perhaps their way of doing XP was flawed
That's a reasonable theory. It sure doesn't sound like my XP experiences. Perhaps you can tell me more about how they did XP.
felt like I was often having to interpret and 'guess-timate' a lot.
Extreme Programming requires an on-site product manager. Why would you have to guess if the guy who can decide is ten feet away? And if the product manager was, as XP recommends, defining the acceptance tests, where was the room for mystery?
the apps tended to have a lot of bugs
Extreme Programming requires two levels of testing (acceptance tests and unit tests) and continuous code review (via pair programming and collective code ownership). Further, with weekly iterations and frequent releases, both the product manager and the end users should be seeing running code on a regular basis. My last few XP projects have all been under one bug per developer-month.
At your shop, how do you feel those bugs slipped past all those safeguards?
things always went late
In XP the project is generally time-boxed, and data from early iterations is used to come up with the final plan. Thus, features get added or removed to make a date. On the projects I've been on, velocity has generally plateaued in the first 6-8 weeks, which gives you good data to predict the rest of the schedule. How was your project different?
And it's frustrating for a team to be in the hotseat when there's no document saying 'it says right here, you promised X by date Y.'
Take a look at some XP team rooms. As you can see, the plan in these is on the wall for everybody to inspect. And the plan should be updated every week through a joint effort by the product manager and the rest of the team.
I'm curious is XP 'sold' as working on large apps, or is it really most suited to smaller projects, and/or minor enhancements to existing applications ?
It's sold as working for teams of up to 12 for both new and old development for projects of indefinite duration (but generally a minimum of a couple of weeks). Some people have it working with many more people, either through larger teams or through many collaborating teams.
But really, it sounds like the places you describe weren't doing XP. Perhaps you could look through a list of XP practices and tell us how many were used on the projects you saw?
This may seem like pie in the sky and "hardened" devs are sure to line up telling me it never really happens that way. However, I know for a fact that it does.
Having tried Extreme Programming, I can testify. On a recent project, we had pretty much 100% test coverage. After 36 developer-months of happy construction and no formal QA, we released to the public and have had a total of 2 bugs in production and zero downtime in the five months since launch. The CEO, a Silicon Valley veteran, said he's never seen anything work so well.
The code is excellent, and the test cases do indeed clearly document what things are for. The unit tests explain the code from the developer perspective, and the acceptance tests say what the product manager thinks the project should do. Aside from a stack of story cards,some HTML mockups, and the product manager in the room, the tests were all the spec we needed.
Of course, hardened developers won't believe me either until they give it a fair try. My bet: sincerely try the full set of XP practices for eight weeks, and you'll keep at least 80% of them. Yes, pair programming included.
Most developers can make software that the cutomer wants if they actually talked to the customer, but sales and marketing people somehow think that developers don't have perople skills to deal with customers... it is a sad world when someone with a business degree tries to make a technical decision.
Quick tip: what to make isn't a technical decision; it's a business decision. HOW to make it is the domain of us techies.