How to respond when you are asked for an estimate? - <AUTHOR> https://softwareengineering.stackexchange.com/questions/648/how-to-respond-when-you-are-asked-for-an-estimate <comment><USER2> Guess what number they'll accept and double it, put up a fight when they halve it, blame someone else when you miss it, and take the credit when you hit it. At most companies estimates are about control, expectation management, and blame distribution and not about information discovery.

Most people really suck at expectation management, much more than they suck at estimating work.

<comment><USER3> Sounds a lot like the scene in Star Trek: The Next Generation, where Geordi La Forge meets Scotty.

> Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain > everything to you, but the Captain wants this spectrographic analysis done > by 1300 hours.

> [La Forge goes back to work; Scotty follows slowly]

> Scotty: Do you mind a little advice? Starfleet captains are like children. > They want everything right now and they want it their way. But the secret is > to give them only what they need, not what they want.

> Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this > analysis done in an hour.

> Scotty: How long will it really take?

> Lt. Commander Geordi La Forge: An hour!

> Scotty: Oh, you didn't tell him how long it would _really_ take, did ya?

> Lt. Commander Geordi La Forge: Well, of course I did.

> Scotty: Oh, laddie. You've got a lot to learn if you want people to think of > you as a miracle worker.

<comment><USER4> I always hated that scene, because it fundamentally changed the character of Mr. Scott from engineer to engineering manager. Which, he was, but that wasn't what made his character so compelling to begin with.

LaForge was a competent engineering manager. The writers tended to focus more on the character's people management skills (and, sometimes, terrible personal relationship stuff). He kept things running smoothly. He was smart. You could imagine a detailed maintenance work log for every system on the ship, and there'd be no gaps in it ever since he took the position of chief engineer.

But while Scotty cared about his staff, it was the machinery that he knew inside and out. He never needed to conjure up a hologram of the designer of the warp engines, because he knew them as well as anyone else. His maintenance logs would have gaps because he'd know which things actually needed regular attention, and which ones were just bureaucratic nonsense. He didn't just understand all of it on the technician level, but on the theoretical level too, enabling him to pull off some unlikely saves.

He actually was a miracle worker and maybe one of the best fictional representations of an engineer, and that one scene was written to make him look a little more like a bureaucrat.

<comment><USER5> I felt that it was more for comedy as well as helping to develop the difference in character between the two.

LaForge is competent, he's also newer in his overall career. Scotty has been around the block so many times he knows where every crack and seam is.

That was a moment where Scotty's wisdom was being handed down; it's OK to know what it will take, but stuff happens, and there's also the potential to hand tasks off to less senior staff that might not do it at perfect speed. Giving a padded estimate gives you options and room for corrections if there are issues.

</comment></comment></comment></comment><comment><USER6> Pro tip: Don't laugh. The boss once asked me for an estimate and I laughed. He said that wasn't funny and I said that he started it!

On the other hand: Do it. Laugh. Laugh in his face when you are called to help on a project that isn't ready after 1 year and started without you. When they show some wire-frames and ask you how long it takes without telling you about the actual technology used for the project.

Summer 2015 I was uninvited from a project meeting. My coworker was planning the project and discussed it a bit with me. He wasn't the one who decided that I shouldn't take part.

Summer/Fall 2016 and the project isn't going anywhere. I'm invited to help. I do my best, besides the other projects.

January 2017 and my coworker is gone. He gave his 3 months (+ x days) notice and told me December 2016. Shortly after it I gave my 4 1/2 months notice.

The new deadline for the project was May 2017.

They launched November 2017.

"Cool story, bro. What was it? Some revolutionary VR or AR application? AI supported super gadget? Brainwave reader and interpreter?"

…

It was the company's own website.

<comment><USER7> I have been in a similar situation.

Any project like this one can often go off the rails if the right decision makers are not involved. This is not necessarily the fault of the project leader as it can be unintuitive in bureaucracies.

<comment><USER8> Corporate websites, in particular, can be pathological cases. The closer to completion, the more "stakeholders" come out of the woodwork.

</comment></comment></comment><comment><USER9> How to treat estimates is hugely dependent on the political situation at your company. Things such as, exactly what is your role, the role of the person asking, your relationship and their expectations, what will they use the information for? That plus the technical side of how many unknowns are involved in doing this thing, and how long it has taken to resolve similar types of unknown in the past.

Maybe the most important thing to remember is to beware of keeping your old behavior with regard to estimating things when there's a sudden change in the management structure. You may go from someone who understands development and knows how to interpret and present a good-faith estimate from developers to higher ups, to someone who just presents your estimates up the chain verbatim. And that shift may not be obvious to the developer until the fallout from a bad estimate gets blamed on you.

<comment><USER10> This. This is one of the reasons I left my last PM job. I was being told to spend less time with the team and more time on the road with clients. I don't know what the right ratio is, but I do know that my rapport with the team and deep familiarity with the stories/tasks led to pretty solid estimates. Also knowing the patterns of the dev lead helped a lot, he was a chronic underestimater so I'd do my best to push him to consider things like coordination, legacy, etc.

Personality of the estimator plays a huge part and the voltile/stable essay was a great shortcut for understanding this. A voltile will hit the estimate or beat it. It'll be cowboy all day long and god help the company if it needs to be maintained. I've had a few dev leads like this. They'll take the tricky bits and do it alone. At night. On the weekend. Half asleep. Then, there is the stable. They'll never hit their original estimate. The most egregious won't get beyond the proof of concept without some serious prodding. When the project is done, it's meticulous, but we rarely get to that point because of the daily 6 hour long discussions about naming...

<comment><USER11> PM = Project manager, or PM = Product Manager?

If it's Project Manager, that's crazy.

<comment><USER10> Yes product- though we didn't have project management to speak of. So, both.

<comment><USER11> Those are two widely different roles in terms of day to day responsibilities and skill sets, which points to a very bad organizational structure.

<comment><USER10> Depends on the context. Also, it was a smaller organization, gotta make due. We frequently delivered on time and on budget, so, I don't think we lost much with that structure.

<comment><USER11> I've worked in less than 10 person companies that split that role for a reason, it leads to far more effective development and better products.

A project manager's key role is to save money on developers. It's a hugely cost efficient role when done well.

A product manager's job is to ensure the product meets customer needs/requirements. Having them do menial tasks to remove roadblocks for developers is totally orthogonal to their most important tasks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> My PM has a great way for dealing with engineer estimates: increment both the number and the unit.

1 hour becomes 2 days. 4 days becomes 5 weeks. And so forth.

I'm actually somewhat decent at estimating well defined work, so it actually annoys him when one day is one day; but I appreciate his work when some odd stumbling block (usually political; my estimating skills crash and burn when it involves working with humans) comes up and the time doubles or triples the estimate.

<comment><USER13> >4 days becomes 5 weeks

Are you being serious? That only works if the people consuming these estimates don't have a clue and therefore can't call BS. This would get me aughed out of my job.

<comment><USER14> This also astounds me. I can't graps the art of these estimates. I suck at estimating deliviery times, and I'm a pretty good engineer. But I either over- estimate or under-estimate, I find it hard to be on point, there are always unexpected side effects. And I'm known as a sort of miracle worker, when they have something they can't solve, they come to me. But I HATE giving estimates.

If I were to estimate things as suggested in this thread, it seems to me things would never get done. Ever. It simply boggles my mind people want and will fudge estimates on this scale.

<comment><USER12> Pretend, for a moment, that you're working on a one week project. You're estimating that week based on the ability to use an open source project which promises to take care of a large portion of the complexity for you. Also pretend you're new enough to not realize the hollowness of that promise.

It's only three days in to the project that you realize there's a mismatch between what you need and what the project provides. You start a conversation with the project's lead developer; but they're only able to have half of any given conversation in a day. How hard would it be to spend five days researching the cause and severity of the mismatch while discussing solutions with the remote developer?

There's 8 days.

You decide to write a patch for the open source project shepherd it through the internal and external approval process, burning up another two weeks of time.

18 days.

You finally get back and finish the original project, redoing a fair bit of work to account for the changes your patch introduced.

23 days.

You're interrupted throughout this process several times by fires in production that need to be fixed _RIGHT NOW_.

28 days.

Let's make the assumption your PM did their little trick, and slated 2 months for this project. Despite your own estimate being off (through no ill-will by anybody) by about 6x, your work is still completed before it's expected, and the teams depending upon your work are happy as clams. Even if it had finished in the original 5 days, everyone would be thrilled, and you'd get more work to do.

From the PM's point of view, it's a win-win situation. From your point of view, the worst you have to endure is a twinge of "don't you trust me?", offset by the relief of not having to answer "why isn't it done yet" every day from day 6 on.

<comment><USER14> Ideally, from my point of view, estimations should be not over nor under- estimated. They should be on point. Sure, on first glance, under-estimation leads to worse outcomes than oversetimation. But it will still lead to negative outcomes. Rational actors on the wrole chain will benefit and extract the most utility when they are as correct as possible.

While your example showed how project implementation can creep up, I already knew that and my problem is more my inability to give accurate estimates and people's willingness to stretch their estimates by a lot. I KNOW some of you will not agree with me, but I think that giving 4x as long estimates will lead to developers spending more time on the actual implementation without noticeable improvements in the delivery. I know my natural tendency is to do so.

</comment></comment></comment></comment></comment><comment><USER15> The best approach to this I have found is to ask why.

What decision are you trying to make using this estimate? Understanding context helps you to understand what sort of estimate is needed - or whether an estimate is needed at all.

<comment><USER16> The question is to know how much it costs, sometimes they also want to know if they'll meet some external deadline.

