6. Work to get some form of instant runoff system going at the local level. If enough people learn how it works when voting for mayor, we'll have a much better chance of getting it implemented at higher levels.
7. Reject proprietary / DRM formats / tiered internet, etc. in favor of open / neutral standards wherever possible, and in general strive to keep information fungible. Probably the greatest hope we have at present is that we can communicate with others in widespread, distributed networks passing detailed information with relative ease. But that ability is under constant assault and could give way to the TV model (sit down, shut up and watch...but don't record...today's version of "truth") if we don't defend it.
So let me get this straight: A lawyer specializing in constitutional law writes a hundred pages or so about an unconstitutional power grab which threatens the most powerful nation on earth, in which the executive branch is usurping the powers vested in the legislative and executive branches and creating a virtual monarchy, and your responses is...
He's a sock puppet because he has the same first name as another author?
And you feel the need to provide two links support to this astonishing point, both of which say basically "I've never seen him in person, and I know of another guy named Glenn...he must be a sock puppet"?
If you're interested in reading the account of someone who started out pretty much where you are, except that he's an attorney specializing in constitutional law, you might want to check out How Would a Patriot Act
From the back cover:
Glenn Greenwald was not a political man. Not liberal, not conservative. Politicians were all the same and it didn't matter which party was in power. Extremists on both ends canceled each other out, and the United States would essentially remain forever centrist. Or so he thought.
Then came September 11, 2001. Greenwald's disinterest in politics was replaced by patriotism, and he supported the war in Afghanistan. He also gave President Bush the benefit of the doubt over his decision to invade Iraq. But, as he saw Americans and others being disappeared, jailed and tortured, without charges or legal representation, he began to worry. And when he learned his president had seized the power to spy on American citizens on American soil, without the oversight required by law, he could stand no more. At the heart of these actions, Greenwald saw unprecedented and extremist theories of presidential power, theories that flout the Constitution and make President Bush accountable to no one, and no law.
I agree that we are mostly agreeing. The one point where we may possibly differ: you paint a picture of monotonic convergence, where we get steadily closer to "the Truth," which I would agree is a common process in science. But it is not the only way things happen. Just as often, a system of iterative refinements such as you describe must be swept away to make room for a system which is ultimately better but was not seen until after we had progressed some way down the "wrong" road. The whole cycles and epicycles edifice in astronomy comes to mind, as well as cold blooded dinosaurs, or Frege, Whitehead and Russell's royal road to the heart of mathematics etc.
The tricky part about these sorts of things is that you can't tell ahead of time which parts of the structure you're going to have to throw out.
What can I, a person with no political interests--a person that would really rather think that the people in office are there because they're looking out for us, our rights, and our freedoms and not because their short-sightedness is creating a police state--do to stem the tide?
It should be obvious, but I'll spell it out:
Get some political interests
Sticking your head in the sand will not help. So pull it out, shake out the sand, and get involved. And I don't mean you should flip a coin, pick the red team or the blue team, and blindly follow them.
I mean that you should get active in holding your elected officials accountable for their actions, regardless of their party affiliation. Keep up on the issues and be vocal about them. Read and listen to opposing points of view and try to form and propagate valid opinions. Make sure your representatives know that someone is watching them, and follows what they do. If they lie, cheat, steal, or sell you down the river, nail them. Vote them out in the primary if you can, and in the general if you can't. Cross party lines if you need to, because you are far better off with an honest member of the opposing party than one of "your own party" who is willing to sell you to the devil for a few hookers.
And, for that matter, do the same with your news outlets. And your local ballot boxes. If we paid half the attention to keeping the system honest that we do American idol or celebrity babies, we wouldn't have this problem.
The problem that the grandparent pointed out is very real. While we need to assume that "the state of current knowledge" is sound and trustworthy to do any engineering it is fatal to make that assumption in science.
I had a friend who made a minor discovery while in undergrad, simply because he didn't fudge his data in a lab assignment. He got graded down for it, and decided to redo the experiment. When he got the same results, he started asking around and found out that quite a few of his classmates had also gotten the results he had, but written it off to "experimental error" since it didn't match the predicted outcome. He took this back to the professor, and challenged him to actually do the assignment himself. They wound up publishing a joint paper on it, but to me the most interesting realization was that, for all the years that assignment had been given, nobody else had caught the error in the accepted theory.
By all means, if you have to bet on the outcome of any particular situation, go with the current state of knowledge. But if you're asked if our current knowledge is correct in its entirety, bet heavily that it is not. And if observation doesn't match the theory, don't lock yourself into the assumption that the data must be wrong because the theory couldn't possible be.
Unless Florida is even further gone than I suspect, you still need a meeting of the minds for a contract to exist. What makes an oral contract so hard to enforce is that, without some sort of documentation or other evidence, each party is generally considered the most reliable witness to their own state of mind.
"You agreed to give me your house if I washed the dishes!"
"Are you crazy? I never agreed to such a thing! If you'd said that at the time I never would have let you touch the dishes!"
Absent some evidence that both parties understood and agreed to the terms, there isn't any reason to suspect they entered into a contract.
It all depends on your assumptions. Look at Venus. The weather there is dead simple to predict. Heavily overcast, highs in the mid 900's, with poisonous smog in low lying areas
through the weekend.
The only reason the Earth's weather seems hard to predict now is that we haven't (yet) experienced a run-away feedback loop. If you posit that we're starting into one, making accurate daily forecasts thirty years out will be much easier than sticking around to see how well you did.
anyone have any ideas what being hit by a small piece of space junk,..will do to one of these things?
I can't find a link at the moment, but ground tests showed pretty much what you'd expect--it does much better than a metal can, to roughly the same extent as a modern bullet proof vest out performs a suit of (aluminum) armor in a gun fight.
Yes, there are things that will destroy it. But Kg for Kg, Kevlar is a lot better than aluminum foil at protecting you from small, high speed impacts.
Glad you asked. In the spirit of intelligent discourse I chose to politely ignore the blatantly disingenuous comparison you made between market forecasting and project estimation -- a comparison upon which you appear to have based your entire argument. After reading _that_, I'm still not convinced this isn't just a sophisticated troll.
Than I shall return the favour. For what it's worth, I've been a professional software developer for just under thirty years. I've done solo work, been a member of teams, managed teams, and (the hardest) managed people who managed teams. I've worked as a contractor and employee for small businesses and major international corporations. I know whereof I speak.
I started to respond to your points one by one (and will, if you wish) but in reading through them again I realize that we only differ on one key point. I believe that you think I am claiming a gap in our ability to predict the time it will take to develop new algorithms, and that this is the basis for my assertion that predicting software development times is impossible. Based on this assumption, you argue correctly that most software development does not involve designing new algorithms.
But that is not the point I am making.
Suppose we divide all software development projects up into three rough piles.
Trivial projects, where no estimate is needed (or asked for) because everything involved is so well understood and simple that there is nothing to estimate.
Cutting edge projects, which involve the development of new technology, and which we both agree would be foolish to try to estimate.
The rest, which I was calling "non-trivial projects".
I'm assuming that we are both talking about the third sort, in that I excluded the first and you excluded the second, and we both seem to agree that this is where the bulk of real-world software development falls.
In an idealized world, software development of this kind would involve programmers skilled in their art using well understood, throughly and accurately documented hardware and software to meet well understood, clearly and correctly specified needs under constraints that are understood in advance by all parties. Further, once the project started, nothing would change. No one would leave or join the project, no new version of hardware or software would be introduced, new needs would not arise, constraints would not change, etc. In such a world, I will grant, it might be meaningful to talk about sending the developers off like a ballistic missile aimed at a fixed target, and expect the project to arrive on a date planned months or even years in advance without course correction.
I'm just guessing though, because I've never lived in that world.
In this world, all of the conditions listed above are violated beyond recognition. Software development is more like flying paper airplanes than shooting missiles. To deal with the fact, any rational plan has to include a mechanism for course corrections, and most do. But the mechanisms used are generally flawed, in that they are based on the notion that software development is mostly like a ballistic missile and that all that is needed is a little patch on the model to get past the rare gust of wind powerful enough to correct it. They focus too much on late game adjustments, and as a result, by the time anyone realizes the project is in trouble, it is too late to fix.
One possibility would be to give the developers complete information up front, and prohibit changes (even "minor" changes that "shouldn't affect anything"). Another would be to educate management, to the extent that they would be able to accurately estimate the consequences of changes in real time and adjust accordingly. I've seen both of these tried, and, while they are better than nothing, they don't work very well and they impose a significant overhead in terms of information flow.
Nuts. All it takes to make this claim false is one pure blooded Aborigine. Given that some tribes were only discovered in the last hundred years, and have rarely been contacted, the probability much greater (approaching certainty) that the claim is false than that it is true.
Have a look at the various places on Earth humans had already migrated to during that time frame, and you'll quickly realize that this theory is flawed somewhere.
Yeah, it's BS. Consider the Australian aborigines. Or the people of New Guinea. Or even native Americans. It nonsensical on the face of it.
To say "You have your team focus on addressing the highest priority open issues at each moment" is to focus on baseline enhancements to the exclusion of strategic application development.
How in the heck do you conclude that? Or, to put a finer point on it, what does it actually mean? Other than just artificially defining the terms ("highest priority open issues," "baseline enhancements" and "strategic application development") to support your conclusion, can you actually give a cogent defense of this claim? Or is it just buzzword stew?
Now, I thought the OP had a question of project estimation theory.
Yes, and the answer is (or should be) well known: in general, there is no way to determine the time it will take to complete a software project that takes less time than actually doing the work and seeing how long it took. If you want the theoretical underpinnings, just note that software development is a subset of the halting problem.
Given that, we need to go up a level, and ask if there is anything the will meet his needs in a different way. I claim there is, and have outlined the process.
You are completely missing the point here. It is precisely because it is important that you should not fall into the trap of lying to people. Instead, you should do what any other responsible R&D team would do--decouple the processes of R, D, and whatever comes after.
Here's how it works:
You don't give timelines, ever.
At any given moment you provide your customers/management with a set of "current best versions," (all this can be automated) tagged with
A unique identifier
Everything needed to reproduce that version (e.g. an SVN #, or equivalent)
Everything needed to take that version and make it a release
A complete, up to date, prioritized, searchable list of the known bugs, features, missing features, etc. of that version, along with the consequences and information about other versions in which those are fixed
Tools to upgrade/downgrade from other versions
You have your team focus on addressing the highest priority open issues at each moment
You work with the customer/management to help them make informed decisions about which version to use whenever they need to ship/install something.
The point is, because it's important, don't let it become an all or nothing proposition. Make sure that, on whatever date they need to, they have something to run with, and it is as close as you can come to the best possible version that could be produced by that date.
And it will likely be better than it otherwise would have been, because you can apply all the time you would have wasted defining and defending schedules to actually keep the project moving forwards.
While you might get some grief for refusing to estimate time, it will be far less than you'll get for being wrong. And since, in the long run, that's your only alternative, you are far better off simply refusing to estimate at all.
Besides, it's pretty easy to push it back on them. Since you clearly can not know how long it will take, or even estimate it with any confidence (again, for a non trivial project) they are in effect asking you to lie to them. So if they insist on an estimate, just insist that they agree (in writing) that you'd be lying to tell them something that you can not, even in principle, know, and that that is Ok with them.
I'm serious. If we've learned anything over the past forty years, it's that trying to estimate software development time is a waste of time. Why? Well, for one things, bugs. To know how long it would take to find and fix them, you'd have to know what the problem was, which means the hard part's done. For another thing, specification flux. Most reasonable project specifications for non-trivial projects don't provide enough information to accurately predict how long it will take to code. And producing such specs, and using them, will take longer than the development would have taken in the first place. And, if that's not enough, think of Dilbert. Specifically, the one where his boss asks him "Will there be any unforeseen problems?"
I once told a client (a dot com) "I'll tell you how long this will take if you can tell me what you stock will be worth six months from now, four months after you IPO. And I'll be more accurate than you will. If you'd rather, you can tell me when the next two-day rainstorm will be." He hemmed and hawed, and basically refused to give any sort of number whatsoever. I said "Good, it looks like we've got a nice honest relationship going here. Neither of us is willing to lie to the other, or claim to know something we don't. So let's start prioritizing these features for the mock up."
Let me say it again: Don't even attempt to estimate development times.
So what should you do instead? Incremental development with frequent opportunities for feedback. Ideally, the users should be able to play with a nightly-build prototype whenever they want from the first week or so on. If they ask for a time estimate, tell them it will be done when they're happy with the result, and don't want anything more, or they're unhappy with the rate of progress, and call the whole thing off.
But don't lie to them, no matter how hard they push.
Bottom line, free speech doesn't give people the freedom to say "kill XXX".
That's quite the double standard, if, in fact, it is the standard.
For example, there have been people running around for years saying "Kill Osama" and nobody bats an eye. Likewise when Bill O'Reilly invited terrorists to attack San Franciscohe didn't get suspended.
Same thing when Pat Robertson said we should assassinate Hugo Chaves, or just last Sunday when Melanie Morgan said (on Chris Mathews) that Bill Keller of the NYT should be killed for publicly disclosing information embarrassing to the Bush administration.
So, according to you, these things were crimes, not covered by freedom of speech? Why was no one arrested for them? Or even sent home for a semester?
Great analysis. Part of me wants to say it's not as dramatic as you make it sound, but I suspect that part of me is wrong.
In any case, it's crystal clear if you are, as you say, cynical enough.
Countries constantly arrest people on terrorism charges.
Even if they "terrorists" are clueless wannabes with no knowledge or skills or anything, with no resources (one of their big requests was boots that would fit them) and the government even has to supply them with a camera to take pictures of their "targets."
Terrorists? Ha! Oceania has always been at war with Eurasia.
As the link you cite points out, the accusations of assassinations were against a foreign bottler of coke products, and had nothing to do with the company in which Buffett held stock
Likewise, the accusations of the use of pesticides by Indian bottlers, even if true, would have nothing to do with Buffett
Your claims about pesticides are highly questionable in any case; the article you sited is flagged for deletion because of bias (scroll to the top), and even so what is being claimed is that they used water which contained pesticides (and didn't adequately purify it), not (as you claim) that they intentionally put pesticides in their own product--presumably at some expense but for no good reason except--as I assume you would have it--pure evil
I note you quietly dropped the bit about radioactivity. I assume this means you'd admit that this too was "a bit trollish"?
Coke makes radioactive waste? And has people assassinated? Bershire Hathaway used its "tentacles" to "screw over hundreds of thousands of homeless in the wake of Hurricane Katrina"?
You, sir, are either a troll or you have smoked so many SCO-linux licenses that you see AT&T trade secrets in the crawler at the bottom on Fox news, which you watch with your eyes closed, using only the filling of your teeth. The fact that you can still type leads me to conclude that the former is far more likely.
Slashdot Mirror
Great. Now we know what congress has been talking about.
Big deal.
Wake me up when you can tell me what in the hell they were thinking.
--MarkusQ
P.S. Other than how to make sure that they--and Joe Lieberman--get re-elected I mean.
That's a great list. I'd add two others:
6. Work to get some form of instant runoff system going at the local level. If enough people learn how it works when voting for mayor, we'll have a much better chance of getting it implemented at higher levels.
7. Reject proprietary / DRM formats / tiered internet, etc. in favor of open / neutral standards wherever possible, and in general strive to keep information fungible. Probably the greatest hope we have at present is that we can communicate with others in widespread, distributed networks passing detailed information with relative ease. But that ability is under constant assault and could give way to the TV model (sit down, shut up and watch...but don't record...today's version of "truth") if we don't defend it.
--MarkusQ
So let me get this straight: A lawyer specializing in constitutional law writes a hundred pages or so about an unconstitutional power grab which threatens the most powerful nation on earth, in which the executive branch is usurping the powers vested in the legislative and executive branches and creating a virtual monarchy, and your responses is...
He's a sock puppet because he has the same first name as another author?
And you feel the need to provide two links support to this astonishing point, both of which say basically "I've never seen him in person, and I know of another guy named Glenn...he must be a sock puppet"?
My mind boggles.
--MarkusQ
If you're interested in reading the account of someone who started out pretty much where you are, except that he's an attorney specializing in constitutional law, you might want to check out How Would a Patriot Act
From the back cover:
--MarkusQI agree that we are mostly agreeing. The one point where we may possibly differ: you paint a picture of monotonic convergence, where we get steadily closer to "the Truth," which I would agree is a common process in science. But it is not the only way things happen. Just as often, a system of iterative refinements such as you describe must be swept away to make room for a system which is ultimately better but was not seen until after we had progressed some way down the "wrong" road. The whole cycles and epicycles edifice in astronomy comes to mind, as well as cold blooded dinosaurs, or Frege, Whitehead and Russell's royal road to the heart of mathematics etc.
The tricky part about these sorts of things is that you can't tell ahead of time which parts of the structure you're going to have to throw out.
--MarkusQ
Get some political interests
Sticking your head in the sand will not help. So pull it out, shake out the sand, and get involved. And I don't mean you should flip a coin, pick the red team or the blue team, and blindly follow them.
I mean that you should get active in holding your elected officials accountable for their actions, regardless of their party affiliation. Keep up on the issues and be vocal about them. Read and listen to opposing points of view and try to form and propagate valid opinions. Make sure your representatives know that someone is watching them, and follows what they do. If they lie, cheat, steal, or sell you down the river, nail them. Vote them out in the primary if you can, and in the general if you can't. Cross party lines if you need to, because you are far better off with an honest member of the opposing party than one of "your own party" who is willing to sell you to the devil for a few hookers.
And, for that matter, do the same with your news outlets. And your local ballot boxes. If we paid half the attention to keeping the system honest that we do American idol or celebrity babies, we wouldn't have this problem.
--MarkusQ
The problem that the grandparent pointed out is very real. While we need to assume that "the state of current knowledge" is sound and trustworthy to do any engineering it is fatal to make that assumption in science.
I had a friend who made a minor discovery while in undergrad, simply because he didn't fudge his data in a lab assignment. He got graded down for it, and decided to redo the experiment. When he got the same results, he started asking around and found out that quite a few of his classmates had also gotten the results he had, but written it off to "experimental error" since it didn't match the predicted outcome. He took this back to the professor, and challenged him to actually do the assignment himself. They wound up publishing a joint paper on it, but to me the most interesting realization was that, for all the years that assignment had been given, nobody else had caught the error in the accepted theory.
By all means, if you have to bet on the outcome of any particular situation, go with the current state of knowledge. But if you're asked if our current knowledge is correct in its entirety, bet heavily that it is not. And if observation doesn't match the theory, don't lock yourself into the assumption that the data must be wrong because the theory couldn't possible be.
--MarkusQ
Unless Florida is even further gone than I suspect, you still need a meeting of the minds for a contract to exist. What makes an oral contract so hard to enforce is that, without some sort of documentation or other evidence, each party is generally considered the most reliable witness to their own state of mind.
Absent some evidence that both parties understood and agreed to the terms, there isn't any reason to suspect they entered into a contract.
--MarkusQ
I can't tell if you're being sarcastic or not, but the GP is correct. In fact, you can still buy appliances with a cooling cycle based on this system.
The basic idea is
--MarkusQ
It all depends on your assumptions. Look at Venus. The weather there is dead simple to predict. Heavily overcast, highs in the mid 900's, with poisonous smog in low lying areas through the weekend.
The only reason the Earth's weather seems hard to predict now is that we haven't (yet) experienced a run-away feedback loop. If you posit that we're starting into one, making accurate daily forecasts thirty years out will be much easier than sticking around to see how well you did.
--MarkusQ
anyone have any ideas what being hit by a small piece of space junk,..will do to one of these things?
I can't find a link at the moment, but ground tests showed pretty much what you'd expect--it does much better than a metal can, to roughly the same extent as a modern bullet proof vest out performs a suit of (aluminum) armor in a gun fight.
Yes, there are things that will destroy it. But Kg for Kg, Kevlar is a lot better than aluminum foil at protecting you from small, high speed impacts.
--MarkusQ
Oh come on! Do you seriously think that that's his real name?
--MarkusQ
Than I shall return the favour. For what it's worth, I've been a professional software developer for just under thirty years. I've done solo work, been a member of teams, managed teams, and (the hardest) managed people who managed teams. I've worked as a contractor and employee for small businesses and major international corporations. I know whereof I speak.
I started to respond to your points one by one (and will, if you wish) but in reading through them again I realize that we only differ on one key point. I believe that you think I am claiming a gap in our ability to predict the time it will take to develop new algorithms, and that this is the basis for my assertion that predicting software development times is impossible. Based on this assumption, you argue correctly that most software development does not involve designing new algorithms.
But that is not the point I am making.
Suppose we divide all software development projects up into three rough piles.
I'm assuming that we are both talking about the third sort, in that I excluded the first and you excluded the second, and we both seem to agree that this is where the bulk of real-world software development falls.
In an idealized world, software development of this kind would involve programmers skilled in their art using well understood, throughly and accurately documented hardware and software to meet well understood, clearly and correctly specified needs under constraints that are understood in advance by all parties. Further, once the project started, nothing would change. No one would leave or join the project, no new version of hardware or software would be introduced, new needs would not arise, constraints would not change, etc. In such a world, I will grant, it might be meaningful to talk about sending the developers off like a ballistic missile aimed at a fixed target, and expect the project to arrive on a date planned months or even years in advance without course correction.
I'm just guessing though, because I've never lived in that world.
In this world, all of the conditions listed above are violated beyond recognition. Software development is more like flying paper airplanes than shooting missiles. To deal with the fact, any rational plan has to include a mechanism for course corrections, and most do. But the mechanisms used are generally flawed, in that they are based on the notion that software development is mostly like a ballistic missile and that all that is needed is a little patch on the model to get past the rare gust of wind powerful enough to correct it. They focus too much on late game adjustments, and as a result, by the time anyone realizes the project is in trouble, it is too late to fix.
One possibility would be to give the developers complete information up front, and prohibit changes (even "minor" changes that "shouldn't affect anything"). Another would be to educate management, to the extent that they would be able to accurately estimate the consequences of changes in real time and adjust accordingly. I've seen both of these tried, and, while they are better than nothing, they don't work very well and they impose a significant overhead in terms of information flow.
So what does work?
The o
--MarkusQ
Yeah, it's BS. Consider the Australian aborigines. Or the people of New Guinea. Or even native Americans. It nonsensical on the face of it.
--MarkusQ
How in the heck do you conclude that? Or, to put a finer point on it, what does it actually mean? Other than just artificially defining the terms ("highest priority open issues," "baseline enhancements" and "strategic application development") to support your conclusion, can you actually give a cogent defense of this claim? Or is it just buzzword stew?
Yes, and the answer is (or should be) well known: in general, there is no way to determine the time it will take to complete a software project that takes less time than actually doing the work and seeing how long it took. If you want the theoretical underpinnings, just note that software development is a subset of the halting problem. Given that, we need to go up a level, and ask if there is anything the will meet his needs in a different way. I claim there is, and have outlined the process.
--MarkusQ
You are completely missing the point here. It is precisely because it is important that you should not fall into the trap of lying to people. Instead, you should do what any other responsible R&D team would do--decouple the processes of R, D, and whatever comes after.
Here's how it works:
The point is, because it's important, don't let it become an all or nothing proposition. Make sure that, on whatever date they need to, they have something to run with, and it is as close as you can come to the best possible version that could be produced by that date.
And it will likely be better than it otherwise would have been, because you can apply all the time you would have wasted defining and defending schedules to actually keep the project moving forwards.
--MarkusQ
The difference being, all the things I mentioned actually happened. But nice try.
--MarkusQ
While you might get some grief for refusing to estimate time, it will be far less than you'll get for being wrong. And since, in the long run, that's your only alternative, you are far better off simply refusing to estimate at all.
Besides, it's pretty easy to push it back on them. Since you clearly can not know how long it will take, or even estimate it with any confidence (again, for a non trivial project) they are in effect asking you to lie to them. So if they insist on an estimate, just insist that they agree (in writing) that you'd be lying to tell them something that you can not, even in principle, know, and that that is Ok with them.
--MarkusQ
Don't do it!
I'm serious. If we've learned anything over the past forty years, it's that trying to estimate software development time is a waste of time. Why? Well, for one things, bugs. To know how long it would take to find and fix them, you'd have to know what the problem was, which means the hard part's done. For another thing, specification flux. Most reasonable project specifications for non-trivial projects don't provide enough information to accurately predict how long it will take to code. And producing such specs, and using them, will take longer than the development would have taken in the first place. And, if that's not enough, think of Dilbert. Specifically, the one where his boss asks him "Will there be any unforeseen problems?"
I once told a client (a dot com) "I'll tell you how long this will take if you can tell me what you stock will be worth six months from now, four months after you IPO. And I'll be more accurate than you will. If you'd rather, you can tell me when the next two-day rainstorm will be." He hemmed and hawed, and basically refused to give any sort of number whatsoever. I said "Good, it looks like we've got a nice honest relationship going here. Neither of us is willing to lie to the other, or claim to know something we don't. So let's start prioritizing these features for the mock up."
Let me say it again: Don't even attempt to estimate development times.
So what should you do instead? Incremental development with frequent opportunities for feedback. Ideally, the users should be able to play with a nightly-build prototype whenever they want from the first week or so on. If they ask for a time estimate, tell them it will be done when they're happy with the result, and don't want anything more, or they're unhappy with the rate of progress, and call the whole thing off.
But don't lie to them, no matter how hard they push.
--MarkusQ
That's quite the double standard, if, in fact, it is the standard.
For example, there have been people running around for years saying "Kill Osama" and nobody bats an eye. Likewise when Bill O'Reilly invited terrorists to attack San Francisco he didn't get suspended. Same thing when Pat Robertson said we should assassinate Hugo Chaves, or just last Sunday when Melanie Morgan said (on Chris Mathews) that Bill Keller of the NYT should be killed for publicly disclosing information embarrassing to the Bush administration.
So, according to you, these things were crimes, not covered by freedom of speech? Why was no one arrested for them? Or even sent home for a semester?
--MarkusQ
--MarkusQ
Even if they "terrorists" are clueless wannabes with no knowledge or skills or anything, with no resources (one of their big requests was boots that would fit them) and the government even has to supply them with a camera to take pictures of their "targets."
Terrorists? Ha! Oceania has always been at war with Eurasia.
--MarkusQ
But what about the rest of your points?
--MarkusQ
Coke makes radioactive waste? And has people assassinated? Bershire Hathaway used its "tentacles" to "screw over hundreds of thousands of homeless in the wake of Hurricane Katrina"?
You, sir, are either a troll or you have smoked so many SCO-linux licenses that you see AT&T trade secrets in the crawler at the bottom on Fox news, which you watch with your eyes closed, using only the filling of your teeth. The fact that you can still type leads me to conclude that the former is far more likely.
--MarkusQ