Well to be fair, it's the longest BSD troll I've seen AFAIR. They usually go like "BSD is dying! Netcraft confirms it !" and "BSD is dead to me!".
These are based on the original BSD troll which was very similar to the FP, which used to (many years ago) make an appearance in almost every story related to BSD.
Banks use their r&d for competitive advantage. The chances of them freely releasing their work to help humanity (and their competitors) is not very high.
How many major infrastructure projects have been attempted at all over the past 40 years? That is the entire problem, as far as I see it, is we are falling behind because we are not building anything. Successive governments keep playing it safe and if there is a surplus the money does not get invested into major infrastructure projects, it gets "invested" into winning the next election through middle class welfare. The mining boom will eventually end and we will be left in the tough times with nothing to show from the good times.
9 employers in 12 years is excessive for a programmer? I guess you don't know many contractors then. Regular 3 to 12 month gigs are the norm and nobody bats an eyelid at it.
Not in the browser market, no. They have enough market share that they're able to influence the market and keep the innovations and advancements flowing, and that's all that matters to them.
So their main goal is not to make money but to produce innovations and advancements? I'm sure their shareholders would be interested in that one.
A big problem online poker players face is the nonsense that the GP was sprouting. The trouble is that they know nothing about the topic at hand yet feel they are qualified to talk about it (well, I guess the same goes for any topic really). You summed it up nicely - in a game of poker it is player v player, the house does not care one bit who wins and loses as they get a "rake" out of every pot. Their sole interest - the one that makes them the most money - is to make as many people play as possible. The better players tend to play more tables therefore provide more income to the sites, which is why sites reward high volume players regardless of whether they are winners or losers (and there are quite a number of high volume winners). The site gets paid regardless of who wins and loses a game, there is no way for them to end up behind on a hand played.
If I were playing a cash game I would fist pump if I saw my AK get called by 43. Yes, the flop comes out 443 this time however in the long run (and poker is about the long run, as in tens if not hundreds of thousands of hands if you play seriously online) you will destroy that clown. Yes he wins this game, however over the next 10 times this happens he will lose around 2/3 of the hands, providing a nice profit.
You clearly don't know what you are talking about or you wouldn't make such blatantly false statement.
I'm glad someone beat me to it. That statement was just absurd and shows a total ignorance of the subject being discussed, made worse with the condescending "you are all so sadly mistaken and I am now going to tell you how it is" tone.
The ONLY game where computers are a match with the top human players is heads up limit holdem. There is no other poker game where computers would be favoured against a top pro so the statement "pitted against a computer, their results suddenly fall well within a bell curve of chance" is just false.
When I look in my database there is a very strong trend where winrates reduce as the stakes increase. This would indicate that as opponents get tougher, it is harder to beat the game in the long run. This flies in the face of the notion that poker is only a game of chance which would lead to no correlation between opponent skill level and winrates.
It would have been interesting to a C, C++ and Fortran shootout on some heavy number crunching. Throw in some OpenGL, OpenCL and assembly for good measure. We always get to see how high level languages compare, when in reality for most apps that are written in higher level languages raw speed is one of the lesser factors when choosing a language. Yet we never see shootouts between the lower level languages which would be used if speed truly was a concern.
TFA here though isn't referring to someone "sneaking a few minutes break at work to check a website while they wait for an email", it is talking about a police officer accessing personal and by its nature I would imagine very sensitive information on a police database, not a random website, that they had no legal reason to be accessing. This is a far cry from using company time to surf the web.
I will put it simply - you are not as good at poker as you think you are.
How do I know this? I play seriously both live AND online. I win at both, and not cheesburger stakes either (I am a winner at mid stakes at both and use it to comfortably support myself between contracts). If you can beat live but can't beat online it is not because OMGZ online is rigged! it is generally because at least at up to mid stakes online players are far better than live players.
I am happy to expand (whether you want me to or not). Online games tend to be both tighter and more aggressive. What this generally means is that an online only player coming to a live game will at first struggle with the looser more passive play. If they are tilt prone they may struggle with the greater number of suckouts in live play due to more players to the flop who will go all the way with their weak draw or underpair and don't know what went wrong. The better players quickly adjust and after a relatively small crossover period will happily destroy most live games as they generally have a far better understanding of the theory behind the game. And no, wearing your sunglasses and hoodie looking for the twitch in the corner of your opponents eye does not give you a massive advantage, if you think it does, then that may explain why you struggle online.
Live players moving to online on the other hand get crushed when they call 3-bets out of position with their any 2 suited cards and attribute it to online being rigged rather than piss poor pre-flop strategy. In general (this is generalising but does apply in the majority of cases) they have no grasp of positional play, have no clue why playing out of position is bad and will call down the whole way with a weak draw and don't get paid off when they do hit. Then they wonder what went wrong as this play works fine in live games where most flops see 5 to 7 to a flop rather than most being heads up or 3-way. In a large multi-way pot pre-flop mistakes are negligible. In a short handed game where heads up post flop play is the norm rather than exception pre-flop mistakes add up very quickly and if they are large enough can't be compensated for by post-flop skill.
Poker is poker, whether it be live or online. They play differently however it is still the same game with the same rules and it is just a matter of adjusting. If you can beat one and not the other then the flaw lies in your game rather than in the medium of delivery.
Who needs proof here on/.? Poster had their AA beaten - definitive proof that teh online pokahz iz rigged!!1! A few of the smaller sites have been busted for dodgy things, I have never seen any proof against Full Tilt or PS (being a fairly serious player both online and live I keep a very close eye on these things). Stars especially has a reputation for solid service and refunding $ to players if anything shady was discovered in any of the games that player played in.
If by any chance the poster does have proof there are many people who would be very interested in seeing it. Trouble is - proof has to be a bit more definitive than "I don't trust their RNG" or "they cheat cause I am the worlds best poker player but can't win online". In re the random number generator - proof or STFU. In re being a good player but can't beat online, the reason for that is because online players tend to be, at least at the small to mid stakes, orders of magnitude better than live players.
If your requirements keep changing, the project manager/program analyst should be fired.
I could not agree more - however there would be a lot of out of work PMs if that really happened. A big part of that is the PM has no authority to say no to the board - if the order comes from above to move go-live forward generally the only authority they have is downwards to re-arrange resources to best make it happen. To be honest however I am yet to come across a single larger scale project where no requirements changed as the project progressed (I have never worked on medical / defence / real-time systems which I am *hoping* do not have the same issues!). After all - was that not why as an industry we moved away from the waterfall and towards a spiral / agile / whatever buzzword type methodology? The whole problem with waterfall was that it fell apart if the requirements changed after they had been signed off and these newer methodologies were brought in to deal with those issues. I personally feel waterfall has a lot to offer and as an industry we need to start moving back in that direction if we want to compare ourselves to the true engineering disciplines. How can we possibly consider ourselves professionals when we are willing to change fundamental design decisions only a short time before go-live and consider that a positive (ie. it is supposed to show how flexible we are)?
The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.
Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered software, and security implications of config options, is an excellent idea.) For most of the documentation requirements, I don't really need to hear how you plan to do it: I just need to know that, if you screw up, you're going to be (at least partially) financially liable. And yet, the contract fails to specify that. What happens when there *is* a security breach, despite all the documentation saying the software is secure? If the procedures weren't followed, then that's obviously a breach of contract — but what if there was a problem anyway?
I actually like designating a single person in charge of security. Finding someone to blame after the fact is a horrible idea. However, having someone who's job it is to pay attention early, with the authority to do something about it is an excellent way to make sure it doesn't just fall through the cracks. By requiring their personal signoff on deliverables, you give them the power they need to be effective. (Of course, if management inside your vendor is so bad that they get forced into just rubber-stamping everything, that's a different problem. But if you wanted to micromanage every detail of how your vendor does things internally, why are you contracting to a vendor?)
I don't agree there re the lazy comment. The reason poor coders release insecure code is because they are lazy. For the rest of us, it is generally because we are told we MUST release X features by go-live date. Go-live date will not slip under any circumstances. X features are non-negotiable for go-live date. The project manager (not the development PM, the project owner) has assigned a certain period for testing, however this testing is never SIT or the such, it is usually UAT of a very non-technical nature and the devs time is spent on feedback from UAT. Development itself has virtually no proper regression / SIT / design time factored in. The development team are never asked how long realistically something will take, instead some non-technical person will tell them how long they have and then tells them to figure out how to make it happen. Specs will change continuously throughout the project so a design approach at the beginning will be all but useless at the end after numerous fundamental changes (got this one on a project I'm working on now - had my part finished, fully tested and ready to deploy about 3 months ago, then change after change after change and I'm still doing dev and if I mention that I need time to conduct SIT / regression testing I'm told "but I thought you fully tested it already a few months ago?"). This leads a dev with a fast approaching deadline, who doesn't have the authority to say "no, this won't give us enough time to test properly" and the emphasis on being feature complete rather than a few features down but fully tested and secure.
This of course does not even touch on the subject of what happens if a third party library or other software sourced externally has vulnerabilities. Can you in good faith sign off that you guarantee a piece of software is totally secure without knowing how third party libraries, runtime environments or whatever were developed? This is not just isolated to open source, try holding MS liable for a security vulnerability that was uncovered after you deployed and see how far you get. This then starts taking us out of the realm of absolutes and into the realm of "best practices" etc. So how good is a contract that expects the signatory to follow "best practi
And loosely coupled code is fundamentally better *why*? "Because it can be easily unit tested" is the only argument I can swallow...
On the past few systems I have worked on I have had the "fun" job of adding new features to existing legacy code. Adding features to the existing tightly coupled code was a nightmare, finding what did exactly what took ages, some functionality was partially performed in several different locations - each relying on the previous part - and the slightest spec change would need the whole thing to be re-done yet again. The exact same spec changes (eg a new element in a message) were trivial to do in the applications I had written from scratch as each change only needed to be done in a single location and was easy to test. I may have seen some extreme cases but I have certainly become a "loosely coupled" evangelist since.
Provide a solid spec and I would be happy to do a fixed cost project - however I will hold you to the spec just as much as you will hold me to the cost. Provide me a vague wishlist and I will not do a job for you fixed cost. Keep in mind any fixed cost quote will come with the risk priced in at some point. Some people are unhappy with that, wanting a fixed cost to be based upon best case estimates - I simply won't do business with them. Just because someone contracts does not mean they will do any job under any conditions presented to them.
I hate this. And when you say you can't estimate something like that, they say: "oh just give us your best guess, we won't hold you to it." Then six months down the line you get called into someone's office and interrogated for an hour because you can't deliver "on time"...and by this time you forgot that they said they wouldn't hold you to the estimate so you end up trying to defend it...trying desperately to think of all the little things that went wrong and blow them up into bigger issues.
One of the first things I learnt - always always ALWAYS ask for any stupid request / comment / statement in an email. "We won't hold you to it" rates very highly on the list of things I want in writing before I will commit to something. If they will not provide you with an email saying as much, make sure that you email them (preferably cc'ing someone) confirming their request and any problems you might see in it so they can't plead ignorance at that future date. That way when you do get called into that meeting you have something to back yourself up with. It has saved me on multiple occassions.
Sounds similar to the method I used to use I would make an estimate, add a 50% buffer and double it and send it to the sales rep The sales rep came from a technical background so knew how IT projects went, so he would take my estimate, double it and add a buffer to that. This method actually produced estimates quite close to what turned into reality.
I think the problem with estimates are that: a) developers are never as fast as they think they are, b) the customer always has something hidden in there that actually means something far more complex than what it appears, c) there are always unforseen things that go wrong eg a bug in some framework you use that you have to then spend time hacking around and d) the human factor - some people leave the project, some people would be more useful to the project if they had nothing to do with it, etc.
The trouble is one of the biggest impact items - ie. the customers or vendors - will almost never be the same project to project. Other peoples experiences may differ but I always find that the people involved usually are the biggest factor determining if a project meets deadlines or not and you have no idea what they will be like until the project begins. Even the same person may perform differently project to project, on the first they may be a dedicated resource, on the next the project is one of a dozen they are working on simultaneously so can only devote a fraction of the time and effort of the original. I have had projects that in reality should have taken a few hours take a couple of weeks while other highly complex projects lasting several months go off without a hitch and come in early, all due to the different people.
Revising or 'dropping' a promise you made is called reneging on obligations you made.
No, dropping a promise is not reneging on obligations. Sun promised to work on accessibility, however they were in absolutely no way obliged to work on accessibility. There is a big difference between the two.
After reading TFA, as far as my medically ignorant mind makes out, the study was withdrawn due to ethical issues obtaining the samples for the study, not due to issues with the conclusions drawn. I can see how this would lead Wakefield to be deregistered due to ethical considerations however how does this disprove his conclusions? The logic seems to go "your study shows there may be a link between autism and vaccines, you obtained samples unethically, therefore this proves once and for all and hereby ends the discussion that there is conclusively no link between autism and vaccines". I always pay extra close attention when a scientific discussion starts descending into claims of absolutes, a statement like "the possibility is laughably remote that there is a link between x and y" makes sense, "there is no link between x and y and nobody is to suggest there is" smacks of dark ages medicine rather than science.
I would love someone more medically inclined to provide more background as I sense a lot of info was missing from the story / article.
Slashdot Mirror
I for one am glad a geek IS the project manager.
More focused on getting it right than meeting deadlines.
That would explain why GNU/Hurd is such an excellent OS
Well to be fair, it's the longest BSD troll I've seen AFAIR. They usually go like "BSD is dying! Netcraft confirms it !" and "BSD is dead to me!".
These are based on the original BSD troll which was very similar to the FP, which used to (many years ago) make an appearance in almost every story related to BSD.
Banks use their r&d for competitive advantage. The chances of them freely releasing their work to help humanity (and their competitors) is not very high.
How many major infrastructure projects have been attempted at all over the past 40 years? That is the entire problem, as far as I see it, is we are falling behind because we are not building anything. Successive governments keep playing it safe and if there is a surplus the money does not get invested into major infrastructure projects, it gets "invested" into winning the next election through middle class welfare. The mining boom will eventually end and we will be left in the tough times with nothing to show from the good times.
9 employers in 12 years is excessive for a programmer? I guess you don't know many contractors then. Regular 3 to 12 month gigs are the norm and nobody bats an eyelid at it.
Not in the browser market, no. They have enough market share that they're able to influence the market and keep the innovations and advancements flowing, and that's all that matters to them.
So their main goal is not to make money but to produce innovations and advancements? I'm sure their shareholders would be interested in that one.
Oh come now, we all know you just enjoy the ability to play with no clothes on! Must admit I have done that more than once.
A big problem online poker players face is the nonsense that the GP was sprouting. The trouble is that they know nothing about the topic at hand yet feel they are qualified to talk about it (well, I guess the same goes for any topic really). You summed it up nicely - in a game of poker it is player v player, the house does not care one bit who wins and loses as they get a "rake" out of every pot. Their sole interest - the one that makes them the most money - is to make as many people play as possible. The better players tend to play more tables therefore provide more income to the sites, which is why sites reward high volume players regardless of whether they are winners or losers (and there are quite a number of high volume winners). The site gets paid regardless of who wins and loses a game, there is no way for them to end up behind on a hand played.
If I were playing a cash game I would fist pump if I saw my AK get called by 43. Yes, the flop comes out 443 this time however in the long run (and poker is about the long run, as in tens if not hundreds of thousands of hands if you play seriously online) you will destroy that clown. Yes he wins this game, however over the next 10 times this happens he will lose around 2/3 of the hands, providing a nice profit.
You clearly don't know what you are talking about or you wouldn't make such blatantly false statement.
I'm glad someone beat me to it. That statement was just absurd and shows a total ignorance of the subject being discussed, made worse with the condescending "you are all so sadly mistaken and I am now going to tell you how it is" tone.
The ONLY game where computers are a match with the top human players is heads up limit holdem. There is no other poker game where computers would be favoured against a top pro so the statement "pitted against a computer, their results suddenly fall well within a bell curve of chance" is just false.
When I look in my database there is a very strong trend where winrates reduce as the stakes increase. This would indicate that as opponents get tougher, it is harder to beat the game in the long run. This flies in the face of the notion that poker is only a game of chance which would lead to no correlation between opponent skill level and winrates.
It would have been interesting to a C, C++ and Fortran shootout on some heavy number crunching. Throw in some OpenGL, OpenCL and assembly for good measure. We always get to see how high level languages compare, when in reality for most apps that are written in higher level languages raw speed is one of the lesser factors when choosing a language. Yet we never see shootouts between the lower level languages which would be used if speed truly was a concern.
TFA here though isn't referring to someone "sneaking a few minutes break at work to check a website while they wait for an email", it is talking about a police officer accessing personal and by its nature I would imagine very sensitive information on a police database, not a random website, that they had no legal reason to be accessing. This is a far cry from using company time to surf the web.
I must be pretty damn lucky to be consistently winning money at internet dice year after year, huh?
You too? And here I thought I was the one in a million lottery winner!
Wow, just wow.
I will put it simply - you are not as good at poker as you think you are.
How do I know this? I play seriously both live AND online. I win at both, and not cheesburger stakes either (I am a winner at mid stakes at both and use it to comfortably support myself between contracts). If you can beat live but can't beat online it is not because OMGZ online is rigged! it is generally because at least at up to mid stakes online players are far better than live players.
I am happy to expand (whether you want me to or not). Online games tend to be both tighter and more aggressive. What this generally means is that an online only player coming to a live game will at first struggle with the looser more passive play. If they are tilt prone they may struggle with the greater number of suckouts in live play due to more players to the flop who will go all the way with their weak draw or underpair and don't know what went wrong. The better players quickly adjust and after a relatively small crossover period will happily destroy most live games as they generally have a far better understanding of the theory behind the game. And no, wearing your sunglasses and hoodie looking for the twitch in the corner of your opponents eye does not give you a massive advantage, if you think it does, then that may explain why you struggle online.
Live players moving to online on the other hand get crushed when they call 3-bets out of position with their any 2 suited cards and attribute it to online being rigged rather than piss poor pre-flop strategy. In general (this is generalising but does apply in the majority of cases) they have no grasp of positional play, have no clue why playing out of position is bad and will call down the whole way with a weak draw and don't get paid off when they do hit. Then they wonder what went wrong as this play works fine in live games where most flops see 5 to 7 to a flop rather than most being heads up or 3-way. In a large multi-way pot pre-flop mistakes are negligible. In a short handed game where heads up post flop play is the norm rather than exception pre-flop mistakes add up very quickly and if they are large enough can't be compensated for by post-flop skill.
Poker is poker, whether it be live or online. They play differently however it is still the same game with the same rules and it is just a matter of adjusting. If you can beat one and not the other then the flaw lies in your game rather than in the medium of delivery.
Who needs proof here on /.? Poster had their AA beaten - definitive proof that teh online pokahz iz rigged!!1! A few of the smaller sites have been busted for dodgy things, I have never seen any proof against Full Tilt or PS (being a fairly serious player both online and live I keep a very close eye on these things). Stars especially has a reputation for solid service and refunding $ to players if anything shady was discovered in any of the games that player played in.
If by any chance the poster does have proof there are many people who would be very interested in seeing it. Trouble is - proof has to be a bit more definitive than "I don't trust their RNG" or "they cheat cause I am the worlds best poker player but can't win online". In re the random number generator - proof or STFU. In re being a good player but can't beat online, the reason for that is because online players tend to be, at least at the small to mid stakes, orders of magnitude better than live players.
If your requirements keep changing, the project manager/program analyst should be fired.
I could not agree more - however there would be a lot of out of work PMs if that really happened. A big part of that is the PM has no authority to say no to the board - if the order comes from above to move go-live forward generally the only authority they have is downwards to re-arrange resources to best make it happen. To be honest however I am yet to come across a single larger scale project where no requirements changed as the project progressed (I have never worked on medical / defence / real-time systems which I am *hoping* do not have the same issues!). After all - was that not why as an industry we moved away from the waterfall and towards a spiral / agile / whatever buzzword type methodology? The whole problem with waterfall was that it fell apart if the requirements changed after they had been signed off and these newer methodologies were brought in to deal with those issues. I personally feel waterfall has a lot to offer and as an industry we need to start moving back in that direction if we want to compare ourselves to the true engineering disciplines. How can we possibly consider ourselves professionals when we are willing to change fundamental design decisions only a short time before go-live and consider that a positive (ie. it is supposed to show how flexible we are)?
Yeah, but you can keep them from doing it again.
The reason people don't use these well-known techniques is very simple: it takes time and effort, and people are lazy. So until the customer tells them to, they won't bother.
Which brings me to my biggest objection to this proposed contract. There's lots of documentation requirements, and no assignment of liability. Documentation is expensive to produce, and much of this I really don't care about. (Exception: the document on how to secure the delivered software, and security implications of config options, is an excellent idea.) For most of the documentation requirements, I don't really need to hear how you plan to do it: I just need to know that, if you screw up, you're going to be (at least partially) financially liable. And yet, the contract fails to specify that. What happens when there *is* a security breach, despite all the documentation saying the software is secure? If the procedures weren't followed, then that's obviously a breach of contract — but what if there was a problem anyway?
I actually like designating a single person in charge of security. Finding someone to blame after the fact is a horrible idea. However, having someone who's job it is to pay attention early, with the authority to do something about it is an excellent way to make sure it doesn't just fall through the cracks. By requiring their personal signoff on deliverables, you give them the power they need to be effective. (Of course, if management inside your vendor is so bad that they get forced into just rubber-stamping everything, that's a different problem. But if you wanted to micromanage every detail of how your vendor does things internally, why are you contracting to a vendor?)
I don't agree there re the lazy comment. The reason poor coders release insecure code is because they are lazy. For the rest of us, it is generally because we are told we MUST release X features by go-live date. Go-live date will not slip under any circumstances. X features are non-negotiable for go-live date. The project manager (not the development PM, the project owner) has assigned a certain period for testing, however this testing is never SIT or the such, it is usually UAT of a very non-technical nature and the devs time is spent on feedback from UAT. Development itself has virtually no proper regression / SIT / design time factored in. The development team are never asked how long realistically something will take, instead some non-technical person will tell them how long they have and then tells them to figure out how to make it happen. Specs will change continuously throughout the project so a design approach at the beginning will be all but useless at the end after numerous fundamental changes (got this one on a project I'm working on now - had my part finished, fully tested and ready to deploy about 3 months ago, then change after change after change and I'm still doing dev and if I mention that I need time to conduct SIT / regression testing I'm told "but I thought you fully tested it already a few months ago?"). This leads a dev with a fast approaching deadline, who doesn't have the authority to say "no, this won't give us enough time to test properly" and the emphasis on being feature complete rather than a few features down but fully tested and secure.
This of course does not even touch on the subject of what happens if a third party library or other software sourced externally has vulnerabilities. Can you in good faith sign off that you guarantee a piece of software is totally secure without knowing how third party libraries, runtime environments or whatever were developed? This is not just isolated to open source, try holding MS liable for a security vulnerability that was uncovered after you deployed and see how far you get. This then starts taking us out of the realm of absolutes and into the realm of "best practices" etc. So how good is a contract that expects the signatory to follow "best practi
Same here, and same with everyone I know. Since when is "barbie" not the Aussie slang for bbq?? On that note - if its not "barbie" then what is it?
And loosely coupled code is fundamentally better *why*? ...
"Because it can be easily unit tested" is the only argument I can swallow
On the past few systems I have worked on I have had the "fun" job of adding new features to existing legacy code. Adding features to the existing tightly coupled code was a nightmare, finding what did exactly what took ages, some functionality was partially performed in several different locations - each relying on the previous part - and the slightest spec change would need the whole thing to be re-done yet again. The exact same spec changes (eg a new element in a message) were trivial to do in the applications I had written from scratch as each change only needed to be done in a single location and was easy to test. I may have seen some extreme cases but I have certainly become a "loosely coupled" evangelist since.
Provide a solid spec and I would be happy to do a fixed cost project - however I will hold you to the spec just as much as you will hold me to the cost. Provide me a vague wishlist and I will not do a job for you fixed cost. Keep in mind any fixed cost quote will come with the risk priced in at some point. Some people are unhappy with that, wanting a fixed cost to be based upon best case estimates - I simply won't do business with them. Just because someone contracts does not mean they will do any job under any conditions presented to them.
I hate this. And when you say you can't estimate something like that, they say: "oh just give us your best guess, we won't hold you to it." Then six months down the line you get called into someone's office and interrogated for an hour because you can't deliver "on time"...and by this time you forgot that they said they wouldn't hold you to the estimate so you end up trying to defend it...trying desperately to think of all the little things that went wrong and blow them up into bigger issues.
One of the first things I learnt - always always ALWAYS ask for any stupid request / comment / statement in an email. "We won't hold you to it" rates very highly on the list of things I want in writing before I will commit to something. If they will not provide you with an email saying as much, make sure that you email them (preferably cc'ing someone) confirming their request and any problems you might see in it so they can't plead ignorance at that future date. That way when you do get called into that meeting you have something to back yourself up with. It has saved me on multiple occassions.
Sounds similar to the method I used to use
I would make an estimate, add a 50% buffer and double it and send it to the sales rep
The sales rep came from a technical background so knew how IT projects went, so he would take my estimate, double it and add a buffer to that.
This method actually produced estimates quite close to what turned into reality.
I think the problem with estimates are that:
a) developers are never as fast as they think they are,
b) the customer always has something hidden in there that actually means something far more complex than what it appears,
c) there are always unforseen things that go wrong eg a bug in some framework you use that you have to then spend time hacking around and
d) the human factor - some people leave the project, some people would be more useful to the project if they had nothing to do with it, etc.
The trouble is one of the biggest impact items - ie. the customers or vendors - will almost never be the same project to project. Other peoples experiences may differ but I always find that the people involved usually are the biggest factor determining if a project meets deadlines or not and you have no idea what they will be like until the project begins. Even the same person may perform differently project to project, on the first they may be a dedicated resource, on the next the project is one of a dozen they are working on simultaneously so can only devote a fraction of the time and effort of the original. I have had projects that in reality should have taken a few hours take a couple of weeks while other highly complex projects lasting several months go off without a hitch and come in early, all due to the different people.
Revising or 'dropping' a promise you made is called reneging on obligations you made.
No, dropping a promise is not reneging on obligations. Sun promised to work on accessibility, however they were in absolutely no way obliged to work on accessibility. There is a big difference between the two.
After reading TFA, as far as my medically ignorant mind makes out, the study was withdrawn due to ethical issues obtaining the samples for the study, not due to issues with the conclusions drawn. I can see how this would lead Wakefield to be deregistered due to ethical considerations however how does this disprove his conclusions? The logic seems to go "your study shows there may be a link between autism and vaccines, you obtained samples unethically, therefore this proves once and for all and hereby ends the discussion that there is conclusively no link between autism and vaccines". I always pay extra close attention when a scientific discussion starts descending into claims of absolutes, a statement like "the possibility is laughably remote that there is a link between x and y" makes sense, "there is no link between x and y and nobody is to suggest there is" smacks of dark ages medicine rather than science.
I would love someone more medically inclined to provide more background as I sense a lot of info was missing from the story / article.