<comment><USER17> I think what the GP is getting at is that an estimate in absence of a context is meaningless. The organization may just be trying to get a handle on the rough scope of a job to make strategic decisions. They may also be in the middle of a discussion with a customer about delivering a feature.

The best thing for both the company and yourself is to try to be as high bandwidth as possible and discuss all the potential risks and tradeoffs. Find out what the real goals are so you can optimize a solution to provide for them. Many managers and customers get stuck early on with a particular approach, but if you apply some creative engineering you can come up with a solution which is easier, or folds in with some other goal you were already working on, leverages existing functionality etc.

its on you to express it in terms they can understand from their own position: risk, cost, headcount, schedule, dropping existing features.

if your organization doesn't want to engage in that kind of semantically meaningful discussion, or comes back and says 'I know you said 3 months, but get in don't in 2 weeks' then you need to start managing upward and looking for a new job. or you can just overestimate, and enjoy your free 2 hour lunches for as long as the money lasts.

</comment></comment></comment><comment><USER18> The problem with estimates is mostly requirement analysis.

When people say they need feature A, B and C and ask when I will have it done, I split it up in tasks that take below a day, estimate these tasks and add 50% for safety.

This works in most cases.

But often the reason why projects won't finish on time is, because people don't know what they want.

They ask for A, B, C, you estimate it right or probably too pessimistic and get done ahead of time, but still the project is late in the end because they forgot about D, E, F, G, H and J. In the end you can fit D, E and maybe F in the time you have left because you got A, B, C done quicker than estimated but G, H and J are still missing.

<comment><USER19> I'm not in the software industry so this sounds really odd to me. Don't you guys write proposals to go along with the quote that detail exactly what is in the scope of work? Do you not have a contractual statement of work?

If they come back and say, "oh, we forgot to say we also need D", then the response should be, "that's no problem, we estimate it will take an additional X hours or dollars to implement that. Would you like us to update the proposal?" Or, if you're under budget and you're charging hourly rates instead of a fixed cost, you might even say you can probably add it without going over budget.

PS: I just realized that you're probably talking about internal "clients" so there's no contract or even payment. But I think the same general idea applies. When they bring up extra features, you just say that it's going to take additional time.

edit 2: I guess this doesn't actually help with getting the project done on time. The initial time estimate is still going to be off for the reasons you mentioned. So this comment isn't really an argument against anything you wrote.

<comment><USER20> That's funny. No, for most developers who are asked to provide an estimate, the analogy is more like this:

PM: I want a bridge. When can we start using it?

Eng: Uh, ok, where is the bridge? What's is going over? What kind of traffic will it carry?

PM: I want a bridge. Why are you being difficult? Tell me right now when we can start using it! I've got to go promise my boss that you committed to getting it done by then! Oh, btw, it needs to be done next week.

<comment><USER18> also, they don't want a bridge, they want something like a bridge, but maybe mobile or cloud based.

<comment><USER21> More like they ask for a car ferry to cross the river but really want a bridge.

If you are lucky, you will recognize from their "requirements" (often just a verbal description) that they are describing the characteristics of a bridge (e.g. continuous bidirectional flow), not a ferry.

More typically, after you have built the car ferry, they ask why it doesn't implement continuous bidirectional flow despite never specifying that as a requirement.

<comment><USER22> I think that last description is more on point. People can usually describe why they want something, if asked, instead what they want. It's not too difficult to come up with a reasonable scope if either the dev or the manager knows how to start and scope a project.

Usually they both suck. The manager will send an unclear email. The developer will start developing right away. None have any idea what they are supposed to do, why or when.

<comment><USER18> Often the manager also expects the dev to start right away.

For managers the value of a developer is the solutions they build divided by the amount of time and information they need to build it.

You have always the choice between delaying further or delivering something they like as soon as possible, risking they don't like it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> As a contractor, I'm always asked for an estimate. The client is worried not about the time, but the thought I'll milk the clock, so an estimate ends up being a flat rate.

The best way is to overshoot the time and offer the flat rate. If they bite, I can treble my usual rate, if they come back with a hard negation, I take that as an indicator that they will be difficult to work with.

It's a a tough balance.

<comment><USER22> Don't forget the budget. All clients wants a number so they can evaluate whether they actually have the money to pay for it and whether the project is worthwhile. Noone wants to engage in a 6 months contract thinking it only takes 1.

By the way, watch out when changing from daily rate to project. Legally, you have to deliver the project when you bill for a project, so you are forced to make a contract with well defined project scope to cover your ass. It's quite a lot of (billable) hassle.

<comment><USER23> I'm sure to get everything in writing.

Interesting you bring that up though. I had a client through a contracting company. After the project was done, they said they actually asked for something more, which was never even discussed. I ended up partly unpaid even though I was clearly correct.

The law works when the money is worth chasing.

<comment><USER22> Your story is a school case, unfortunately.

The law is never in your favor as a single man or small shop. It's too expensive to go to court, then determining what should have been done or not done as per the contract is a lengthy and uncertain proceeding.

Clients who wanna pay per project basically want to move the risk over to you. They should pay a premium. Write a solid contract and increase the fees/duration. Most should give up when you start increasing the quote just to establish the contract, it's easier to start a POC and see what could be achieved.

</comment></comment></comment></comment><comment><USER24> I don't do estimates any more but I use forecasting. Like the weather, it's an idea of what might happen given what we know now. I once laughed in a job interview when the interviewer said that they expect 'accurate estimates'.

<comment><USER11> I would have responded "Then your dev process is broken".

</comment></comment><comment><USER25> It is common programmer folklore to apply the 80/20 rule to estimate the time required to implement a feature - and I don't mean the Pareto principle, but "Do a worst case estimate, add 80 hours and multiply this sum by 20". :-)

</comment><comment><USER26> In my many years of estimating, the ONLY thing I have found to work consistently is to meticulously break work into a series of tasks taking no longer than a few hours. Real time, not points.

Don't estimate in a meeting. Let people go back to their desks to research and document the issue. Give them time. It takes longer, but it yields more accurate estimates.

Have the team meet up again afterward and let everyone discuss the estimates and how they arrived at each piece. Let the team come to a group consensus about each estimate.

By breaking it out into a series of small tasks, you also have a daily schedule and a daily benchmark to work against:

[x] X (2 hours est., 2 hours actual)

[x] Y (3 hours, 5 hours actual)

[ ] Z (1 hour)

Now you have a daily update: "I went 2 hours over on Y yesterday and didn't get to Z, but I stayed a little later to get Y finished. I'm at least 1 hour behind schedule, but I think I can make it up today and tomorrow."

This makes you super dependable to management and keeps you on task. Super dependable means you make them look good--which means you're first to get the choice assignments, first to get a bonus or raise, first to get a promotion.

Managers know that schedules occasionally slip; what they want is to know as early as humanly possible so they can make a decision about the project.

<comment><USER11> This is why Agile is such an effective development process. By not using time estimates it removes almost the entire planning overhead and lets devs spend far more of their time actually developing.

<comment><USER26> It really doesn't take that much time to create a detailed estimate (and then pad it for contingencies). Ultimately the entire rest of the world operates on the basis of real time, not sliding-scale points.

<comment><USER11> It never takes long to put time estimates together that will lead to disastrous project management decisions.

The rest of the world benefits far more from faster and more effective product development than it does schedule estimations.

</comment></comment></comment></comment><comment><USER27> Also: Is it an estimate or a deadline?

Most of the time, you will give an estimate, and the manager will turn the sum of your estimates into a deadline. Don't fall into this trap.

<comment><USER8> I try to consistently use the word "target" to head off the ambiguous semantics around time estimates versus "deadlines". It's a little thing, but it can be psychologically easier if one explicitly controls the project language to allow "we need to revise our target" than to be implicitly seen as "not meeting a deadline".

</comment></comment><comment><USER28> engineers hate giving estimates for a variety of reasons that i'm not going to get into here. most modern agile organizations don't value spending time on getting accurate estimates, but some kind of best-faith estimate is still valuable for a lot of reasons.

for medium to large size projects i like to give a confidence score to my estimate to give a sense of how much unknown there currently is.

for example: we think we can get this ticket done in 5 days, but there's a 50% chance it will take two weeks (because of complications in X, Y, and Z).

or the other way, my estimate is 3 days, but if this one thing works out that we're looking into, there's a chance we can finish it in 1 day.

what people are generally asking for with estimates is sizing and complexity, so providing some additional information helps.

<comment><USER29> Some devs seem to have actual phobias of estimates. My team was asked if we can deliver features x or x+ some time next year. (IMO as the dev who knows both the code and x best, we can deliver x in 2018 easily and x+ maybe). In our discussions about it, one guy would only say you can't predict the future, and another guy argued we should say either of them would take two years so that we could have time to rebuild the app from scratch while we delivered them. It's a web app.

<comment><USER28> tl;dr - we engineers are bad at estimation because we're too optimistic, and then we don't want to be accountable to the estimate given based on limited information.

i think we have phobias for estimates because of management repercussions that only happen when you miss an estimated delivery date, or for organizations that put external dates based on a best-case aggressive engineering estimate. then when the engineering team misses the date, there's a retro (when retros should happen for both good and bad sprints.)

i've never been clear why more organizations don't soft launch features or products, and then pick a marketing/external announcement date.

<comment><USER29> I am an engineer. That isn't what I was trying to say. My interpretation of these conversations would be more like "we think managers are morons".

</comment></comment></comment></comment><comment><USER30> My flow adapted for this question:

1\. Why do you need the estimate? Is it to get budget approval, or because you're trying to meet an approved budget? _If they don 't have budget approval then I'm going to charge them something to gather requirements and deliver an estimate. __No budget approval = low on priority list.

2\. We charge a blended rate of $xxx per hour. If you have a detailed requirements list I can tell you if we can do this within your budget. _If they don't have a detailed requirements list then I'm going to charge them to provide one. __After I have the requirements list completed I 'm asking for their budget.

3\. Don't want to pay for a requirements list? I understand. Its okay. Something like this typically costs (low bid), but that will likely change if the requirements are different then my assumptions.

<comment><USER31> Could you elaborate on #3? Do you walk away at that point? A last attempt to show the value of good requirements and get them back to #2, else they are premtively "fired" as a client?

Going to hold onto these. Good phrasing/ideas.

<comment><USER30> In enterprise software, at least the companies I know, they will underbid and return to the well many times for increases. They will blame this on poorly scoped requirements, for which they were not responsible. They will be right, and they count on this for much profit. If you quote virtuously, you will be a victim of your client and competitors who scope/quote less virtiously.

</comment></comment></comment><comment><USER32> Oddly enough t-shirt sized estimates work well.

get a sense whether task is S, M, L, or XL from developers etc... and then multiply it by whatever factor you think S-XL should be in hours/days.

people can't seem to provide time-base estimates - but generally have a good sense of a complexity of a problem.

<comment><USER8> A similar trick to help crystallize thinking about the project is to ask whether it's on the order of hours, days, weeks, or months. This mitigates the fear of speaking a number and having it be enshrined as a guarantee, while connecting the rumination process to the experience of past projects in all their underestimated splendor.

<comment><USER33> I like this approach, especially for getting estimates out of trades that don't like doing estimates before they tear apart your clutch.

"Is this a hundreds of dollars or thousands of dollars problem" can work wonders.

</comment></comment></comment><comment><USER11> If asked for an accurate schedule for a large project, offer management two options.

1) Two months spent writing complete product requirements documentation, while engineers research and estimate all tasks and sub-tasks.

2) We start right now with the minimal documentation we have, using priorities Marketing has given us and work with Marketing to flesh out the details for every component as we build it.

In case 1), you get a schedule in two months. The schedule won't be accurate because it won't be able to anticipate everything. Most likely it won't be able to anticipate how product requirements will change during our lengthy development, and they most certainly will change given that Marketing isn't going to stop talking to customers or thinking of new ideas. But you'll have a schedule.

In case 2) I'll guarantee the project will be finished faster and be a better product. You don't get an accurate schedule either, but you also don't lie to yourself that the one you have is accurate.

</comment><comment><USER34> Apart from the social issues there's a nice cognitive corrective described in "heretics guide to best practises".

1\. optionally divide your project in arbitrary smaller tasks

2\. for each subtask pick a range (min and max estimate) so that you're sure the actual time lies in the range 90% of the time.

3\. imagine the following decision: you can draw one out of 9 black and 1 red marble. If you pick the red you get 10.000$. That's a chance of 90%.

OR: you can choose your estimate and get 10.000$ if it's correct.

If you think about this decision and rather pick the marble-game, then your estimate is too narrow and most likely not correct.

If you pick your estimate over the marble game, it's too wide, because you're more than 90% sure about it.

Adjust your estimate until the decision doesn't matter anymore and both the game and your estimate seem like equal chances to you.

4\. my own addendum for people who are afraid of asking too much: double the result to take the stress of yourself.

</comment><comment><USER35> If you're asked for an estimate. Give an estimate. Part of your job is giving an estimate. Find out how to break the job down into something you have done before, and give an estimate.

Will you see a doctor who can't estimate how long a surgery will take?

Will you take a cab or a flight that refuses to give you an estimate?

Will you take a job that can't give you an estimate of what the salary range will be. They will figure it out when they pay you.

Come on, cut the rubbish folks. This is why we get no respect from non tech folks. Everything doesn't revolve around tech. Businesses have decisions to make based on time product gets to market. They have decisions to make based on cost of product. Estimates allows them to make such decisions.

Learning to give estimate is one of the best skills you could ever have as a developer.

<comment><USER36> You must be new here

</comment></comment><comment><USER37> Bill your clients for estimates and still give ranges. The more they want to dial in those ranges, the more billable time you spend estimating. "How long will it take to estimate" is a question you should be able to answer because you will control the deliverable in this case. Also, if you spend time with them asking questions and helping them discover the complexity of their request, they will soon see the benefit of this process.

Alternatively what I'll do is point out that their request is simply incomplete and I can help them create a better request, which I will then estimate (it's all still billable though).

<comment><USER8> It's critical to position yourself (or your company) to be able to bill for discovery (a separate project, or at least a day-rate engagement). You're a consultant working with the client to figure out what the project actually is. Amazingly, the client often doesn't really know, as can become apparent during that first gathering around a whiteboard. And if they don't know, you're well on your way to a "now that I see what you've done, it's not really what we had in mind" moment.

<comment><USER38> Great point.

Also worthwhile is to consider the overall likelihood of success for projects you take on (and what it implies for future work, quality of life while working with the client, etc). I wasted a lot of time early in my career on projects that I knew were doomed just because someone agreed to pay my rate.

</comment></comment></comment><comment><USER39> One thing I could use help with: How do you respond when someone asks you for a monetary estimate?

I was approached by someone who wanted to hire me as a freelancer, but the requirements were quite vague. He wanted a general idea of how much I billed daily, but I really didn't know how to answer it. $300? $600? What's high enough to hook them, but not too high to push them away? How do you factor in risk? What if they don't like what I deliver?

This seems related to time estimation, but different enough to ask.

<comment><USER40> That's a good question for them to ask, usually you'll go for a lower rate. If possible, try to get them to make an offer, or try to dodge the question (gracefully, do not attempt if not skilled at that).

Another thing that sometimes works is giving a really high number, but then offering a "deal".

YMMV.

<comment><USER39> I did manage to dodge the question, but now I'm not sure what the next step is. Do you have any advice?

Last time I tried this, my rate was high enough that they balked. I'd like to avoid that, but still charge enough to make it worthwhile.

I thought it'd go like this: Start at double my highest rate, then wait for them to counteroffer. Commence negotiation. But last time they just walked.

<comment><USER41> Assuming you're not hurting for work, you want them to wince a little when they hear your rate.

Regular on site visits and full-time, local work? $1000/day minimum in the high cost of living area I'm in (Boston area). If they straight out walk at that, you dodged a bullet.

Bidding too high and losing the work is way, way better than bidding too low and getting it!

</comment></comment></comment></comment><comment><USER42> At our company we didn't estimate entire projects, but separated tasks until it was 3-5 hours piece of work that everyone agreed "it's realistic, I can do it". The big time then simply summed up with 30% buffer for delays. Since our customers mostly paid for hours, it was also a good base price builder.

Big projects can suffer from this because little architecture is involved (and we worked on already existing systems). Otoh, I've seen no big local project that wasn't an architectural mess once it hit a deadline hard. It is better to not have one than to have a set of rules that you must obey, while other parts of system don't even care of or contradict these.

Personally I don't believe this "I'll get back to you with an estimate" thing. It is just first iteration where you go relax and try to formulate at least 5-10 questions that you think you should ask foremost to _start_ building an estimate. If you come back with an answer instead, then it is still wrong, maybe even worse than random, since you estimated a different thing. For us, estimates and requirements always moved, as they were functions of delays and business priorities that change unpredictably. I didn't like to deliver the entirety on a deadline because my job was to support that for years, not throw a bill at them and run, as all integrators did.

Maybe, maybe these SE-users are speaking about coding phase, when all "business analysis" was done perfectly. But ime it is you coder who collects all the knowledge, because no one can. Or it is you who is non-coding analyst who must estimate, because non-analytic coders don't have a clue what a big picture is.

</comment><comment><USER43> In "debugging the development process," the author recommends the method of "make a quick estimate, then give a range between that and 5x that. Suggest that the estimate can be made narrower only with significant additional scheduled work."

I like it, because it's true, it works, and it deals with the inherent uncertainty of software development by letting those who ask decide how much they want to pay for how much certainty.

</comment><comment><USER44> There is a difference between establishing a deadline and estimating relative effort and complexity. The former is problematic. The latter is important and should be done and then revised continuously.

The process of building software includes discussing what has the best impact to effort ratio. Both are estimates and will not come out as expected.

The logical response to managers that expect you to always hit deadlines is to inflate estimates enough that you will.

</comment><comment><USER45> Tell them that it'll take an hour or so of effort, but they'll have their estimate by tomorrow morning. Then spend some real time documenting the more and less certain areas of change, the likely risks, and the unlikely-but-very- costly risks. The estimate will be dramatically more accurate, but more importantly, _they will stop asking for it when it doesn 't matter_.

<comment><USER45> Frequently, the right answer is actually "I won't know until I spike on it - that will take a couple of days".

</comment></comment><comment><USER46> 1a. Make (but don't immediately communicate) a best guess based on initially determinable requirements (functional _and_ non-functional), which includes a large amount of contingency.

[It is ideal to understand the problem with "use cases" and "stories" is that they are a poor building block for estimation and development because they inevitably require further and further decomposition.]

1b. Formally (in writing) present the estimate, together with the known requirements upon which it is based.

1c. Include in writing that changes in requirements (and undiscovered requirements) w ill affect the estimate.

1d. Document and immediately communicate in writing all new and changed requirements.

When your boss's boss (inevitably) asks him what the problem is with this project taking so long, and he responds to him that you the developer (or team) "keeps finding problems and more work to do", you can at least rely on a written record of the project's changing scope.

</comment><comment><USER47> The requirements will be a rocket ship to Mars, while all they need is a bus to the picknick. You argue that they really only need a bus, but then they go with a competitor, that delivers a rocket that almost makes it to the stratosphere. Then they take taxis to the picknick. So you promise the Mars mission, but with the estimate of the bus trip.

</comment><comment><USER48> One thing I've been unable to ever see adopted is a true bottom up planning strategy, where the time to delivery is estimated from historical data. Say last X project took Y time, similar Z project will thus take Y time. And from there, the business plans timeline and delivery dates.

The reason for this is that in practice I've found estimates are an indirect way to define scope.

You need to ballpark the minimal viable product in a range from under a month, a month to 3 months, 3 to 6, 6 to 1 year, over a year.

After that, its just about downscoping all the "good to haves" based on if there's time left from the desired deadline or not. As long as you delivered the "must have" in your timeframe it should be good.

<comment><USER11> The more work that is put into a planning process, the later the product will ship.

</comment></comment><comment><USER49> Be glad. Worst is when managers estimate themselves.

Be pessimistic, don't count happy flow only. Count also meetings and other organizational slowdowns into estimation. It can be anything between 30% to 200% of needed time depending on what politics on your company is.

Break it down, and guess shortest time possible, longset time possible and them most likely time for each task. Then do (min+max+4×likely)/6 and sum them. The result will look intuitively too long, but resist temptation to shorten it.

Then resist pressure to make it smaller. If they want it faster, keep calm and ask them whether take out this or that feature. The only way to make it faster is by cutting features.

<comment><USER11> No time estimate should ever be made by anyone not responsible for implementing it.

</comment></comment><comment><USER50> Estimates are important.

If you can't answer right away, "I'll get back to you" after having some time to think about what's needed.

Then just keep that person up to date on timeline progress and it other work that's been requested impacts that estimate.

</comment><comment><USER51> Explain that the way to do estimates is to have a process that starts by breaking down the work into the components of the design, estimating each component, and adding it up, with small padding to each granular component. The more granular the breakdown, the more accurate the estimate. For a single top-line complete project guess (which is what you are being asked) you should use a large pad, as comments below say, double and shift. If you can afford the time to do the breakdown, you will get a closer and more realistic number, and have some of the project planning work done to boot.

</comment><comment><USER11> The only correct answer for a programming estimate is, "No one knows".

Seriously, tomorrow morning I'm going to be in a long planning meeting where I'm going to be asked for time estimates. And this time i'm going to refuse to give any.

I've spent a fair bit of time preparing my boss, my bosses boss, and people on my team for this moment, by explaining good Agile development doesn't use time estimates. I'm going to insist that I and my fellow developers will point problems using planning poker, but the points won't correspond to any fixed time amounts.

</comment><comment><USER52> If you're having trouble figuring out an estimate then try the following exercise. Imagine a pointy haired project manager who knows little to nothing about code say "Code refactoring, let's see that's what, one or two days?" Immediately you will have outraged yourself and you will start figuring out the right answer. And once you have, double it. If they question you and counter your estimate give a very uncomfortable "uhhh...." followed by "it's much more complicated than it seems, I don't think that's possible".

</comment><comment><USER53> "Six to eight weeks"

[https://meta.stackexchange.com/a/19514/154820](https://meta.stackexchange.com/a/19514/154820)

</comment><comment><USER54> I give an estimate with an error margin, that is usually larger. eg something like "that will take about 3 weeks, plus or minus 2 months". The plus or minus bit reflects the uncertainty in requirements, things that could change etc.

Often it is the case the goal can already be achieved with existing functionality, but may not be as direct or elegant. That is why I include the "minus" bit covering this scenario where a solution is already there.

<comment><USER55> > I give an estimate with an error margin, that is usually larger. eg > something like "that will take about 3 weeks, plus or minus 2 months"

I can't tell if you're being serious. How do people respond to such a non- estimate?

<comment><USER56> 3 weeks minus 2 months...I'd probably ask if that means it might be done already

<comment><USER54> Yes, that was precisely the point with "Often it is the case the goal can already be achieved with existing functionality, but may not be as direct or elegant".

</comment></comment></comment></comment><comment><USER11> I once worked in an organization that only allowed engineers to make estimates once, at the beginning of typically 6 month projects. No elaborate research was allowed, all estimates were given off the cuff in a single 1 hour team planning session.

In the 6 years I was there they shipped around 40 different software products, without once shipping late or a buggy product, and won dozens of industry awards.

It's not time estimations. Its how you manage your process.

<comment><USER57> > 40 different software products

What kind of software products?

<comment><USER11> Graphics and desktop publishing utilities. And I mistyped, it wasn't 40 different products, it was 40 different major releases, only about 8 different products. Though hundreds of minor releases counting Japanese, Spanish, French and German versions, and point releases.

</comment></comment></comment><comment><USER58> Just keep in mind that estimation != promise. Make estimations to help you plan your time, but never commit these to management who turns them into promises.

</comment><comment><USER59> The key to estimation is good historical data. If you have data on how long previous things took, estimation can be reasonably accurate.

<comment><USER60> This is the technique I've adopted.

Interestingly when I was first introduced to scrum years ago, this is how my team was taught to estimate stories. Find similar stories (or, if you're just getting started, requests of comparable scope) you worked on in the past and use those as a reference.

What happened instead: team quickly ended up equating story points to some unit of time (e.g. 1 pt = 1 day to complete). Then, for a new story, play planning poker where each developer makes estimates based on rose-tinted projections of how long they imagined it would take them to finish the job if they were working on it alone without major distractions or unanticipated complications. After everyone reveals their estimate, argue pointlessly with each other for a random amount of time. Then, once the scrum master has caught up on all the latest notifications on his or her phone, either cave to the opinion of the most belligerent member of the team or average the results.

After we got burned a few times, we added a "shit happens" cushion while still following the same basic procedure. I'd be surprised if that team didn't continue to use the same protocol to this day while gradually ballooning their cushion to the point their estimates coincided with the "double the number, shift to the next time unit" rule.

Daniel Kahneman provides a good lesson on the difference between these kind of expert-driven (for various definitions of the word "expert") estimates and the sort of historical data-based approach you suggest in Thinking Fast and Slow.

It's excerpted here:

[https://www.mckinsey.com/business-functions/strategy-and- cor...](https://www.mckinsey.com/business-functions/strategy-and-corporate- finance/our-insights/daniel-kahneman-beware-the-inside-view)

<comment><USER11> Story points should never be equate to any unit of time. No wonder people argued. And fire the scrum master because they weren't running an effective agile process. Switch the team to a Kanban board, and prioritize, don't estimate, work.

Time estimates are a fools errand, even with historical data. Historical data won't tell you if this task is really similar to that old task, or if fast dev will work on it or whether the slow dev will, or how many meetings devs will be pulled into, or who will need PTO, etc, etc.

</comment></comment></comment><comment><USER61> Tell them there's a probability density function associated with the result. This allows you to get away with any outcome :)

</comment><comment><USER60> My favorite recent story on estimates comes from a previous company. (I've written about them before. There are reasons I am not working for them any more.)

Before I was unceremoniously shown the door, we had been discussing a rewrite of our main customer-facing website. It was basically a bank website, but for a bank that only served a few hundred clients internal to the company.

The most recent version had been written a few years ago in a Python web framework that was now defunct. This time we were going to do it right using Rails. We had been talking about a 6-8 month timeframe for release of the minimal viable version once the dev team got started. We had been talking about getting started for about 3-4 months while we got sidetracked with other spot fires, upgrades, and all the other workaday delays. The team used Agile Scrum, mostly in the ways you aren't supposed to use it (meandering voluntary standups that some developers would attend at their whim, perfunctory retrospectives in which process issues were swept under the rug, systematic disregard for the definition of done and best practices, an unhealthy focus on burndown charts). There was no special business urgency behind the upgrade as far as I knew other than the old application was getting long in the tooth and looked a bit out-of-date. It was still floating beneath the surface of the backlog when I was finally walked from the building.

A year or so later I got together for lunch with a couple friends still with the company including a project manager from the old team. I asked her how the big bank site rewrite was going.

"Oh, it's about where it was when you were still working there. Except now it's urgent."

She was not happy. The banking unit had signed up some new customers who were outside the bank and the dev team's boss said executives were eager to integrate them into the new online system. So he asked my friend, as product owner, to give him an estimate on when the new site would be ready. My friend told him she'd get back to him on it.

She logged into their project management system, filtered out all the non- essential user stories for the project, added up the sizing on the essential ones that were left, and then formed an estimate based on the team's average velocity over the last few sprints. Then, just to be safe, she removed a couple more stories that probably were essential to the MVP, added up the new total, bumped up the team's velocity a few points on the reasonable premise that they were inveterate slackers, and updated her final estimate. She then met with her boss to present her results.

She premised her estimate by outlining her methodology. She reminded him that the last version had taken over a year to complete. Then she dropped the number:

"Six months."

"Too long. We need to have it ready in three months."

My friend looked at him slack-jawed.

"I don't think that's possible." She started to review her methodology. He stopped her.

"It is possible."

"How?"

"Double the team's velocity."

This guy had been the one who had championed scrum to the company. He had hired the consulting firm that ran the three-day scrum on-site workshop that had introduced the principles of Agile Scrum in detail to the company. He had attended the workshop. We all had. Twice!

My friend found a new job and left the company within a month.

<comment><USER11> I'm going to add burn-down charts to my list of bad Agile fails.

\- Using points as measures of time

\- Redefining "done" as something that's not really done

\- Trying to ship fixed feature sets ("your commitments!") within a sprint

\- Any type of time estimates.

\- Burndown charts

</comment></comment><comment><USER62> When possible, I give three numbers. A best case scenario, the nominal scenario and the worse case scenario.

Software Development is full of hidden pitfalls and I've found this can keep development and management teams both on the same page when unforeseen obstacles arise

</comment><comment><USER63> Don't forget psychological aspects: [http://www.cs.toronto.edu/~sme/papers/2005/ESEC- FSE-05-Arand...](http://www.cs.toronto.edu/~sme/papers/2005/ESEC- FSE-05-Aranda.pdf)

</comment><comment><USER64> I like to say, "my gut says X days. But I'll have to get back to you." I think there's a lot value in having the conversation with the PM or manager or whomever in the moment. And being non-committal is frustrating for the other parties.

<comment><USER65> That "gut estimate" converts to a concrete deadline in your PMs mind before you put a period at the end of your sentence.

<comment><USER64> Not in my experience. I think it's about managing expectations. You just have to be clear about what you mean with that individual. If that PM takes it to mean that then you need to find another way to communicate your message.

I think what I intend to say with that can be, "I don't know how long it takes and it'll take more planning to figure it out, but I'm willing to participate in this conversation so that we can continue to effectively plan in the current context."

If the current context is "concrete" then you probably don't want to give a number. If the conversation is (and this was my assumption before) "here's a feature we want done but we're trying to figure out it's priority and feasibility" then giving a gut check adds value. You just need to be clear in your messaging.

And if someone uses a gut check number against you "but you said X days!" Then you need to call them on it and make sure you explained the discrepancy.

</comment></comment></comment><comment><USER66> At my company we use simple analysis on previous estimates and adjust future estimates based on past errors. We are usually about 70 to 100 percent accurate using this method. However, projects are usually not more than 7 days of work in my case.

<comment><USER67> This is something I wish I saw more talked about: how to get better at estimates. I wish more people dedicated time to reviewing their projection & mindset at the time, then look at the task timeline, then write down what caused it to go off schedule.

Sometimes it's an environment change. Are these consistent? Can they be modeled statistically?

Often, it's an inaccurate belief in the work to be done. Was it lack of requirements, that had to be expanded? Etc.

When I work in development, I spent up to 20% of my time on "overhead" tasks. These are of the estimate review type, not meetings. It's something a great manager will do without wasting his team's time, but as an independent, I spend a lot of time doing it myself, and it's amazing how much it helps to dedicate time and write things down.

</comment></comment><comment><USER68> Map out all the requirements and tasks. Put an estimation to each. Sum up the hours. Multiply the estimate by 2.5.

Even then 2.5 isn't enough of a hours multiplier.

A lot of these enterprise systems have traps and tricks other developers and analysts have put in. :( :/

<comment><USER46> > Map out all the requirements and tasks.

Arguably problematic even when the project is _relatively_ trivial. Try it for a new "Air Traffic Control System" or new "Bank Customer Lending Management System".

</comment></comment><comment><USER69> "Fixed scope, fixed price. Flexible scope, flexible price."

</comment><comment><USER70> I tell them whatever I think they'll think is reasonable. What actually happens won't bear much resemblance to whatever number I give, and it won't matter to whether we ship.

</comment><comment><USER71> I don't know. I just know that it's childish to refuse to make an estimate at all.

It's part of being a professional to be able to give some kind of ballpark estimate.

<comment><USER11> It's unprofessional to give time estimates since you know they can't ever be accurate and it's poor software development practice to rely on them.

Its your job to educate your boss and your team about this.

</comment></comment><comment><USER72> "The task of estimating how long a feature would take to implement is NP-C. Give me a quantum computer and come back in 4B years for an answer."</comment>


How to Ease Tensions Between Cyclists and Walkers - <AUTHOR> https://www.citylab.com/life/2019/08/amsterdam-bike-pedestrian-safety-shared-space-street-design/596542/ <comment><USER2> My motto as a cyclist: "The pedestrian is king -- no matter where you encounter him." And those kids on skateboards? Be happy that they are not sitting on their butts playing a video game.</comment>


LabCures: research crowdfunding by lab, not by project - <AUTHOR> https://labcures.com/

<comment><AUTHOR> This very recently launched crowdfunding site is a spin-off venture [1] of the Bay Area based Buck Institute for Research on Aging [2].

A bunch of people (such as the folk at experiment.com ) are in search of the magic bullet that makes KickStarter-like crowdfunding work well for research. I don't think a straight port can work, as the incentives and motivations are all very different. But I'm optimistic that someone will find the magic recipe that will open the floodgates.

This is an age of distintermediation, and crowdfunding seems like something that will inevitably take over a chunk of the sort of research fundraising that presently flows through big per-disease charities. But do people who go beyond a nebulous support for curing a specific disease really want to pick and choose projects, or are they happier rooting for teams? If the latter, science crowdfunding may inevitably shift in the direction of a LabCures-like approach.

[1]: [http://www.marinij.com/novato/ci_26246445/new-buck- institute...](http://www.marinij.com/novato/ci_26246445/new-buck-institute- spinoff-will-use-internet-solicit)

[2]: [http://www.buckinstitute.org/](http://www.buckinstitute.org/)</comment>


Making Games with Python and Pygame (2012) [pdf] - <AUTHOR> http://inventwithpython.com/makinggames.pdf?27f655 <comment><USER2> Is pygame the best way to get into game programming?

Or is it better to use HTML5 these days? I wonder if someone could write something to compile pygame to HTML5?

<comment><USER3> If you're wanting to use Python, it's probably PyGame. If you don't care, I've had a great time with Phaser.js (www.phaser.io) when it comes to HTML5. It's intuitive and the project is pretty active (and seems to be picking up speed).

<comment><USER4> I second Phaserjs. I switched for my Ludum Dare attempts and it's been great to work with. PyGame's distribution story for events like Ludum Dare was pretty horrible.</comment></comment></comment>


What English sounds like if you don't understand it - <AUTHOR> https://www.eiman.tv/blog/posts/marklish/index.html <comment><USER2> The same claim is made about this song [https://www.youtube.com/watch?v=-VsmF9m_Nt8](https://www.youtube.com/watch?v=-VsmF9m_Nt8)</comment>


Ask HN: Hacker Tent City - <AUTHOR>

So, we are seeing that regular people beat us hackers to tent cities. Where would the perfect place be for a hacker tent city?<p>Someone else mentioned using cargo containers instead of tents with YContainer funding them. <comment><USER2> Hackers are regular people.</comment>


NSA chief who oversaw sweeping domestic phone surveillance joins Amazon board - <AUTHOR> https://www.zerohedge.com/political/longtime-nsa-chief-who-oversaw-illegal-domestic-surveillance-joins-amazon-board-directors <comment><USER2> We've merged some of the comments into [https://news.ycombinator.com/item?id=24426500](https://news.ycombinator.com/item?id=24426500) and left the ones complaining about ZH here.

</comment><comment><USER3> Mods: would you consider updating the link to another source[1][2]? The current source is both a general distraction and is itself a common source of misinformation (even when the news itself is factual).

[1]: [https://www.cnbc.com/2020/09/09/amazon-adds-former-nsa- direc...](https://www.cnbc.com/2020/09/09/amazon-adds-former-nsa-director-to- board-after-jedi-fight.html)

[2]: [https://www.reuters.com/article/us-amazon-board/ex-nsa- chief...](https://www.reuters.com/article/us-amazon-board/ex-nsa-chief-keith- alexander-joins-amazon-board-idUSKBN2603A7)

</comment><comment><USER4> Is ZH the only source reporting this story? I mean, I love me some ZH, but it can turn some people off so it might be better if a less controversial outlet was reporting this...

<comment><USER5> Why though?

ZH is the only one willing to report things that others would rather you not know about.

If every so often they report something batshit crazy, that's a small price to pay.

I don't see an issue with linking the good stuff. And ZH has plenty.

<comment><USER6> Every other post is a misleading conspiracy theory with cherry picked facts and data. ZH is awful.

<comment><USER7> How did you determine the posts are conspiracy theories ? Is that your personal opinion?

<comment><USER6> No. It is based on the fact that they objective cherry pick facts and data, over and over again, to support conspiratorial narratives.

</comment></comment></comment></comment></comment><comment><USER8> ZeroHedge is an anonymous conspiracy blog. It is not a reputable source of information. It is a constant source of fear, uncertainty, and doubt. They occasionally post rehashed actual news to appear legitimate. Please be cautious about entering that rabbit hole.

<comment><USER9> What's your point? Is the report false? I see similar reports elsewhere.

[https://www.cnbc.com/2020/09/09/amazon-adds-former-nsa- direc...](https://www.cnbc.com/2020/09/09/amazon-adds-former-nsa-director-to- board-after-jedi-fight.html)

I suppose you just meant to warn against other content there that are inaccurate? Which ones, though? I'm not familiar with that site.

<comment><USER10> What we know:

* JEDI contract was awarded to Microsoft

* Amazon brought the case that this contract was not awarded fairly, specifically because AWS was proven to be cheaper for the same capability, indicating favoritism.

* Amazon adds national security director to its board (which is different then giving him a director position in charge of a program btw)

* Amazon provided/provides cloud service to CIA

What is extrapolated without any sort of proof

* Amazon wants to spy on citizens

Be aware of news sources that focus on the latter rather than the former. Because you can also extrapolate that Amazon just REALLY wants the JEDI contract for no other reason than money just as well as you can any conspiracy theory.

</comment></comment></comment><comment><USER11> I can't believe the amount of conspiracy nonsense pervading HN recently. Seriously what is going on? We're pushing a zerohedge article? What's next, infowars?

<comment><USER12> Is it really so unbelievable to be wary of the former director of the NSA joining a company that has enormous amounts of data as well as literal microphones in millions of homes? I don't really care about the source, facts are facts and this appointment is a bit scary.

</comment></comment><comment><USER13> "Chink in one's armor" for YC when anything from ZH oozes its way onto the front page.

<comment><USER14> Well, there's other sources for this, becauses it's actually true. I wonder what "armor" you think HN even has as inane tripe like [https://news.ycombinator.com/item?id=24426407](https://news.ycombinator.com/item?id=24426407) is glued to #1, while something that actually matters and pertains to the responsibilities of this crowd is, once again, penalized.

<comment><USER13> I'm not arguing that the story itself isn't frontpage newsworthy... just we should not be validating that particular source with pageviews/clicks.

ZH has pushed Coronavirus misinformation, Seth Rich conspiracies, and openly labels itself as "far-right libertarian". Of course this unsurprisingly attracts some slice of the HN demographic :)</comment></comment></comment>


Why Bitcoin Matters More Than Blockchain - <AUTHOR> https://www.forbes.com/sites/briankelly/2017/10/24/why-bitcoin-matters-more-than-blockchain/#69f2537837ac <comment><USER2> >If I told you that I developed a mobile app that was able to use computers to modernize the 600-year-old process for transferring value, you might think I was crazy or you might ask how to invest. Bitcoin is this app, and the disruption of the 600-year-old double entry accounting system is why I have called Bitcoin one of the most important innovations in the history of finance.

I know someone who bought a 100 bitcoins back when they were under a dollar. He bought them so he could order drugs. He made one transaction one time and still sits on his 600k now and is holding on for dear life. If he looses all the money he still doesn't care because he sees it as only loosing $100. This is weird to me. I imagine there are probably lots of bitcoin millionaire HODLers out there just waiting for the world to start using it as a currency and maybe buying a new Tesla. As the rest of the world hops on the bandwagon hoping for their millions too, IMHO it starts looking more and more like a ponzi scheme. I guess it worked for a few lucky ones out there and still will, but it seems like bitcoin will behave like Gold and not so much as a transnational money tool. It's a good story - a great story... and that's why it's not a bubble THIS time!</comment>


Show HN: P2P delivery for international migrant population - <AUTHOR> https://www.flyoutapp.com/ <comment><AUTHOR> Co-founder here. My girlfriend and I([https://ippad- itn.eu/researchers](https://ippad-itn.eu/researchers)) quit our jobs 4 months ago, and have been working on this day and night off of our savings since then. FlyOut is born to address a problem that is driven by a "need" and this "need" is a global problem and wanted by the sheer volume that addresses the average middle class who study or work abroad and consistently miss the products from their culture back home or who are addressing their family members that are anxious to get in touch with foreign local products. More than 8 million people travel/day ([https://www.iata.org/en/pressroom/pr/2013-12-30-01](https://www.iata.org/en/pressroom/pr/2013-12-30-01)). Apart from our technical solution, what matters to us is how many of them know our product!!. Massive market awareness is our 24/7 strategy.

with regards to safety: We are making it mandatory for the sender to put up detailed images and description when the need is posted. Furthermore, we have an integrated notification system to make the traveller aware to check items before acceptance from the sender. And there are also clear mention of caution every step of the way and all marketplace legal implications will be automatically inserted as soon as the items are added. A legal disclaimer that says : the contents that user wants to be shipped does not contain any narcotics, etc. will also be inserted as part of the algorithm.</comment>


Ask HN: Are mobile phones on a plane taking off or landing really dangerous? - <AUTHOR> Are there any actual studies and detailed research with proof that having my mobile phone on during take off or landing provides and increased risk of the plane crashing (or other adverse reaction?)
I mean logically if planes did not have sufficient shielding for this would a terrorist not just bring about 1000 phones (say its for export for sale) as hand luggage and just leave them on? Also some planes now now allow mobile phones to be used on board.
Things that have been done for the sake of it or have continued because that was the way it has always been really annoy me. And I really hate having to switch off my phone and my RSS reader getting dirty looks for fellow passengers. <comment><USER3> From the press release for a Carnegie Mellon study in 2006:

 _"We found that the risk posed by these portable devices is higher than previously believed," said Bill Strauss, who recently completed his Ph.D. in EPP at Carnegie Mellon. "These devices can disrupt normal operation of key cockpit instruments, especially Global Positioning System (GPS) receivers, which are increasingly vital for safe landings." Strauss is an expert in aircraft electromagnetic compatibility at the Naval Air Warfare Center in Patuxent River, Md._

<http://www.cmu.edu/PR/releases06/060228_cellphone.html>

It's true that no crashes have been positively linked to cell phone use, but it's also true that black box recorders don't measure RF interference so it would be difficult to do so.

edit: and here's a link to the whole paper [http://spectrum.ieee.org/aerospace/aviation/unsafe-at-any- ai...](http://spectrum.ieee.org/aerospace/aviation/unsafe-at-any-airspeed/0)

 _In one telling incident, a flight crew stated that a 30-degree navigation error was immediately corrected after a passenger turned off a DVD player and that the error reoccurred when the curious crew asked the passenger to switch the player on again._

<comment><USER4> Seems like GPS for landing is poor dependency, considering how easy it is to jam GPS...

<comment><USER5> That's why RNAV (GPS) approaches are still not allowed (for commercial flights) AFAIK.

30 degree error has nothing to do with GPS though. Probably DVD player interfered with Localizer signal.

<comment><USER6> GPS approaches are allowed, FWIW.

I'm also not sure the localiser signal was involved since I don't think the crew would have gone to the back to get the passenger to mess around with the DVD during an approach.

</comment></comment></comment></comment><comment><USER6> I flew for the airlines.

The problem is not your everyday takeoff and landing. The problem arises when the weather deteriorates to near zero visibility and the crew is relying on instrumentation to find that strip of pavement, at 130 knots.

Instrument approaches rely on a narrowing volume of radio signals, the closer one is to the runway. The tighter the signal, therefore, the greater the deviation should something go wrong. Think of threading a string through a funnel, if you touch the edges, you lose. Now do it on a trampoline while someone else jumps on it. I assume we can all agree that wildly porpoising a 200k lb jet, 400 from the ground, chasing a signal, is not a good idea.

Vehicles on the ground are prevented from encroaching on the approach signal area, when aircraft are shooting approaches in reduced visibility conditions, to prevent them for interrupting the signal. In the cockpit you can see your signals fluctuate if someone does cross that threshold. It happens.

When visibility is good, it is a non event but when you can't see jack, having your guidance just start dancing around, gives one moments of pause.

The phones do interfere in some manner. TO what degree, I can't say. I have forgotten to turn my phone off before takeoff and get the annoying beep in the headset when we descend into an area with coverage, so something is going on.

The reason they ask you to turn it off is because they can't tell you its okay, because they haven't tested it. They can't say, well turn it off if it's cloudy or if the bases are below 300'. Some departures and arrivals require precise navigation, even in good weather, for traffic flow reasons. Missing a fix on departure or arrival could cause traffic alerts or aircraft deviations.

All rules exist for the worst possible scenario. Not the milk run. But how do you explain that to the traveling masses? You should be more concerned with the fact those little dixie cup oxygen masks they instruct you to put on in the event of a decompression, won't actually supply you with oxygen when the shit hits the fan at altitude. It's a partial pressure thing.

That's just between you and me...

Edit: At the end of the day, it is the law. If the crew is having a bad day and has a stick up their ass, they can make your day a lot worse. You need to ask yourself, does ignoring the rule, no matter how inane you think it is, really make a body cavity search worth checking the latest XKCD update?

<comment><USER7> Isn't the avionics room under the cockpit shielded to sustain operations through lightning storms, signals bouncing off the ionosphere, solar flares, etc.?

I've flown commercially with my phone left on and privately in Cessnas and I haven't experienced anything negative. My dad's a pilot too by the way and he said that there's no supporting evidence, but this is a just small rule so might as well comply.

<comment><USER6> There is no supporting evidence. That is part of the problem. The FAA has enough on their hands trying to get the air traffic control system into the latter half of the twentieth century, without trying to test for every stray signal and how it might affect the navigation. A blanket policy, restricting all devices does that.

The wiring is shielded to an extent but there is no special safe room for the avionics. A lot of it is in the nose, right in front of the crew. It is, after all, a very thin tube of aluminum we are all shooting around in. Weight is something to be avoided.

</comment></comment></comment><comment><USER8> The plural of anecdote is not data, but stories are fun.

Last Christmas, I was on a multi-hop flight back to SF from the east coast. We were going to be landing in Vegas, and I was talking to a flight attendant. She mentions that conditions in Vegas were a little crazy, as the runway doesn't drain properly and crosswinds are common.

As we're preparing to land, the captain gives the usual speech. It's going to be a little rocky on the landing; there's a sleet storm, etc.

We're making our approach, and the flight attendant gets on the PA. "Someone's cell phone is on. Turn it OFF NOW." A minute later: "Someone's cell phone is still on. I need EVERYONE to doublecheck their phones, and get that phone switched off!"

We ended up diverting to Phoenix, because the pilot did not feel comfortable making an instruments-only landing. His announcement was the only time I've ever heard a pilot sound audibly rattled on the PA.

<comment><USER9> Did it turn out that anyone actually had his phone on?

<comment><USER5> How do you imagine they would find that out?

Probably the problem was that during approach pilots had the usual GSM buzz in their headphones while trying to communicate with ATC.

Do you really want your pilots not to hear ATC instructions on take-off, landing or taxi? Like not hearing landing clearance, or which runway exit to use, or what other traffic to lookout for.

Do you even know what was the main cause of the deadliest air disaster (583 dead)? That's right, not hearing ATC instructions.

<comment><USER10> To be able to hear the gsm buzz in their headphones, the cellphone would have to be on their person, turned on, and be about send/receive some sort of call or data. If a cell phone from a distance away can cause a gsm buzz, then being in an area that has cell phone reception would cause the buzz and they need to design their headphone systems better.

</comment></comment></comment></comment><comment><USER11> If they were really dangerous, I suspect they wouldn't let you have them in the cabin at all. "Everyone turn off your phone" isn't the level of safety compliance major airlines typically rely on.

<comment><USER12> If they were really dangerous, Al Qaeda would be using them to bring down planes.

<comment><USER13> That would be like al-Qaeda operatives trying to cause road accidents by not recalling their Toyotas. [Theoretically] increased risk != an effective weapon.

</comment></comment></comment><comment><USER14> Please, please let's let the airlines keep this rule no matter how little it has to do with safety. If you get an honest answer from a pilot, they'll tell you this was never covered in any flight school, and they usually leave their phone on, but can you imagine a flight where that business guy who just doesn't get it spends the whole time on flight talking on the phone?

<comment><USER15> Consider this: you're on an eight hours long flight and you need to make a really urgent call. There are no technical reasons why you wouldn't be able to do so, but it is forbidden because some people would abuse it and wouldn't be considerate to other passangers. It's not the phone that should be banned, it's being an inconsiderate prick that should be disallowed.

<comment><USER16> But until we figure out a way to ban being a prick I'll take the blanket phone ban.

And what is this urgent call about anyway? Maybe to you it seems urgent and to me it just seems like you're being inconsiderate.

<comment><USER17> Perhaps you are an eminent surgeon and someone is calling you for a life or death consult.

</comment></comment></comment></comment><comment><USER18> There's a pretty robust wikipedia article about this

<http://en.wikipedia.org/wiki/Mobile_phones_on_aircraft>

<comment><AUTHOR> Thanks for the link, a few good quotes from there:

Now this I can definately belive: "the report concludes that the primary reason for the ban on cell phone use in flight is that neither the FAA nor the FCC are willing to spend the money to perform conclusive safety tests. "

God flight attendant observations? Thats the evidence that is reliable? How could you isolate for all the other factors? "However a few reports state that anomalies were observed to appear and disappear as the suspect device was turned on and off which would indicate a high degree of correlation."

"Degrees of correlation or confidence were not among the data summarized in the report."

"There is no smoking gun to this story: there is no definitive instance of an air accident known to have been caused by a passenger's use of an electronic device. "

This is my point - are we still in 1984? "will exceed demonstrated susceptibility levels for equipment qualified to standards published prior to July 1984"

BBC report: "most of the evidence is circumstantial and anecdotal. There is no absolute proof mobile phones are hazardous."

"Whether interference from small battery-powered devices should have any influence on electronic systems that should be designed to fly through lightning storms without failing is often disputed by critics of the ban."

<comment><USER3> _This is my point - are we still in 1984?_

No, but I'm pretty sure the point is that planes from 1984 are still in use.

<comment><USER19> The airframes might be, but they definitely have been upgraded/retrofitted with newer gear.

My favorite is the industrial, hardened switch for 'Internet Off' on Delta flights with onboard Wifi now (which I can't believe I can't find a picture of!).

If I can use WiFi on the plane while it's flying, why not while it's taking off and landing?

<comment><USER20> Because if something goes wrong the pilots have a lot more of time for a corrective action during flight. Not so much during take off and landing.

</comment></comment></comment></comment></comment><comment><USER21> I'd like to know what drove the relatively recent policy shift around demanding that phones and other devices be "completely off" at takeoff and landing, with airplane mode deemed insufficient. From a visual survey of people turning their phones on later, this prohibition seems to be obeyed mostly by one teenager on JetBlue with an iPod once.

<comment><USER22> I've noticed exactly the opposite on recent flights between NZ and Australia -- they're now a lot more tolerant about having mobiles in flight mode (and specifically say so in the pre-flight announcement) and they let you turn your phone on as soon as the plane has landed. Previously you had to wait until you were "well inside the terminal".

<comment><USER21> "Well inside the terminal" comes as a surprise -- in the US, the carriers have traditionally tolerated everyone snapping their phones on within a few seconds of touching down. Which is really just another oddity, now that I think about it.

</comment></comment></comment><comment><USER23> This is strictly anecdotal evidence, but I'll throw in my 2 cents here. I have a private pilot certificate and am working toward an instrument rating right now, which involves being in continuous contact with air traffic control, flying in low / zero visibility conditions, and relying on aircraft instruments to guide me on landings.

On numerous(if not all), I've had my iPhone with me, switched on and even in my lap at times(to use the stopwatch). Occasionally I would keep it in airplane mode on extended flights, but only to conserve battery life. Despite incoming calls and SMSs during these flights, not once have any of the instruments been affected by the phone.

We can all agree that a four-seater Cessna and 767 are very different, but for nav/comm they all use the same instrument systems. I would find it very hard to believe that a larger aircraft wouldn't have more shielding / protection than a simple Cessna with a phone that's just two feet away.

One more thought: Federal Aviation Regulation 121.306 states that no portable electronic devices are allowed except for: portable voice recorders, hearing aids, heart pacemakers, and electric shavers. How are the first and last any different from a phone in airplane mode?

<comment> a-priori _We can all agree that a four-seater Cessna and 767 are very different, but for nav/comm they all use the same instrument systems._

Unlike a Cessna, a 767 has a fly-by-wire system supported by a data bus (e.g. ARINC-429) running the length of the aircraft, often close to the passenger cabin. Presumably, GSM/CDMA signals could interfere with this.

<comment><USER23> I'll admit that I wasn't aware of this, but on the same token, would that portion of the electronics not be shielded as well?

<comment><USER24> The 767 was first built in 1981, long before everyone in the passenger cabin was emitting microwave-class RF radiation.

The plane itself serves as a very large shield to _outside_ radiation, but I'm guessing the internal wiring is not RF-shielded because of weight concerns. Wonder how much it costs to rewire a 30 year-old plane.

<comment><USER25> It cost $368 Million when the FAA forced operators to replace Mylar insulation (cause of at least two accidents):

[http://findarticles.com/p/articles/mi_m0UBT/is_10_19/ai_n129...](http://findarticles.com/p/articles/mi_m0UBT/is_10_19/ai_n12941245/)

According to this very interesting IEEE article, it costs anywhere from $1-5M per airplane, which doesn't include lost business cost:

[http://spectrum.ieee.org/aerospace/aviation/down-to-the- wire...](http://spectrum.ieee.org/aerospace/aviation/down-to-the-wire/0)

</comment></comment></comment></comment></comment><comment><USER26> Another reason I've heard argued by a coworker is that they aren't banning electronics for the sake of interference, but for your attention.

If anything were to go wrong during a flight, takeoff and landing are the two times that they want you to be able to react with zero hesitation. If something goes wrong and you have seconds to react, the less things you're fiddling with the more likely you are to survive.

<comment><USER21> That's not a compelling explanation, considering that you're free to keep your head in a John Grisham potboiler (as long as it's not a Kindle edition), or remain fully asleep at takeoff and/or landing.

<comment><USER27> Well actually I think it's better than jamming the newest (insert band here) album and not be able to hear much other than that and a very dim amount of engine noise.

I think it is safe to say it's likely a combination of many things - <USER2> coupled with statistics (as mentioned before, very small % failure rate + very large flight volume = enough dead people to warrant having them turned off) seems the most plausible.

Not to mention that someone linked that it could very well be a problem with the cellular networks - if (hypothetically) you could bugger up an entire major tower with enough "hop" volume, I can see why the FAA or other organization would just want to have this as a cover-our-ass precaution, too.

</comment></comment></comment><comment><USER28> Former avionics tech here. Not scientific, but I've seen CDMA devices interfere with nav equipment, and GSM devices interfere with communications system (ala the infamous dat-dit-dah GSM sound over speakers). And these on nuke-hardened (EMP-shielded) military systems.

These issues aren't going to crash the plane, however with the sheer variety of cellular devices, it's just a good idea to keep them off.

Besides, you people who can't seem to shut them off are an annoying lot, so there's also a co-passenger sanity aspect to it. Just leave them off, are you that addicted to Farmville?

<comment><AUTHOR> Not farmville but I enjoy reading on my phone, RSS feeds, kindle books, Instapaper. etc. Short flights espeically in the EU e.g. 1.5 hours to Amsterdam on the weekend in great time to catchup on reading. Missing the takeoff and landing cuts about 30 minutes of reading time.

It sounds selfish and there is enough evidence here that I am now happy to just turn my phone off, maybe I will just print off some of my Instapaper articles :)

<comment><USER5> There are offline RSS readers, Kindle apps and Instapaper saves can be exported to various formats.

<comment><AUTHOR> It is all offline, I only read in airplane mode on the phone, I use high contrast mode with medium brightness on the Instapaper app so don't think I really annoy everyone else, but you do get told to turn the phone off even if it is in airplane mode (thus no signal in our out) for takeoff and landing.

I just need to go to super offline mode and print stuff out!

<comment><USER29> You don't have to turn your phone off during the _entire_ takeoff and landing, just when the stewardesses come to check you.

Apparently that's the only dangerous part.

</comment></comment></comment></comment></comment><comment><USER25> Here is the reason straight from the FAA:

 _"There are still unknowns about the radio signals that portable electronic devices (PEDs) and cell phones give off. These signals, especially in large quantities and emitted over a long time, may unintentionally affect aircraft communications, navigation, flight control and electronic equipment."_

[http://www.faa.gov/news/fact_sheets/news_story.cfm?newsid=62...](http://www.faa.gov/news/fact_sheets/news_story.cfm?newsid=6275)

ie. We don't know, but we are playing it safe. While it is an inconvenience, I take comfort in knowing that the regulators are erring on the side of caution when it comes to air safety.

If they are so cautious with the slightest possibility of radio interference from a 3v device, then I can be assured that the remainder of the plane (ie. the thing that is flying at 800km/h at 30k feet with 200+ people inside it) has been checked over and is safe.

<comment><USER30> How hard could it be to get 500 phones, put them in a plane and dial them all ?

<comment><USER31> There are more than 500 _different kinds_ of phones.

That's the problem.

<comment><USER30> It's only a problem if the plane doesn't fail.

However, if it fails with those 500 then that's all you need to know to say "phones can down the plane". If you need more detail you can keep researching.

<comment><USER31> The plane doesn't fail, it's been done. There are too many variables. The biggest problem is older electronics and GSM.

</comment></comment></comment></comment></comment><comment><USER32> Mythbusters did a great show on this problem. Here's a link to the results of the show:

<http://mythbustersresults.com/episode49>

<comment><AUTHOR> Thanks for that I was really hoping that Mythbusters had tested it. "It was found that cell phone signals, specifically those in the 800-900 MHz range, did intefere with unshielded cockpit instrumentation. Because older aircraft with unshielded wiring can be affected, and because of the possible problems that may arise by having many airborne cell phones "seeing" multiple cell phone towers, the FCC (via enforcement through the FAA) still deems it best to err on the safe side and prohibit the use of cell phones while airborne."

So that is interesting, wonder if they suggested modern shielded planes. Also lends credence to ground interferance as the real reason for the "ban"

<comment><USER33> But that's the part I don't get; there's no "ban" at all! I can bring a bunch of phones on the plane and just not tell them about it. If they search my bags, they'll remove my 200ml of water citing "it's too dangerous" but they'll leave the cellphones alone.

That's not much of a "ban". So I still disagree that phones could interfere in any meaningful way with any aircraft's systems.

<comment><USER34> That is a foolish conclusion.

Firstly, if the TSA searches your bags and actually finds a "bunch" of cell phones, I bet that they will find an excuse to hassle you about it.

Secondly, your own example shows how shoddy this reasoning is; the TSA is not rational* about what they confiscate and what they don't -- your water isn't dangerous, and they took it, so why would you trust their judgment on cell phones?

Thirdly, the cell phone industry moves much faster than the airline security industry, so it's (vaguely, remotely) possible that some new phone released yesterday is dangerous, whereas old models aren't; the airlines wouldn't know the difference. One could say the same for almost all consumer electronics. So it would be hard to ban "bad" electronic devices and allow "OK" ones, and probably not worthwhile. Banning them all is an option, but just because it's a risk doesn't mean it's enough of a risk to be worth addressing.

*At least, they aren't rationally trying to prevent planes from being hijacked or interfered with; maybe they are doing a good job at other things, like making people feel warm fuzzies about security.

<comment><USER35> _it's (vaguely, remotely) possible that some new phone released yesterday is dangerous,_

That's no greater a possibility than for my netbook, or my wristwatch, for that matter. Why pick on phones over other electronics?

(I suppose the answer is to see your previous paragraph regarding rationality)

<comment><USER34> They don't pick on phones over other electronics. On every flight I've been on, they ask passengers to shut off "all portable electronic devices," including things that often don't even communicate over a network, like CD players.

</comment></comment></comment></comment></comment></comment><comment><USER36> Two things:

1\. Using a mobile phone isn't generally dangerous providing everything else on the plane works fine and nothing would be interfered with if it wasn't.

2\. Cell handovers at 30,000ft with an air speed around 500mph are really, really hard.

The reasons for turning your phone off during takeoff and landing are wide and varied, but the long and short of it is that it effectively counts as security theatre. Take off and landing are the two most dangerous bits of any flight. If anything goes wrong they do not want people tweeting "OMG IM GOING TO DIE!!!!", they want them focused on bracing for impact. That's not the only reason (or necessarily a major one) but you get the idea.

<comment><USER37> Since most phones are CDMA now I think the dangers of interference are much much lower. I have always suspected that carriers help promote this myth to reduce network overhead from point 2 above.

<comment><USER38> I'm fairly sure most phones are GSM.

[http://en.wikipedia.org/wiki/Comparison_of_mobile_phone_stan...](http://en.wikipedia.org/wiki/Comparison_of_mobile_phone_standards#Development_of_the_Market_Share_of_Mobile_Standards)

</comment></comment></comment><comment><USER39> I find it hard to believe that a plane's avionics are sufficiently shielded to withstand a direct lightning strike, but one person's phone will crash the plane.

I've heard other explanations, too, such as the fact that too many mobile towers are line-of-sight at the same time, and the effective ground speed means you'd hop towers far too often and it'd mess with the phone system. Multiplied times the number of mobile-phone-carrying passengers in the air at any given time, I suppose it's plausible.

<comment><AUTHOR> That last one is an interesting point, any references to whether it has been tested?

<comment><USER39> [http://www.breitbart.com/article.php?id=D8O9BCJ80&show_a...](http://www.breitbart.com/article.php?id=D8O9BCJ80&show_article=1)

FTA (emphasis added): "Existing rules require cellular phones to be turned off once an aircraft leaves the ground _in order to avoid interfering with cellular network systems on the ground_."

</comment></comment></comment><comment><USER20> Leave your phone near a CRT screen or loudspeaker, observe the noise right before you recieve a call.

The rest is statistics and probability. What's the probability of interference causing a fatal misreading in aircraft's sensor? Too small. What's the number of flights world wide? Too big. We would see a number of accidents if everyone kept their phones on all the time. As a death is one too many, it warrants the ban.

<comment><USER33> I disagree. The airlines claim the risk of death from my water bottle is too high to allow me to bring the water on the plane. Fine. However, I'm allowed to bring 100 cellphones in a backpack. They don't care about that, except to politely ask me to turn them off.

If there was a remote chance of a cellphone causing a crash - more chance than a bottle with water in it - then they would ban cellphones in flight.

It's very clear that there is no actual risk of interference at all.

<comment><USER20> The water bottle thing is not airlines' doing as far as I know. It's to do with your countries national security authority.

Emirates allows mobile phones on some of their flights.

<comment><USER40> > The water bottle thing is not airlines' doing as far as I know.

Neither is the cell phone thing in the US. It's both the FAA and FCC:

[http://www.faa.gov/news/fact_sheets/news_story.cfm?newsid=62...](http://www.faa.gov/news/fact_sheets/news_story.cfm?newsid=6275)

</comment></comment></comment></comment><comment><USER41> Go fly in a private plane and leave your cell phone on. I do not fly IFR so I haven't had to rely in my ILS but it does destroy radio communications. Have you ever heard your GSM based phone pulse and cause noise on a close by speaker? Imagine that being pumped into your radios and into your headphones. It is painful to hear. If I was landing when it went off, it could cause me to react badly at a time when I couldn't afford it. Also, I could miss a call that there is traffic around.

</comment><comment><USER42> Here's the part that I think about: ok I get that phones could potentially cause a problem. If that is the case, than we shouldnt be relying on voluntary compliance. Either it's not a problem--then let people do that they want, or it's a problem, and you better be telling me that you have a better risk mitigation than "hope that everyone turns off their phones".

</comment><comment><USER43> It has to do with FCC regulations. This is terribly handwavy, because I barely remember the explanation, but basically, they have to make sure that the plane isn't giving off certain signals and interfere with anything, and the easiest way to do that is just to tell everyone to switch their devices off.

Hopefully someone can clarify that a bit.

<comment><USER33> > they have to make sure

This is the problem, though. They _don't_ make sure! They politely ask you to turn your phone off. 50% of people comply, 50% don't. If they _actually had to_ stop the signals, they would ban all cellphones in the cabin. They could collect them, put them in a lead case with the luggage and move on.

But since they don't "make sure" of anything, I disagree with your explanation.

</comment></comment><comment><USER44> Do the cellphones even work in airplanes? I mean, they are pretty far from antennas, even over civilized area. They also move quite fast, although I do not really know how much Doppler effect affects the phones' transmitters and receivers. The plane is also a Faraday cage, thus it may greatly reduce signal.

<comment><USER45> GSM is designed to be usable when travelling in a car, but going much faster than that will likely cause problems. It's probably problematic that you're not staying long enough in a single cell tower's range, and doppler effects on the radio signals will also cause problems (if I remember correctly from my uni course on the subject).

</comment></comment><comment><USER46> As far as I'm concerned, reason #1 to ban cell phones on airplanes,

Who wants to listen to the person beside you talk through the flight on a cell phone. Your life can be on pause while you fly through the air.

</comment><comment><USER47> I've heard it summarized thusly:

The aircraft is most likely to hit something during takeoff and landing. Cell phones, laptops, and other hard, dense, chunks of metal plastic are, in fact, dangerous when they're flying toward your head.

It doesn't particularly matter whether they pose an electronic threat, policy would be the same.

<comment><AUTHOR> Wouldn't that just mean the policy should be put them away not turn them off?

</comment></comment><comment><USER48> I was thinking of this 2 days ago, when I decided to leave Runkeeper running in my pocket :)

</comment><comment><USER49> I don't want to encourage terrorism, but if someone wanted to destroy an airplane, they could bring onboard a more dangerous device disguised as a phone or other everyday 'black box' object such as a laptop. The dangerous device might emit serious levels of radiation, it might contain a powerful laser, it might contain explosives. The best defense against 'terrorism' is to be nice to other countries, help them and don't oppress them.

Usury (national debt), bombing, invasion and economic sanctions (aka starvation) are not nice. The countries and groups that commit crimes like those are likely to be attacked. Don't be bad, and no one will want to kill you.</comment>