Why software projects take longer than you think – a statistical model - <AUTHOR> https://erikbern.com/2019/04/15/why-software-projects-take-longer-than-you-think-a-statistical-model.html <comment><USER4> An important aspect of being a professional software engineer is having the backbone to sometimes say things like:

\- "I don't know yet enough about the problem to give you even a rough estimate. If you'd like, I can take a day to dig into it and then report back."

\- "This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chinese and Google Translate isn't good enough. I'd need to insist on professional translation in order to even estimate the second part."

\- "The problem is tracking down a bug rather than building something, so I don't have a good way of estimating this. However, I can timebox my investigation and if I've not found the cause at the end of the timebox, can work on a plan to work around the bug."

You need to be willing to endure the discomfort of looking someone in the face, saying "I don't know", and then standing your ground when they pruessure you to lie to them. They probably don't want you to lie, but there is a small chance that they pruessure you to. If you don't resist this pruessure, you can end up continually giving estimates that are 10x off-target, blowing past them as you lose credibility, and your running your brain ragged with sleep- deprivation against a problem you haven't given it the time to break down and understand.

But when you advocate clearly for your needs as a professional, people are generally reasonable.

<comment><USER5> > But when you advocate clearly for your needs as a professional, people are > generally reasonable.

This has not been my experience. People want 'estimates' at all costs, tell you to not worry about any accuracy, and then a week later tell your manager you committed to x date.

<comment><USER6> As long as software is a cost center to your company, it will be treated this way. Trying getting a job at a company where software is a core concern. Ideally with a CEO that is not from a marketing/business background.

<comment><USER4> For more on this sort if thing, Patrick McKenzie's writing is good:

\- [https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a- pr...](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

\- [https://www.kalzumeus.com/2014/04/09/what-heartbleed-can- tea...](https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the- oss-community-about-marketing/)

<comment><USER7> > In the real world, picking up a new language takes a few weeks of effort and > after 6 to 12 months nobody will ever notice you haven't been doing that one > for your entire career.

Spoken as someone who has never taken the time to fully master a programming language and, from the sound of it, has never worked with someone who has either. The difference between someone who has spent 6-12 months with a language compared someone who has spent 6-12 years is night and day. From the general tone of the article, he obviously focuses more on the business value than on the technical side and that is a pretty good approach for making money. But I'll take Peter Norvig's advice ([http://norvig.com/21-days.html](http://norvig.com/21-days.html)) over this guys when it comes to mastering a language.

To be fair most of the content of those articles is pretty decent though and it is just a pet peeve of mine when people claim that mastery of your medium doesn't matter.

<comment><USER5> In my experience, having mastery over one language translates more or less directly into being at least journeyman in all others.

If you are working with an apprentice, whatever you do, it will seem like you are really experienced.

</comment></comment></comment></comment></comment></comment><comment><USER8> I've been one place that I thought was _really_ good at software estimation. Their system was:

Everything gets a T-shirt size. Roughly, "small" is no more than a couple person-days, "medium" is no more than a couple person-weeks, "large" is no more than a couple person-months.

Anything beyond that, assume the schedule could be unbounded. Figure out how to carve those into a series of no-larger-than-large projects that have independent value. If they form a series of iterations, don't make any assumptions about whether you'll ever even get around to anything but the first one or two. That just compromises your ability to treat them as independent projects, and _that_ creates risk that you find yourself having to worry about sunk costs and writing down effort already expended when it eventually (and inevitably) turns out that you need to be shifting your attention in order to address some unforeseen business development.

At the start of every quarter, the team would commit to what it would get done during that quarter. There were some guidelines on how many small, medium or large projects they can take on, but the overriding principle was that you should under-promise and over-deliver. _Lots_ of slack (1/3 - 1/2) was left in everyone's schedule, in order to ensure ample time for all the small urgent things that inevitably pop up.

There was also a log of technical debt items. If the team finished all their commitments before the end of the quarter, their reward was time to knock things off that list. Best reward ever, IMO.

<comment><USER9> > Everything gets a T-shirt size. Roughly, "small" is no more than a couple > person-days, "medium" is no more than a couple person-weeks, "large" is no > more than a couple person-months.

That's pretty much exactly what I've ended up using on past projects - <USER2> little more fine grained (start at a half day, went up to months), but that was my approach as well, and if I didn't know everything it went up a size.

<comment><USER10> Did you find much differentiation between half day and couple of days? Especially because some things that might take a couple days end up taking 30 mins (some efficient package already exists), and some half day things end up taking a couple days, so it comes out in a wash?

<comment><USER8> The answer to that question depends heavily on the duration and nature of your planning iterations.

If you're doing quarterly planning, the difference between half a day and a couple a days is meaningless, and there's not really any point in distinguishing among them.

If you're doing 1-week sprints, the difference between half a day and a couple days is enormous, and the product planner might get some value out of distinguishing among them.

If you're following a more kanban-y approach, the difference is perhaps meaningful, but not particularly actionable, so I think I (personally) still wouldn't bother to capture the distinction for planning purposes.

</comment></comment></comment></comment><comment><USER11> According to Joel Spolsky¹, programmers are generally bad at estimating, but they are _consistently_ bad, with the exact factor depending on the individual. So by measuring each person's estimate and comparing it to the actual time takes after the fact, you can determine each person's estimation factor, and then when they estimate again, you can get a pretty reliable figure.

1\. [https://www.joelonsoftware.com/2007/10/26/evidence-based- sch...](https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/)

<comment><USER12> You know that article was written to sell a feature in their bug tracker. I like Joel's writing but I'd take that piece with a pinch of salt.

<comment><USER11> If we try to be a bit charitable, we could assume that they implemented the feature in the bug tracker _because_ of this observed property of estimates.

</comment></comment></comment><comment><USER13> US navy has developed something similar with beta statistical distribution. You estimate "Optimistic", "Most likely" and "Pessimistic" time estimates for each task in the project and then use beta distribution on it. Some tasks take way longer than estimated.

Here is the link to the time estimation described above with Beta distribution. [https://www.isixsigma.com/methodology/project- management/bet...](https://www.isixsigma.com/methodology/project- management/better-project-management-through-beta-distribution/)

<comment><USER14> I find this approach very interesting, but it hinges on the assumption that project completion times follow a beta distribution. What's the basis for that?

<comment><USER15> It may reflect the observations in OP kind of well -- with one difference: it assumes we're good at estimating the mode, not the median. But other than that, within the range we're talking about (1 < alpha < beta) it has somewhat similar shape to the lognormal distribution.

The three things that still bother me about that idea are:

1\. I haven't tried fitting it to the dataset in OP;

2\. It's bounded to the right, which seems unrealistic;

3\. I haven't come up with intuitive interpretations for the alpha and beta parameters in this context. If the beta distribution means something, then its parameters must have natural interpretations as well.

</comment></comment></comment><comment><USER16> As always, my favorite article on this subject: [https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning-f...](https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning- fallacy)

> _A clue to the underlying problem with the planning algorithm was uncovered > by Newby-Clark et al., who found that

Asking subjects for their predictions based on realistic "best guess" scenarios; and

Asking subjects for their hoped-for "best case" scenarios . . . . . . produced indistinguishable results._

> _So there is a fairly reliable way to fix the planning fallacy, if you're > doing something broadly similar to a reference class of previous projects. > Just ask how long similar projects have taken in the past, without > considering any of the special properties of this project. Better yet, ask > an experienced outsider how long similar projects have taken._

<comment><USER17> Daniel Kahnemann calls this the "inside view" and "outside view", from his book Thinking Fast and Slow.

The relevant excerpt (mostly an anecdote that serves as an introduction to a whole _chapter_ about it) can be found 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></comment><comment><USER18> The mythical man month ( required reading for most CS programs ) goes into a historical and production aspect of why software projects take longer than what you think and what you expected.

Also, there is a law named after author called the Brooks's law : "adding human resources to a late software project makes it later"

[https://en.wikipedia.org/wiki/Brooks's_law](https://en.wikipedia.org/wiki/Brooks's_law)

In most industries, if you are running behind schedule, you throw more workers at the problem to catch up. For example, laying railroad tracks, digging ditches, deliverying packages, harvesting crops, etc. By adding more workers, you shorten the time it takes to complete the project. But which software engineering, the reverse tends to happen. If you are falling behind, just throwing more developers at the problem worsens the problem. Most likely because you need the new developers to get "caught up" with the code/project/tools but if you rush that process, then they won't have a full understanding of the project/code/tools and introduce bugs/problems themselves which exacerbates the problem.

It's a fun read if you have the time.

<comment><USER19> Given most software project estimations are off, wonder if a corollary of Brook's law can be - don't add resources in later stages of 'any' software project.

<comment><USER20> Ah, but how do you know what stage of the software project you're in? Are you 3 months into a 4 month project or are you 3 months into a 5 year project?

<comment><USER19> Maybe, instead of asking - if I'm x months into a y months project (assuming y months is the initial estimate) - ask if the project is x% feature complete. Based on the remaining features identify how far the project has progressed. Though, this approach has the problem of scope creep. As the requirements are fluid, especially in a long-running project.

</comment></comment></comment></comment><comment><USER21> My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

<comment><USER22> Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.

<comment><USER23> > _then you aren 't learning from previous mistakes_

???

The doubling-it is for when you build the whole component on top of a library, then discover that the library has a fatal bug you can't work around, and you have to rebuild the whole component on top of a different library, then discover that other library has _another_ fatal bug, so now you need to include _both_ libraries with logic around when to use which one, and then that seems to work but you add plenty of tests and documentation to make sure it works that way in prod too and not just on your dev machine.

I don't see what that has to do with learning from previous mistakes. Pretty much all but the most basic programming turns out to be like that -- dealing with unforeseeable and undocumented problems.

(The 20% is because you weren't planning for sick days, an unforeseen emergency bugfix on another project, nobody remembered about the afternoon retreat next week, etc.)

<comment><USER24> Going through this now and boy is this true. Nothing like rewriting a 1k+ lib the day before a feature is supposed to be ready and then praying you didn't blow up some other lesser documented part of the code.

</comment></comment></comment></comment><comment><USER25> This is why I like 3 point estimation[1] - if you have optimistic, expected and pessimistic estimates for each task you can pull out which points are high risk. Using a single estimate can't give you that insight.

[1] [https://en.wikipedia.org/wiki/Three- point_estimation](https://en.wikipedia.org/wiki/Three-point_estimation)

<comment><USER26> manager: "thanks for the optimistic estimate!"

<comment><USER25> Sure, in the same way a bad manager will say "No, that's too high, I'm going to reduce your estimate" if you use a single number. Bad managers are a thing. Make sure you get a good one.

<comment><USER27> Yep. I still remember my first manager, who doubled every estimate I gave him. He was great.

<comment><USER25> Definitely a good manager, but Hofstadter's Law says that's still too low. :)

[https://en.wikipedia.org/wiki/Hofstadter%27s_law](https://en.wikipedia.org/wiki/Hofstadter%27s_law)

</comment></comment></comment></comment></comment><comment><USER28> One strategy for dealing with risk is to order your tasks so the highly variable ones come first. That way, as you progress through the project, you eliminate a lot of unpredictability, and it's smoother sailing toward the end.

However, as the tables in this article show so clearly, one task can dominate others. This serves as a great illustration of a perception problem the above strategy can create. Outside observers watch your progress and will probably evaluate it in terms of number of tasks completed.

You have (say) 10 tasks to complete, and from their point of view, all they know is a really long time has passed and you haven't even completed 1 of them! Since they are further removed from the situation than you are, they are almost guaranteed to not appreciate why the variable task is that way. They're likely to just think your team is performing badly.

So, maybe it's better to order tasks so that risky stuff is spread more evenly across the timeline of the project. It could create less confusion. Putting risk at the beginning is a strategy that requires a whole lot of trust and buy-in.

</comment><comment><USER29> The interesting thing is that by the central limit theorem, the mean of a mean is normally distributed. This is extremely helpful. Here's what I suggest you do:

Same size your stories to small values. Do 30 stories in a sprint and take the mean. Do 30 sprints and take the mean of the sprint. What you get is the mean amount of time to do a sprint of 30 stories. What's amazing is that this estimate will be normally distributed. You can measure the variance to get error bars.

Of course 900 stories to get good estimates ;-) However, imagine that your stories averaged 2 days each. Imagine as well that you have a team of 10 people. That means that you will finish a "sprint" of 30 stories in 6 days (on average). 30 sprints is 180 days -- the better part of a year, but you probably don't need a 95% confidence interval.

You will find that after a few sprints, you'll be able to predict the sprint length pretty well (or if you set your sprints to be a certain size, then you will predict the number of stories that will fit in it, with error bars).

The other cool thing is that by doing this, you will be able to see when stories are outliers. This is a highly undervalued ability IMHO. Once a story passes the mean plus the variance, you know you've got a problem. Probably time to replan. If you have a group of stories that are exceeding that time, then you may have a systemic estimation problem (often occurs when personnel change or some kind of pressure is being applied to the team). This kind of early warning system allows you to start trying to find potential problems.

This is really the secret behind "velocity" or "load factor" in XP. Now, does it work on a normal team? In my experience, it doesn't because groups of people are crap at calmly using statistics to help them. I've had teams where they were awesome at doing it, but that was the minority, unfortunately.

<comment><USER30> The central limit theorem is in the limit for the number of variables in the sum approaching infinity. In the finite world, the article explains how it's done. The article is saying, the sum of lognormals is not normal. You are saying: take enough of them and it is normal. The article is still more accurate than your reasoning for 30 stories. From the wikipedia entry for Central limit theorem " As an approximation for a finite number of observations, it provides a reasonable approximation only when close to the peak of the normal distribution; it requires a very large number of observations to stretch into the tails". To prduce a 95% confidence intervals, you have to upper-bound the tails. All methodologies that are based on sum of subtasks estimates are not evidence based. But we knew already sw methodologies are not evidence-based, did we?

<comment><USER31>
        You are saying: take enough of them and it is normal.

This doesn't completely undermine your point, but that isn't what they are saying, I think. I read it as saying by CLT that the estimates of the mean of those distributions is normal and centered on [the mean you are actually interested in]. Tails are perhaps somewhat a red herring here, because you don't really care about them unless you are specifically trying to evaluate worst-case-but-really-unlikely.

<comment><USER29> Yes, that is correct. It's been a very long time since I studied statistics, so I'm not sure if the variance of a mean has the same confidence interval as the mean. I suspect not. So you would indeed need to have a very large number of samples to get good error bars. It's a good point which I hadn't really considered. However it will never really get that far anyway because hopefully you'll intervene before the long tail hits you.

I think those really long tails are more of a problem when you are working with "features" that are much longer. If you have 1 day stories and you've been working on the story for a whole week, you know you have a massive problem. It's time to back up and see if there is a way to break it up, or to do it differently.

If you have a feature that is a month, by the time you get to 5 months, you have so much capital invested in the original plan that it's very hard (politically) to say, "Nope... this isn't working out. Let's try something else". Of course, it is very hard to get your organisation to plan to a 1 day level of granularity.

</comment></comment></comment></comment><comment><USER32> Even the language is not correct: We all call it "estimate", but stakeholders behave like it's a "commitment". Passage from uncertainty to certainty happens in the language, and all the responsibility is on the engineering team's shoulders.

<comment><USER28> Even if you choose the right words, people don't necessarily pay close attention. And if they want a commitment, they may assume that the numbers you give them are a commitment regardless of how you phrase it.

But even if they did listen closely to what you said, "estimate" is not even a great word. If your car is in a wreck, a body shop gives you an estimate to fix it, and they may treat that estimate as a commitment. It's pretty common practice that people are held to an estimate, or to not going over by a certain small percentage. Maybe we need a word like "forecast" or "prediction".

<comment><USER33> > Maybe we need a word like "forecast" or "prediction".

Scrum (The org behind that flavor of agile) actually changed the language used in their guide back in 2011 from developers making a "spring commitment" to making a "spring forecast" for exactly these reasons.

[https://www.scrum.org/resources/commitment-vs- forecast](https://www.scrum.org/resources/commitment-vs-forecast)

</comment></comment></comment><comment><USER34> > Instead, figure out which tasks have the highest uncertainty – those tasks > are basically going to dominate the mean time to completion.

From the _technical_ side of things, uncertainty can mean a few things here:

(A) I've never done this kind of task (or I don't remember or didn't write down how long this task took in the past)

(B) I don't know how to leverage my historic experience (e.g., implementing an XYZWidget in React and implementing the same widget in Vue or Elm for some reason take different amounts of time)

Considering (A)... _Rarely_ does a seasoned developer in the typical business situation encounter technical tasks that are fundamentally different than what has been encountered before. Even your bleeding-edge business idea using modern JS' \+ GraphQL' is still going to be built from the same _fundamental_ pieces as your 1999 CRUD app using SOAP and the estimates are going to be the same.

If you disagree with this you are in the (B) camp or you haven't done the work to track your estimates over time and see how ridiculously accurate estimates can be for an experienced practitioner. Even "soft tasks" like "design the widget" are estimable/repeatable.

This whole you-can't-estimate-software accuracy position is entirely a position of inexperience. And of course all bets are off there. You are talking about estimating _learning_ in this case, not _doing_. And the bets are especially off if you aren't modeling that these are two different activities: learning and doing.

<comment><USER4> > is entirely a position of inexperience

There are a lot of inexperienced software engineers and very little good guidance written for them. What is a new CS grad to do when asked for an estimate? How can a new grad learn to produce accurate estimates within 3 months?

<comment><USER34> A problem with our industry in this regard is that we don't understand the difference between _learning_ and _doing_.

A new grad entering industry is going to be doing _a lot_ more learning than doing -- or rather learning _while_ doing.

I know from experience that explicit _doing_ is highly predictable/estimate- able for the experienced software practitioner.

I have a suspicion that the _learning_ side would be predictable, too, if our industry could do a better job of articulating what the _practitioner_ skill set actually is -> then a pedagogy could develop and it could be said that learning X-Y-Z takes on average this long for a set of students. Etc.

But we as an industry do not seem to be near this level of clarity -- in large part because we don't even have the vocabulary to frame it this way... in terms of _learning_ vs _doing_...

Now what this means for the new CS grad is not the best story. You'll rather have to play the chaotic game a little bit, which includes a mess of things like doubling estimates and working weekends or what-have-you depending on the work culture you find yourself within.

That ^^ in the short term.

In the long term what you should do is practice on your own:

1) ALWAYS privately plan and estimate your tasks to the best of your ability-- on your own, you may not get benefit by exposing your "practice" to the higher-ups

1a) hint: your tasks should be as scoped/small as you can make them and they will look pretty simple, like this: "design widget X", "design API interface", "implement API interface", "test API interface", "implement widget Y", "learn how framework X lifecycle works" (yes! even learning tasks can be estimated!), and so on. The key is that you try to keep them under a day and ideally even smaller on the order of hours.

2) RECORD the time it takes and compare to your estimates. --> LEARN from this.

3) REPEAT

If you do this conscientiously you will find that your estimates improve dramatically over time and you'll be able to out-estimate your peers to their own wild confusion.

This skill set will pay off in your ability to deliver AND have weekends and hours with your family. Because you will be able to "see time" and protect yourself. You'll have protection and ammo even in the worst pressure-cooker environments because you will be able to say "No" with confidence. Or rather you will learn how to say "Yes" and what to say "Yes" to. (Ie. you will get really good at priority negotiation etc.) And you'll cultivate delivery trust with superiors and everyone will be happy.

The main reason you get these claims that "business just doesn't understand software" and "they put too much pressure on us" is because "business" side doesn't trust us. Once you get good at estimates and _delivering_ on them, that trust is restored and everyone can be made happy.

BUT -- and here's the rub -- it takes _time_ and conscientious _effort_ and variety of experience to reach this level of confidence. My advice: Ignore all the philistines who say it can't be done....because they'll just try to talk you out of the effort that they weren't or aren't willing to do themself.

</comment></comment></comment><comment><USER35> In the UK, bookmakers offer 'accumulator' bets, where a punter can select many outcomes, getting a big prize if 100% correct.

This takes advantage punters' failure to accurately multiply probability - <USER3> events with 80% probability have joint probability <11%.

Something similar happens with planning, where people fail to compound many possible delay sources accurately.

Dani Khaneman covered this in Thinking Fast and Slow, also showing that people overestimate their ability, thinking they will outperform a reference class of similar projects because they are more competent.

[https://en.m.wikipedia.org/wiki/Planning_fallacy](https://en.m.wikipedia.org/wiki/Planning_fallacy)

<comment><USER36> It doesn't take advantage in the way you say because you get paid along the same lines. If you bet an accumulator with 2 selections at evens, you get paid at 3/1\. (4.0 decimal odds) so that is "fair".

It's profitable for bookies because they have a house edge, and that edge is increased the more subsequent bets you make. The house has more edge with an accumulator than a single bet.

People like to do accumulators because it's more meaningful to win large amounts occassionally than more regularly win less meaningful amounts.

So it's a "trick" to simply increase gambling.

If you had to pick out 8 evens shots in sequence and intended to roll over your bet each time it would have the same effect / outcome, but starting with a pound by the last bet you're effectively placing a 128 quid bet on an evens money.

It's not that the player thinks that they have a better chance of winning than 1/256 it's that it effectively forces them to gamble a lot larger amount in the situations where only 7 out of 8 of their picks come in.

And that's before considering the edge. If we consider that these are probably events that happen more like only 45% of the time (at best) then instead of a 255/1 shot we're looking at 600/1 shot.

</comment></comment><comment><USER37> One big factor that I don't THINK the article touches on is how we are using 'space' metaphors (speed and distance) for our work that's very 'time' based (working productivity and duration). And I think when we estimate, we try to estimate distance/duration but we forget that we're really trying to estimate our speed/productivity.

Where that gets painful is, say you estimate you can get something done in two days. In reality, you're twice as fast (there's that speed metaphor), so you actually get it done in one day. Yay, you saved a day! Now assume you're twice as slow as your two day estimate. Boo, you spent TWO days longer. So in terms of duration, getting it incorrect in the painful direction seems like a bigger mistake.

I don't think this is the same phenomenon as the author's mean vs. median dilemma. I'll bet both the mean vs. median and the productivity vs. duration dilemmas are real factors though.

</comment><comment><USER38> Pet theory: this is entirely explained by unknown systems not behaving as expected. As developers, and unlike e.g. carpenters, we are constantly using new tools with effects we haven't yet experienced. Then we have to yak-shave to get around their heretofore unknown kinks. Then the time blows up.

If and when you're using known features of a known framework, and that's _all_ you're doing, the estimates are accurate and the work is completed quickly.

<comment><USER14> I disagree. Estimations tend to be just as wrong even when the tools are well known.

There's always that one edge case you haven't considered, that one algorithm that doesn't work as well as you expected, that small change to the requirements the requires a completely different approach.

<comment><USER38> "Just as" wrong? I don't know what to point to to resolve disagreement here since it's just anecdotal, but if you're just using the same feature you've used hundreds of times before, there is nowhere near the potential for yak- shaving snags.

<comment><USER14> Okay, sure. Not "just as" wrong since a certain class of pitfalls are eliminated by deep knowledge of your tools.

But I'd argue that that's not where the bulk of the uncertainty comes from. I think that in the software industry as a whole, most of the problems are solved by people with at least a decent understanding of their tools, and estimates still suck.

The problems is that the tasks we deal with are always new, unsolved problems. That's the nature of software. Unsolved problems come with uncertainty. That's the nature of unsolved problems.

Carpenters on the other hand deal mostly with solved problems. They just need to execute.

</comment></comment></comment></comment><comment><USER39> Here is a story about the woes of interpreting statistical distributions:

I have two habits when I estimate: First, I like to give a range or even better a triple estimate of "optimistic", "expected", "worst case". (And btw, you should expect things to weight toward the pessimistic side, because you always find new requirements/problems, but you rarely discover a supposed requirement is not really one.)

Second: I like to break down a project into tasks of just a few hours and then add everything up. I usually don't share that spreadsheet with the customer, but it helps me a lot. Pretty much always it gives me a number higher than I'd like, but which is almost always very accurate. A couple times I've ignored the result and given a lower estimate because I really wanted some project, and it has always turned out the spreadsheet was right.

Well, one time I combined these two approaches, so that my very finely-chopped estimates all had best/expected/worst values, _and_ I shared that with the customer. Of course they took one look at the worst-case total and said, "How can a little thing like this possibly take 2 years??" I didn't get the work. :-)

EDIT: Btw it feels like there is a "coastline paradox" here, where the more finely you estimate, the higher the max possible, so that you can make your estimate grow without bound as long as you keep splitting items into greater detail. It'd be interesting to see the math for that.

<comment><USER39> EDIT2: In spite of my personal experience I do think the author makes a strong case for this: "Adding up task estimates is a really misleading picture of how long something will take." Perhaps I've had better results because I try to give myself a little padding in every task, just considering that everything requires not just typing code but getting on some calls, having back-and-forth in emails and the project management tool, testing (automated or manual), fixing a thing or two, etc. So my individual estimates are probably a bit higher than median. When I work with other developers they consistently estimate lower than me. But my numbers are deliberately not "best case", because then you _know_ you'll go over on the total.

</comment></comment><comment><USER40> The why is typically:

1) The person(s) doing the estimate aren't qualified to do so.

2) There is a disconnect between wishful thinking and reality.

3) There is some arbitrary future milestone (i.e., "We need to ship by ____ because ____ is happening the following week.") that is independent of software development.

4) Most importantly, when the deadline is missed the estimate / estimators are not questioned, the software team is.

I've been at this a long time - too long? - and the narrative that IT is __always__ at fault is a myth that needs to be buried.

</comment><comment><USER41> I'm sorry to contribute to the dogpile effect (long thread probably says same thing I'm about to say, but I didn't see it..), _but_..

devs estimate known risks. Ideal path + predictable delays. The further reaches of the long tail are the unknown risks.

known risks are estimated based on knowledge (hence, a question for a dev), unknown risks are just an adjustment parameter on top of that estimate, possibly based on historical evidence (there is no reason a dev could estimate any better).

It should be managements job to adjust a dev estimate. Let's be real here - I've never heard a real life example of management using stats for this kind of thing, or being enthusiastic about devs doing the same.

Perhaps if management is taken seriously as a science, things will change, but I doubt it.

<strong_opinion type="enterprise_software_methodology_cynicism">

Bizness is all about koolaid-methodology-guru management right now, very much the bad old ways - a cutting example of workable analytical management would be needed for things to change, but this is unlikely as all the stats people are getting high pay cool ML jobs, and aren't likely to want to rub shoulders with kool-aider middle managers for middle-management pay..

</strong_opinion>

</comment><comment><USER42> In my experience software takes longer to build than original estimates because no one will get out of the way of the development team and let them work.

This is an extreme example, but one I now live in daily.

My current full-time-ish gig is working on a pretty enterprisy system for law enforcement. To this date there hasn't been a single feature request, or bug fix that took more than 16 hours of development time. And so I know that I can typically finish something within a few hours to a day of receiving the task. UNLESS my manager wants to discuss ad nauseam what he means when he says "intersect an array". Or get stuck in 2 day long code reviews where my manager makes me sit behind him while he goes over every single line of code that changed, then gets side tracked and starts checking emails, chat messages, text messages, calling other developers in to check on their statuses, and even watching youtube... while I'm stuck in his office waiting on my code review to be done so I can go back to my 5th day of trying to complete a task that would have taken only a couple of uninterrupted hours. /rant

And this is why I pay $120 a week for therapy.

<comment><USER43> Sorry but why would a manager even do a code review?

<comment><USER42> He was originally hired as the sole developer 10 years ago, but the project grew too big, and instead of hiring a manager to oversee the project and hire more devs, they moved him into a management position, and put him in charge of hiring new developers.

</comment></comment></comment><comment><USER44> I used to work for a software company that did projects for clients and charged by the hour (a consultancy) and we frequently had to estimate projects with incomplete information in order to event get the contract in the first place, so they often turned into the actual final budget. Since I was the head of engineering I ended up doing a lot of sales and estimation for new projects. Besides just doing it a lot and gaining experience from many projects, there were a few other things that really helped me:

1) Software Estimation: Demystifying the Black Art by Steve McConnell (already mentioned by others).

2) His short video on "Targets vs. Estimates" was super helpful - we watched it with engineering, sales, and project management all together and had a good discussion afterwards. [https://www.youtube.com/watch?v=FY9X21HA02w](https://www.youtube.com/watch?v=FY9X21HA02w)

3) Keeping a running list of "Things to Remember". Every time a project went astray or we encountered something during a project that I had failed to estimate (but potentially could have) it went on the list. That was useful to share with other too, when they did estimates.

I really like the discussion of standing up to those who ask for estimates. A clear understanding of what an estimate is and what it's for is important, as is a strong sense of professionalism. I would recommend "The Clean Coder" by Robert Martin for this. It's more about professional behavior than software practices. Especially his chapters on "Saying No" and "Saying Yes". I read it and discussed it with my team often. It helped us realize when we had to refuse to give an estimate because we lacked the necessary information to do so, rather than just guess or make something up.

</comment><comment><USER45> In the world of small medium projects often the major issue is that software engineers give estimates for writing the software but customers take that to mean time to actual delivery in production and a lot of the time have no idea how big a task deployment and integration are...or don't even have a plan for that.

<comment><USER46> in medical devices it usually takes five times as long to really finish the project vs. finishing development.

</comment></comment><comment><USER47> To me, software projects take longer than i think because customers don't know what they actually need until there's a runnable version of what they want.

</comment><comment><USER48> Honestly, after doing this whole data science thing for a while now, I'm going to be blunt: I can estimate quite a lot of tasks with quite a lot of accuracy. including software and IT tasks.

What I can't do is make bad management hear what they don't want to hear. Nor can I stop people from accepting an estimate because its closer to what they want to be true, because they've already made a promise that conflicts with the actual estimate, or because a certain process requires or necessitates inaccurate estimates.

I think the whole "software is hard to estimate" myth stems from 2 fundamental causes:

\- not controlling for human biases or referencing actual real world data \- processes that don't punish/ reward people who provide inaccurate/accurate estimates respectively.

</comment><comment><USER49> Vistimo.com, the tool I built and use when I run estimates for my clients, uses log-normals and monte-carlo simulation to conquer this exact problem.

Really exciting to see other people beginning to recognize and use the same statistical tools -- they've served me really well.

</comment><comment><USER50> I once had a really convoluted metaphor for estimation which involved opening boxes that sometimes contained other boxes which sometimes contained other boxes... I wonder how that models mathematically.

<comment><USER51> The problem with this analogy is that the boxes do not obey the laws of physics and fit inside eachother...

<comment><USER50> Did I mention that they were magic boxes?

</comment></comment></comment><comment><USER52> Wouldn't it be more sensible to give a range instead of a fixed date? I know it's not going to happen, but I think it would be more informative and honest.

That way you could communicate better of how certain you are. There's a difference between telling something will be completed in, for example, 6 month +- 2 weeks. Or something will be finished in 6 months +- 1.5 months. The estimated time is the same but communicates the level of certainty more clearly.

Or just use between, for example, 4-6 months if you don't want to use +- notation.

<comment><USER53> In my experience, developers understand and appreciate range-based estimates. But when those numbers start moving up the communication chain, some non- developer is going to either not like or not understand the point of the range, and will convert it to a single number: either the first one, the last one, or the average. They might even be honest about it, thinking "I need to know the earliest possible date, so I'll use the low end". But then the next person, who doesn't see the range, thinks that low end is THE committed date and will plan accordingly. Now your deadline is 99% likely to be missed.

</comment></comment><comment><USER54> I'm blown away on a regular basis by how long it takes to write software that in my opinion is super easy.

Usually it just comes down to fuzzy/missing/changing requirements. A lot of times people know that they want something, but they don't know exactly what. Or they're absolutely sure they need feature x, but then later they realize they don't, but they missed out on developing other more fundamental features.

<comment><USER28> I have developed a belief about this: people don't know what they want until you show them what they said they want. Then it's immediately obvious to them what they wanted instead.

This suggests that demos and mock-ups might be a valuable tool. The sooner you can get someone to try something, the sooner they can tell you what direction they really wanted you to go in instead, and the less time you waste.

<comment><USER55> They want everything but they can't even define a starting point. It's insanity. I've been going back and forth with a customer about this (through my product and sales team) since August of last year. At first the priority was high and it seemed like the scope was reasonable. But no one was making moves or delivering on my requests / asks / concerns. I suggested a phased approach, so that we could _be_ agile and get _something_ in front of the customer for feedback. But before I even got there the requirements changed again and again and again and again and again...

Thankfully all of this specific work is easy to segregate away from the rest of my team. It's proven to be very toxic and morale draining. If my entire team was involved, I've no doubt that we'd have lost people by now.

And the real kicker: It turns out that right now we can't even deliver on the first pass that I had originally suggested, despite me being basically done with my teams piece, because some other team in the company was loose with their language and convinced a bunch of product and sales folks that, yes, of course they had what the customer was asking for. They didn't. They still don't. I'm convinced today that they never will. Bunch of fucking sycophants.

I have no idea how these things happen but recently I've become convinced that this sort of confusion-on-all-fronts is just par for the course in this industry today. The only work that I've been able to do in the past couple of years that was well understood and easy to articulate, and as a result capable of being completed mostly on time and within scope, was born out of a select few individuals being able to identify a real problem and a real solution and grinding away at it in a controlled fashion. But that seems to be rare and not at all "how things are done."

</comment></comment></comment><comment><USER56> I've always thought that typically overoptimistic estimates tend to be more based on the mode. I.e. 'this is the sort of task that normally takes 1 day, so I'll estimate 1 day'. The high point on the probability curve is the most noticeable, but it's also way further to the left than either the mean or the median.

I have no data to back that up though.

</comment><comment><USER57> I've been coding professionally for 20 years and I'm largely no better at estimating completion than day 1, maybe worse since I'm more likely to feign confidence in a figure I've essentially pulled out of my ass.

At some point, I came to the realization that my fundamentally poor concept of time was always going to be an insurmountable obstacle to my career advancement.

</comment><comment><USER58> My empirically-confirmed heuristic is that the time to deliver a feature set that someone would actually want to use is 2.5x-3x of the time I think of when asked for an off-the-cuff estimate.

Basically, multiply initial estimate by a number between e and pi -- no joke! It's a bit of a problem given that PM's think they're being generous with a 20% pad.

<comment><USER19> I can relate to your heuristic. The current project I've been working on is close to completion and somewhere between 2.5-3x of its initial estimate.

</comment></comment><comment><USER14> My theory on why software estimates suck is tied to Rosenberg's Law:

> Software is easy to make, except when you want it to do something new. The > corollary is, The only software that's worth making is software that does > something new.

It's hard to estimate the difficulty of something you've never done. And the nature of software development is to always do new things.

</comment><comment><USER59> I believe this is the reason why scrum uses story points instead of time estimate. By putting uncertainty on the same level as effort, you give it more weight. And using a fibonacci sequence rather than a continuous amount with the rule you should round up if unsure tend to correct those defects.

<comment><USER60> there is an uncharitable response to this thread, which is marked dead. I do think there is a kernel of truth in that response, which is nothing more than mocking.

why fibonacci? I think it's reasonable to say time includes an exponential error. an estimated 1 hour task is very different than an estimated 1 week task. i see that 1 hour, 1 day and 1 week estimates are progressively, and likely exponentially, worse.

Is it just the ease of doing the math? (totally reasonable answer, in my humble opinion). or is there something specific about fibonacci that's actually relevant? I think it's the former not the latter. but if you have any evidence to the contrary, i'd love to hear it.

<comment><USER61> The kernel of truth of that response is that you won't get more certainty about an estimate by adding more uncertainty, no matter in how much pseudo- scientific cargo-culting mumbo-jumbo you cloak it. (Unfortunately, HN readers don't really like sarcastic commentary which requires reader to think it through. Time is precious, and we just want to be coddled, give me your opinion ELI8 straight, because there is no time to think!)

<comment><USER60> I think you're half right. adding an error band to a far out estimate won't give you a better estimate, but it might help tell you how much you _don't know_ about what you're facing.

Cumulative error is _hard_. see weather prediction.

</comment></comment></comment></comment><comment><USER62> One take away is for sprint planning - if there is a reasonable amount of uncertainty on a task, take it out, either break it down or do some investigation, and bring it back next time. You don't want a σ=2 task messing up your sprint!

</comment><comment><USER63> The assumption in the article is the amount of work is a constant. Instead what happens is that a manager has decided how much time it should take (always too little). If you accept that time, then you will go over.

If you push for more time and get it, then the manager will eventually add more scope and you will go over.

The vast majority of the time we see projects go over deadlines because scope was added under the guise of clarifying scope.

Starting with a business value actually works pretty well to enable people to control scope.

We also use actual velocity on tasks to re-forecast daily. That has been the most effective way to get a good date. Over a large number of tasks this works very well.

</comment><comment><USER64> I always think of project tasks as flow charts, where every item either takes 1 day, or 1 week. There's no way of really knowing in advance. Complications happen.

It makes it really hard to calculate the "expected value" of 5-10 tasks.

<comment><USER65> The more tasks you have to do, the _more_ certain about duration you should be - some of the uncertainty will cancel out and you will get a gaussian distribution. For your example, I expect 10 tasks of between 1 day and 1 week each (with flat probability) to take about 6 weeks in total, with a 95% chance of completion within 7 weeks.

</comment></comment><comment><USER66> Well, I think this is a complex topic. Not because of the math, but because the key to an accurate estimate is to understand who has done the estimate and on what basis.

As stated in the summary, the core driver for inaccurate estimates is _uncertainty_ :

> Tasks with the most uncertainty (rather the biggest size) can often dominate > the mean time it takes to complete all tasks.

There are different sources of certainty:

\- Experience: If someone has done a task 20 times he probably knows how much time he will require. Someone who hasn't done the task yet, probably underestimate the time he requires (e.g. because of the median vs. mean conflict). But don't be fooled just because you have 20 years of work experience in the field but never actually done a specific task doesn't mean you can estimate it better than someone who just started the job but had done that specific task 10 times. However, most of the time, projects are doing something new. So you have to find out which tasks have been done before by a project member and which are completely new ground. If something is completely new, remember to plan time for getting familiar with a problem space plus a handful of complications (together this will be more than the actual task would take someone who is trained for that specific task).

\- Detail: The smaller the tasks the larger the overall estimate... or so. Planning on a top-level is rarely going to be accurate. We do it a lot because it doesn't take much time. But _if_ you want an accurate estimate, you have to plan on small, specific tasks.

\- Risk management: Every project has risks. Some don't really have an impact and others blow up the whole project. Know your risks and what you are going to do if something should go in the wrong direction. It is not like you wouldn't have time to figure out what to do when the problem occurs but to understand how it would impact your timing and to take preventive actions (e.g. include stakeholders).

If you have people who have done the exact same task a few times, made a detailed plan of every step and know how to handle the most likely or impactful risks you are in a good position to deliver on time. Most of the time you won't have that luxury and have to compensate the resulting uncertainty with a prolonged time to project completion, but that should be just fine when being communicated in the beginning.

With all that said, remember, that some projects don't require an accurate estimate. _Sometimes_ it is enough to deliver just as soon as possible.

<comment><USER67> On the experience part, this happened to me few times, when the project manager asked me for an estimation, i give it from my perspective and experience, and then he gives the work to someone else with no experience, and obviously takes more than estimated.

Now, i always give two estimates: An estimation if the work is done by me, and an estimation if the work is done by someone else.

</comment></comment><comment><USER68> How about making the manager estimate the project, that way if the deadline is not met, the manager receives the blame? It's the manager's job to manage resources, and if the deadline is not hit, then they can hire/bring on more resources. If an engineer works as hard as they can for 40 hours a week, why is it the engineer's fault if the arbitrary deadline is not met? If the engineer estimate's time for a project, the engineer will always have to work more than 40 hours a week because some estimates will be too optimistic.

<comment><USER69> The manager does receive the blame, and then stuff rolls downhill.

</comment></comment><comment><USER70> Something I've been trying is estimating for the time in which I'm 80% sure I can finish something. I end up racing ahead of estimates most of the time because they are too high, but then some times I'll find something that is a bit more complicated than expected and it takes a little longer. Overall this seems to balance out, but also have a lot more predictability, it's easier to predict at any given time what I might be working on. This has been pretty important on my team where I've been doing API work for some iOS developers to use.

</comment><comment><USER71> Yes, this is a thesis I've brought up quite some times in relation to sprint planning. The odd misjudgment having a strong influence on the total estimate biases upwards, not downwards.

</comment><comment><USER72> What I want to know is why the software developer is expected to give estimates. Estimating how long common tasks take seems like something I would expect a software manager to be able to do effectively and care about. If you're just a monkey who is asking everyone to do the planning and estimation job for you, I'm frankly unsure why the company allows you to collect a paycheck.

</comment><comment><USER73> I think the most important issue why projects take longer is not because the time it takes to complete a task is uncertain, but because at the start it will always be unknown which tasks will prove critical. The further you get, the more tasks will reveal itself that were not part of the original scope, but critical nonetheless.

</comment><comment><USER74> They don't take longer than I think. The problem is nobody listens! True story - They handed me an RFP, asked for an estimate. I gave it and they cut it in half and got the job. I didn't take any pleasure in being right, but I was right. It was an expensive mistake.

</comment><comment><USER75> 1\. Do the tasks with, as far as you can tell, the most uncertainty as soon as possible in the process.

2\. This is why "agile" tries to avoid estimating more than a few weeks. The more tasks you have in there, the more you estimate is likely to be really off.

</comment><comment><USER76> _Fits symmetric function to clearly asymmetric distribution_

Author: Decent fit, in my opinion!

This bad fit makes me genuinely sad (;∩;)

<comment><USER69> He could probably tweak a skew normal distribution to make it fit nicely, but it's _pretty_ close to normal.

</comment></comment><comment><USER77> There would be great to have predictions that use ML to estimate how long something will take.

<comment><USER31> If you are thinking this as opposed to statistical modelling, what is the benefit you imagine?

</comment></comment><comment><USER78> It takes longer than we think because writing software is solving a math problem, and you can't know how long solving a math problem will take until after you solve it. [http://www.warhound.org/kcsest.pdf](http://www.warhound.org/kcsest.pdf)

</comment><comment><USER79> Eh don't worry, self driving cars are coming this year, Elon said so.

</comment><comment><USER80> I've been in a company where all estimates were multipied by pi.

</comment><comment><USER81> Because they can't take negative time.

</comment><comment><USER82> I'd also add that _the reason why the mean will be larger than the median_ is usually hard to discern for any specific situation.

This foments bikeshedding debates that are a mix of business pressure to favor uninformed estimates and disagreements about which possible sources of surprises or hitting a wall are most likely.

As soon as you mix this with a formal estimation system like Agile (yes, even the platonic ideal 'agile' too), it creates a snowball effect of time wasting because overhead is so frequently required to resolve debates and placate business pressures for estimates.

</comment><comment><USER83> TLDR anyone?

<comment><USER84> Thesis: Developers are good at estimating median time to finish tasks. But the tasks that take longer, in fact take much, much longer than estimated.

E.g. Dev estimates that time to complete each of A, B, C tasks will be 2 days. In reality, A will take 1 day, B will take 2 days, but C will take 8 days.

Dev was right about the median time to complete each task (2 days) but average was much higher. Article goes into how to statistically model the distribution of actual time to complete tasks.

<comment><USER4> That was a really concise but faithful summary. Welcome to HN.</comment></comment></comment>


When the Millionaires Are Fleeing, Maybe You Should, Too - <AUTHOR> https://www.nytimes.com/2018/06/02/opinion/sunday/millionaires-fleeing-migration.html <comment><USER2> tl;dr rich people are a good barometer of a country's economy, so you should probably dump/short the Turkish Lira.</comment>


In UK, Two Convicted of Refusing To Decrypt Data - <AUTHOR> http://it.slashdot.org/story/09/08/11/2340221/In-UK-Two-Convicted-of-Refusing-To-Decrypt-Data?from=rss <comment><USER2> TCHunt is a free program that finds (for the most part) TrueCrypt volumes. (Modulo 512, chi-square stream analysis, etc). The scary thing is that it's not 100% positive as it cannot differentiate between random data and AES data, but in general testing, it finds 100% of TrueCrypt files. I wonder if something such as TCHunt could be used to accuse someone of having an encrypted TrueCrypt file or not? I doubt it, but some folks argue otherwise.

</comment><comment><USER3> No problem.

1) Encrypt sensitive data by the method of your choice, and store it in a filesystem X.

2) Generate a plain text filesystem Y full of disinformation, the same size as X.

3) When the key to decrypt X is demanded, compute Z = (X xor Y), and provide Z to the police on a DVD with instructions to the forensic cryptologist that it's a one-time pad.

<comment><USER4> The beauty of the one-time pad is that one can not tell the "random" key from the payload. Clever.

</comment></comment><comment><USER5> It's interesting to see the responses on /. compared to here.

The thing is were fogetting (or they're forgetting) is that this is, what, 2 people prosecuted out of 11 refusals over the course of 1 year. That's maybe 0.001% ( _this is a typo - I meant 0.01%, see below_ ) of all the encrypted material investigated in a year (very rough figures, I only have a tiny portion of the data: it could be lower still).

I dont think it's "panties in a twist" material yet :)

<comment><USER6> So we shouldn't worry because the secret police don't have the manpower to prosecute "that many" of us yet?

Seriously?

<comment><USER5> well that only works if this was the most they COULD prosecute. Im fairly sure in a year a few hundred wouldnt be too much difficulty (considering the sheer number of computer related prosecutions anyway).

Anyway my main point was that the other 99.99% you generally dont need the access keys for: either there is sufficient evidence elsewhere, or not enough data/evidence to warrant a (uh) warrant [this one being the main factor] or you can break throuhg the encryption in some way.

Secret Police?

</comment></comment></comment><comment><USER7> They should have used a Truecrypt random partition in which case it cannot be proved that they have encrypted anything at all.

<comment><USER8> What are you considering "provable?" You know, a judge and prosecutor don't get involved because of suspicion that you have encrypted data that might be useful for solving a crime, there are usually a long string of events and circumstances that brings you to that point. The actual encryption keys are just a formality by that point.

Whether or not you can plausibly deny the existence of encrypted data in a convincing manner probably isn't going to be that important. Everyone draws a line somewhere and that might be the stand you wish to take, I suspect you'll end up in jail regardless though.

<comment> a-priori Exactly. Any time someone suggests fancy crypto as a solution to a legal problem, it reminds me of this XKCD comic: <http://xkcd.com/538/>

Except replace "Drug him and hit him with this $5 wrench..." with "Charge him with contempt and throw him in jail...".</comment></comment></comment>


New NanoTech May Provide Power Storage in Cables, Clothes - <AUTHOR> http://today.ucf.edu/new-nanotech-may-provide-power-storage-cables-clothes/ <comment><USER2> The biggest concern I have with this is that, should it ever become viable, many energy storage devices have a failure mode where they release all their stored energy very quickly in a rather exciting way.

</comment><comment><USER3> Ok, so a new approach for making nanostructured supercaps, great. So what's the energy density they saw? Breakdown voltage? What's the whisker manufacturing process?

There's lots of work on devices like this, and this article doesn't answer any of the points that you need to see where this tech stands relative to its competitors. The nature article is better, as well as the actual paper:

[http://www.nature.com/nature/journal/v509/n7502/full/509568a...](http://www.nature.com/nature/journal/v509/n7502/full/509568a.html)

[http://onlinelibrary.wiley.com/doi/10.1002/adma.201400440/pd...](http://onlinelibrary.wiley.com/doi/10.1002/adma.201400440/pdf) (Paywall?)

TLDR: Whiskers grow by heat-treatment - seems pretty scalable to me.

0.55 mWh cm^−3 and 413 mW cm^−3 energy and power densities. LiPos hit 300 mWh cm^-3, for reference, so it's pretty pointless to put this in clothing. Power density is decent, as it's a super cap. It might be interesting to consider electrical grids built with the stuff, but for the moment it looks like the only real applications are for so called "dual-use" applications where you're putting in a boatload of cable anyway. PV solar farms perhaps? IDK if even that's enough to be worthwhile.

</comment><comment><USER4> Growing whiskers on copper wires to use as capacitors is a very interesting idea. A few thoughts:

(1) Is avoiding shorts in the insulating dielectric difficult? It seems like you'd need a very thin dielectric if you want benefits from the whiskers/nanowires, but a very thin layer could be hard from a reliability or voltage breakdown perspective.

(2) If you wanted to use these for power lines, would the capacitance be an issue? I remember from my electrical engineering classes that the transmission line propagation is strongly affected by the balance between capacitance and inductance. Would you need much higher current to voltage ratios? [http://en.wikipedia.org/wiki/Transmission_line](http://en.wikipedia.org/wiki/Transmission_line)

(3) Even if this was built into power lines, I don't know if the capacitance boost would be very useful in terms of storing energy or smoothing out solar/wind power generation. You can only store power if you're willing to let your voltage vary significantly.

</comment><comment><USER5> Am I the only one bothered by the repeated use of "storing powerful energy"?

</comment><comment><USER6> Yes, this sounds great. I would love to literally be clothed in a powerful supercapacitor. What could go wrong.</comment>


Show HN: Summer Pledge – you have 72 days until the end of summer - <AUTHOR> https://alt-romes.github.io/summerpledge/ <comment><USER2> I have 72 days till the start of summer. Irregardless, the season doesn't affect my bandwidth for side projects as I'm not a student.

</comment><comment><USER3> I pledged and am close to finishing my project. This site may not get traction, but I think its pretty cool to remind yourself that being done is a very important step to success. "Great Artists Ship"

Hopefully in a week I'll have the finishing touches on my project and then can share it with everyone (here and on the pledge site).</comment>


Huge Trove of Leaked Russian Documents Is Published by Transparency Advocates - <AUTHOR> https://www.nytimes.com/2019/01/25/world/europe/russian-documents-leaked-ddosecrets.html <comment><USER2> Interesting to learn about the DDoS group posting it. Distributed Denial of Secrets. It's like they're positioning themselves as some sort of WikiLeaks competitor.

</comment><comment><USER3> Not being published on WikiLeaks for some reason.

<comment><USER4> For the most part Wikileaks seems to avoid posting negative info about Russia, or against Russian interests.

<comment><USER5> Do you have some examples? I mean of data that was given to wikileaks and not posted?

<comment><USER6> Just one rather recent example: [https://foreignpolicy.com/2017/08/17/wikileaks-turned- down-l...](https://foreignpolicy.com/2017/08/17/wikileaks-turned-down-leaks- on-russian-government-during-u-s-presidential-campaign/)

Assange also claimed to possess incriminating documents on several Russian oligarchs and Government corruption since about 2009-2010, before he got his show on RT.

<comment><USER6> Found a link regarding the Russia leaks announced in 2010: [http://content.time.com/time/world/article/0,8599,2028283,00...](http://content.time.com/time/world/article/0,8599,2028283,00.html)</comment></comment></comment></comment></comment>


No Google+, No Single Sign-on? - <AUTHOR>

Just noticed if you try to delete your Google+ content, it says, among other things:<p>- You won't be able to use the "Sign in with Google" button to log in to third-party apps. <comment><USER2> It is all pretty unified at this point, yes. I guess I hadn't fully realized that, but that doesn't surprise me at all.</comment>


ROC-RK3328-CC: A Raspberry Pi Competitor with Gigabit Ethernet, USB3, DDR4 - <AUTHOR> https://www.phoronix.com/scan.php?page=article&item=libre-computer-renegade&num=1 <comment><USER2> Can you just make a more powerful Raspberry Pi and succeed? The Pi probably benefits so much from economies of scale, it would be hard to approach the price/performance, leading people to settle for the less-powerful but probably capable-enough Pi.</comment>


Ask HN: How do I save stories on HN? - <AUTHOR> I'm relatively new here and was looking for a way to "bookmark"/save stories that have been submitted by others here at HN. Under my profile I see a "Saved Stories" link but I don't see a way to save the submitted stories on any of the submitted stories or any place else. I checked the HN FAQ and I don't see it explained there.<p>Is this feature available only to reputed users? <comment><USER2> Also, consider a tool like [https://getpocket.com/](https://getpocket.com/) — i use it across all my devices. Love it. If you are into tagging I would suggest you will too.

</comment><comment><USER3> Stories you upvote are saved.

<comment><AUTHOR> Thank you. Didn't realize that's what it meant.

Maybe the page that gets displayed when I click on the "Saved Stories" link on my profile, should include a note saying upvoting is the way to save stories.

<comment><AUTHOR> I just noticed that the link has now been renamed to "upvoted stories". Thanks to whoever did that!</comment></comment></comment>


Goodbye, Ctrl-S - <AUTHOR> https://medium.com/@jeffjarvis/8f424e463dbe

<comment><AUTHOR> Working in traditional document-driven software with a good autosave implementation is like using v2.5 of a really bad source control system.

In v1, before autosave, the system only kept one commit, but you could choose when to do it.

V2 let you commit when you want but also committed for you automatically, which is nice, but hopefully you don't want to revert changes.

V2.5 is like v2 except that it keeps a few of the older commits. The usefulness of this feature is almost completely eliminated by the fact that the _software_ decides which commits to keep, not the user.

When you think about it that way, it's insane to think that it's the normal mode of operation. The technology and concepts to fix it already exist; the only reason we don't have anything better is because no one has figured out the right user experience.</comment>


Get push notifications from different mail services - Our-Last-Night

Life has necessitated three different mailboxes from three different services (Yahoo, Gmail, Hotmail). I got a nexus 5 recently. After I installed the app for each service my phone's battery won't last longer than 3-4 hours. The problem is that all of these apps are constantly synchronizing with their own servers. Has anyone found a solution to this problem? Is there a way to get notifications from all of the services all at once? <comment><AUTHOR> I found this crazy myMail.my.com app. Looks like it can do everything you need it to. The design is just unbelievable, although they're already in line with the boring Android app guidelines.</comment>


Free Schnail Mail for life - <AUTHOR> http://aralbalkan.com/notes/schnail-mail-free-real-mail-for-life/ <comment><USER4> This argument is really vacuous and makes an inappropriate analogy.

First, we need to distinguish between attaching ads to _the mail experience_ versus injecting them into the _actual content_. In the original post, this service would actually open these letters and insert ads into them. This is not even remotely comparable to what most email providers do. They insert ads around the service, but never actually alter the content of the email. A better analogy would be receiving a discount on branded stamps or allowing advertisements to be displayed on your mailbox.

Second, the use of the term "read" when discussing advertising is asinine, disingenuous and probably detrimental to the conversation (inasmuch as it can provoke unnecessary fear in non-technical users). "Read" implies active evaluation and comprehension, conceivably by a person. The GMail algorithm does not "read" email in the classical sense. It systematically evaluates the content in a way isn't even remotely comparable to "reading." (This doesn't mean that this sort of advertising isn't bad, but portraying it in the way he did is just unnecessary fear mongering.)

Third, the OP seems to decry "keeping a copy" as some sort of violation. GMail is a webmail service. What the fuck are they supposed to do if not store your mail?

Fourth, this service actually seems like a good idea, and is probably something I would use for various types of mail. The price of mail been steadily increasing, and I would be fine with these practices if I knew they were saving me money. I'm willing to tolerate advertising so long as I know that the service is improving my life. Like I do with 95% of the things I use.

In conclusion, this is a very dubious analogy that doesn't really contribute to the pragmatic discussion of cost versus privacy.

<comment><USER5> > This is not even remotely comparable to what most email providers do. They > insert ads around the service, but never actually alter the content of the > email

[http://news.cnet.com/8301-1023_3-57594819-93/google- starts-p...](http://news.cnet.com/8301-1023_3-57594819-93/google-starts- placing-ads-directly-in-gmail-inboxes/)

<comment><USER6> And how is this related to "altering the content of the email"?

</comment></comment></comment><comment><USER7> I don't know why this still surprises people, or why Google is being singled out here. Information is transmitted by copying. Every provider has to look at and analyze your messages if they want to do clever things to them, like let you search your archived mail server-side. Even if they don't do anything with your messages themselves, they're still compelled by the government to parse through it all. Nothing is safe.

Whenever anyone asks me to explain how the Internet works, I don't talk about tubes or connected servers, because thinking your message is "in" a pipe is a broken abstraction; it makes people imagine nothing sees or touches your messages until they arrive at the destination. Instead, the mental model I encourage people to have for Internet is that "each packet is like a message stuck to a big public message board." Privacy is not the default; it's a public system, and privacy is something you have to actively create on top of it (via encryption, onion-routing, etc.)

<comment><USER8> Once again, this is a fundamental mistake especially techies seem to make when it comes to privacy.

Privacy isn't about what is and what isn't publicly accessible, it's about _what you do with that information_.

It's a violation of privacy for any company to follow me around in a public space and record my movements.

It's a violation of privacy for a company to use the data _I 've given them_ for any other purpose than the reason for which I gave it to them, because it is still _my data_.

This is why collecting and collating wifi ssid's by Google was considered a violation of privacy. Yes, the data was out there, but the _abuse_ of that data was a violation.

Privacy is not a technological system. Privacy is not about security.

People should be able to use the internet without automatically getting their privacy violated, just like they should be able to go out in public without having their privacy violated. The fact that it is an open system is absolutely no excuse for deliberate privacy violations.

Stop blaming the victims.

<comment><USER9> >People should be able to use the internet without automatically getting their privacy violated, just like they should be able to go out in public without having their privacy violated.

You do realize that that's exactly wrong. Going out into public means that you risk being followed. Being followed becomes illegal when they follow you into your home (a private space) or when they actually hurt you/have hurt you.

</comment></comment></comment><comment><USER10> In my opinion, this kind of argument is demagoguery and ignores practical security concerns.

For the average person, which is more likely?

(1) A hacker taking over their email account to get bank info, etc.

(2) Some nebulous threat from Google having too much information about you.

Google and Gmail offer some of the best security controls and threat detection of any webmail provider that I've seen (pioneered two-factor authentication for email, warn you about strange sign-in activity on your account, allow you to kill other sessions, etc.).

If the outcome of this kind of article is people move to less secure email because of some intangible threat, I think it's a net harm. Gmail is still the best choice for my mom.

I wrote about this more than a year ago at greater length on my blog: [http://www.maxmasnick.com/2012/02/12/gmail_paranoia/](http://www.maxmasnick.com/2012/02/12/gmail_paranoia/) and there's more discussion on HN at [https://news.ycombinator.com/item?id=3582609](https://news.ycombinator.com/item?id=3582609)

My point is that any post criticizing Gmail for it's business model should also consider what is realistically a problem in the actual world (hacking) and hopefully offer some advice on what to do about it. I'm not sure this kind of "Google reads all your email and it's terrible. Full stop." post is very helpful.

Ok, a couple more things to preempt the inevitable trolling:

(1) Government snooping is a separate issue, but as far as I know there are no major email providers that a non-technical person can use that aren't vulnerable. We sorely need easy-to-use, widely used email encryption. Google isn't likely to do this because it would be counter to their business model, and this _is_ a problem.

(2) I don't use Gmail myself, but not because they are algorithmically reading my email. I switched (to FastMail) because I don't like the design direction of the Gmail UX, the FastMail UX is substantially faster, and the support is better (i.e. it exists). However, given that the average webmail user (a) doesn't want to pay for email and (b) is going to use one of the most popular services by default, I still think Gmail is a good choice.

<comment><USER11> > Government snooping is a separate issue, but as far as I know there are no > major email providers that a non-technical person can use that aren't > vulnerable.

But at least, those other email providers are different that your web search provider - while if you use Gmail, your profile will also contain your searches (if you use Google for search), visits from those searches, and then also data from other Google services you choose to use.

<comment><USER10> If you're talking about government snooping, they most likely can aggregate information from different sources.

If you're talking about the nebulous "one company has all my information and may do something evil" argument, I still say that it doesn't matter. Email is by far the most sensitive thing most people do online, so if there was a real threat from a company having all that information, also having searches is not substantially worse.

Regardless, I still don't see a credible threat of harm from Google having this information that outweighs the actual threat of hacking.

</comment></comment></comment><comment><USER12> Machine "reading" the email != humans reading the same thing

A machine can't laugh at your embarrassing confession. Nor can a machine talk about your letter to its friends.

For either of these things to happen with gmail would require serious risk and effort on part of an employee.

<comment><USER13> It doesn't matter, the information is there. He mentions building a profile. While the machines might have built it, there's nothing stopping a real person (forced or otherwise) from browsing those profiles.

<comment><USER14> "The information is there" on all e-mail providers. There is nothing (short of end-to-end encryption) stopping a real person _at any e-mail provider_ from looking at your email.

The interesting distinction (for me, and I have been a happy GMail "customer" for close to a decade soon) isn't the profile, it's the human. I have strong faith that Google can be successful in keeping humans from reading my e-mail (or a computer-generated digest of it, which is what the profile amounts to), and so I don't worry about the existence of the profile.

<comment><USER13> Not always. Several new security-oriented email providers boast diskless email servers and end-to-end encryption.

<comment><USER14> Yes, end-to-end encryption would fix all this, but it would also fix it in OP's satirical mail service, as well as in GMail - so that's really a tangential point.

Trusting that those providers don't start siphoning off a copy of your mail (or are indeed diskless and not out of malice or incompetence actually just using regular disks. Also, being diskless is worthless if they are still keeping your mail around in memory anyway) is no different than trusting Google to keep humans away from my email.

</comment></comment></comment></comment></comment><comment><USER15> So... Can I still get the free snail mail for life? I don't have a twitter account, and I'm not going to register one just to get free snail mail for life...

I hope that you can afford the postage, as I intend to embark on a mega mass mail campaign for a few dozen different customers, and the thought of free postage is quite enticing...

/s

</comment><comment><USER16> What if Schnail Mail automatically filtered postal junk mail so you never had to receive another piece again?

What if it let you search the contents of every printed message you'd ever sent or received?

What if it let you send international mail, with attachments, for free?

What if it protected you and more susceptible friends and family from postal scams?

What if it informed you that your recipient no longer existed at the address you used?

What if it let you undo sending of mail you regret writing?

...

A free postal mail service that truly replicated Gmail's functionality would probably appeal to many, even with inserted ('relevant') ads and all the privacy issues.

Paid versions of such a service already exist (e.g. [https://www.earthclassmail.com/](https://www.earthclassmail.com/) ). A free equivalent could be pretty disruptive.

<comment><USER17> Most of these features are available even if you don't use Gmail though - <USER2> article's point wasn't about e-mail in general, just the invasiveness of Gmail.

<comment><USER16> My point was that people who use Gmail get more than a free mail service in return for their privacy.

The things that Gmail does best – search, spam filtering, scam warnings, simple attachments, innovative labs features like undo send – weren't offered by Schnail Mail, which invited you to trade your privacy for free postal mail alone.

Trading privacy for free mail alone _would_ have little appeal to most. But Gmail offers more than that. A feature-matched physical mail equivalent to Gmail would make an ad-supported postal mail service far more compelling.

I suspect you'd also see more hands stay raised if you flipped the pitch to place the negatives up front ahead of a long list of potential benefits.

</comment></comment></comment><comment><USER18> This is just a re-hash of Microsoft's Scroogled campaign ([http://www.scroogled.com](http://www.scroogled.com)). Just as with scroogled, the comparison of a human reading your mail with a machine analysing the contents in order to provide focussed advertising results in a complete loss of credibility.

<comment><USER19> Why does putting a human in the loop change anything? Either way, my data is being used on behalf of other people.

<comment><USER20> Because machines don't care what you do, or who you are. Humans potentially do. They can gossip about you, they can read, and understand, all your private emails and use that information against you.

<comment><USER19> Humans are slow. Gmail's computers are programmed to wring the most possible profit out of millions and millions of accounts. Seriously, I'm convinced the humans would do less damage.

<comment><USER6> I'm convinced of the opposite: humans judge basing on incomplete and incorrect data, they are often malicious and selfish and blinded by personal gain.

Computers don't have prejudices, don't have a motive, and work on the specific task without being sidetracked by feelings.

<comment><USER19> Computers follow instructions of the programmers. If the programmer is good, the computer has the same prejudices. Specifically, if the programmer wants to find juicy gossip, a computer lets her do it faster. If the programmer respects users' privacy, so will the computer. (If she's not good, the computer has _random_ prejudices. [https://en.wikipedia.org/wiki/Hacker_koan#Uncarved_block](https://en.wikipedia.org/wiki/Hacker_koan#Uncarved_block))

<comment><USER6> I partly disagree for the following reasons:

1) If the programmer is good the computer COULD show prejudices. It's not an implication. I can be a racist bigot, but if I'm a good programmer I will not prevent login for the users 晴輝, Abd al-Aziz or 湘. I can build a watermill and it will not have prejudice, it will just do a job.

2) The programs running in such big companies are peer reviewed, so the inner workings are known and checked by at least two people. You cannot do that to human beings. You don't know what they are ultimately trying to do AND you cannot have at least two people checking on them. If now you're thinking of parents, remember that they have a limited influence on a person.

3) Random prejudice could still work, just like random noise, but I still disagree on the prejudice part.

<comment><USER21> > I can be a racist bigot, but if I'm a good programmer I will not prevent > login for the users 晴輝, Abd al-Aziz or 湘.

However, if you were a programmer with a very insular mindset, you could create a system without support for such non English names, by not even considering that non English users would use the service. Just an example of a prejudice that could show though.

<comment><USER6> True, but by definition a good programmer should take non English names into account. ;-)

It is more an example of random prejudice introduced by a programmer. In that case I retract some of my points.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> The problem with email is that we've arrived at a monoculture. TLS-enabled email is pretty secure if nobody can compromise either of the two ends (or, well, the intermediaries). Since everyone uses Gmail, it's trivial to just get everyone's email, since one of the two ends is pretty much guaranteed to be there.

If we move to a system where everyone has their own mail server, or at least one mail server for a few people, that system will be much harder to snoop on.

<comment><USER23> If a system evolved where a significant proportion of communications were difficult for the security services to monitor, encryption would be criminalized and it's users vilified as unpatriotic.

<comment><USER24> Great. Let's cross that bridge when we come to it.

</comment></comment></comment><comment><USER25> The analogy is a bit leaky IMHO. Gmail doesn't add advertisements to the mails you are sending out. They only add ads to the messages you received and are looking at in your browser. If you don't want to see any ads, just use an IMAP client and you'll get the original message.

In-fact, not altering the mails their users are sending was one of the unique features when gmail launched. AFAIR both Hotmail and Yahoo were altering the messages of their users to include ads.

The part about reading the mail is true though, but on the other hand: Unless you host your own email server, it is absolutely impossible to be sure that nobody is going to read your mail as it is stored on the mailbox server (it also can (and is as we now know) be read in transit most of the time and outside of your control).

As such, I honestly trust Google more than I trust $ISP. Usually $ISP is equal to $CARRIER and those, IMHO, are the personified evil, so I wouldn't trust them at all. But even $ISP != $CARRIER, I still think that the bigger the mail provider company, the safer your messages probably are there (minus government spying, but that works regardless of ISP): Bigger providers are bigger targets and thus have likely invested more in data security and internal procedures to make sure mail isn't being read by humans unless strictly needed.

If you don't want ads in your Google-served email while using the web interface, get a paid Google Apps Account. No ads, very flexible email routing and actual customer support. For $50 per year per user. That doesn't say anything about the data being used for other marketing purposes of course, but, as I said, that problem is the same everywhere unless you self-host (which is reasonably complicated and annoying to do).

TBH when I was running a free email service in the early 2000s I really had to fight the temptation to just run grep over /var/mail and have some fun. I think the smaller the company (it was just me and my colleague back then), the bigger the risk that one unethical person can do serious damage.

</comment><comment><USER11> The article is a bit demagogic, because saying "we open your letters" is not the same thing as "Google algorithm reads your email."

I don't defend Google here, and I also stopped using Gmail, but not for the reasons mentioned in the article. Storing the emails and mechanically parsing them wouldn't be a problem for me, if they could ensure that those emails will not leak out of Google - but that is not technically nor legally possible (at least nowadays).

</comment><comment><USER26> I didn't realize this was satire until I saw the Google logo, and I thought it was an awesome idea. "Oh, just like Gmail, but they're really open and honest about it."

I guess the reason Google and the like have to conceal their intentions is because there seem to be few people (three out of an audience in the example) who are willing to go into it knowing the terms (or admit to be willing). A lot more people are happy with signing up for the service not stopping to consider why a corporations would be so charitable, then finding out and joining the outrage bandwagon [while continuing to use the service].

This pattern seems insincere or dishonest (for the most part, always exceptions, etc), and I'm hoping it's a fad that dies out, as opposed to the value proposition getting bashed to death. Every other week there's a great tutorial on how to switch to duck duck go and roll your own everything, those are the honest sincere solutions for the truly interested.

<comment><USER27> Why would that pattern disappear? It makes money... What I would like to disappear is naivety of people. They should understands what they actually are doing. They don't need to understands the technology, just that free doesn't exist. Personally I don't care, it's a small price to pay to get a good spam protection, a good security and a good interface accessible everywhere.

<comment><USER26> To clarify, I meant the pattern of acting outraged while continuing to use the accused service. We're on the same page.

</comment></comment></comment><comment><USER28> This is a far better mockery/attack on Google's strategy than Microsoft's Scroogle campaign ever was. They should learn from this. I especially loved the cute & funny one-liners.

(Not that I support Scroogle, it's a cheap shot. I hate negative marketing. It's setting a bad example in tech, which has mostly kept the negative marketing away.)

</comment><comment><USER29> I like the way this has been presented, but have to admit that I disagree with the point - if someone's willing to give me something for free (monetary) in exchange for reading info I pass through their services I'm fine with that - <USER3> just won't use their service to send anything I don't want them to read. There are good arguments for privacy, and for people/organisations being open about how they use any personal data they collect, but in this scenario you've willingly and knowingly signed up to a contract; and in doing so invalidated your right to be upset by the required "payment method" of information.

</comment><comment><USER30> What happens if I put a sealed envelope inside the schnail mail envelope? Is that opened too?

</comment><comment><USER31> Anyone who has ever Googled their name and hometown must realize how much information is being sold about us. Google is just presenting the top layer, but this problem is a very old one. For better or worse, I think we have to get used to a post-privacy society. If it forces us to be more tolerant of each other's imperfections (because our own are shared with the world) all the better.

</comment><comment> FELICIA-JOY Knowing in advance that the intent is to read my mail feels icky and invasive. Google did not start out reading our mail; their approach was a classic case of the slow-boiled toad ([http://en.wikipedia.org/wiki/Boiling_frog](http://en.wikipedia.org/wiki/Boiling_frog)).

Perhaps you should gain users confidence and trust first by NOT reading their mail and giving them an opportunity to become reliant on the service. At less than 0.50 per piece, postal mail is not so expensive that it weights a risk/benefit analysis in your favor with this model. Most people would probably opt to just continue paying for their mail versus having it read. (Also, not sure people want to create bad friend karma -- ha! -- by having their friends spammed with "junk" mail.)

Moving from critiquing to finding a more viable option: I think you can still make money with this upfront by "skinning" the mail with fully printed ad envelopes (obviously with windows for the addresses to show) paid for by general consumer advertisers who don't have as much of a need for making sure they are hitting a niche group.

Once, and if, you gain a critical mass of users then you could introduce the "read" option with some kind of incentive to get people to opt-in. At least they will trust you more by that time, theoretically. And you could then sign up more advertisers including niche marketers.

The current model is not palatable -- unless it were used by a small business/entrepreneur that is sending marketing mail and therefore does not care if it is read (but that then poses a problem of them potentially having a competitor's materials inserted with their materials). If the model remains as is I would have to say #schnailmailfail.

-Felicia Joy @feliciajoy

</comment><comment><USER32> I was disappointed that it isn't real. This would have been a great way to keep in touch with prisoners, whose mail is being read anyways. It would have been nice to type letters without needing to print them out and mail it, and "free" sealed the deal.

</comment><comment><USER33> This is the guy that did an expenses paid tech talk where one of the big sponsors is heavily involved in the gambling industry, and then proceeded to publicly bitch out another speaker for doing a talk on technical hurdles of some kind of sports betting platform because betting companies are evil. Can't really have any less respect for someones opinion or thoughts when they are so ill-mannered and hypocritical.

</comment><comment><USER34> Seems like it could be argued both the gag, Schnail Mail, and the real gmail are fairly upfront in the relationship with the user. Advertising is present. Obviously, some technical differences but it IS disclosed!

</comment><comment><USER35> Is this kind of like - [http://www.promotinglinux.com/truth/](http://www.promotinglinux.com/truth/) (just for fun)

Or is this supposed to be a sarcastic poke at gmail, the NSA, etc?

</comment><comment><USER36> Funny, but for extra laughs they should add a section on PRISM: We keep scanned copies of all your snail mail indefinitely, which the NSA can access through our PRISM backdoor on a moments notice. ;)

<comment><USER37> I don't think they would be allowed to acknowledge that.

</comment></comment><comment><USER38> Google could offer a $20/month no-ads no-tracking email service. How many privacy conscious people are willing to pay that? Its not Google deciding to do this, its just ourselves.

<comment><USER39> Google does offer a $5/month no-ads email service called Google Apps.

According to their homepage, 5 million businesses have chosen that.

[http://www.google.com/enterprise/apps/business/](http://www.google.com/enterprise/apps/business/)

No tracking is trickier, who would believe Google (or any business) if they claimed they didn't track their customers? The lack of ads you can verify for yourself.

<comment><USER40> No ads is already free. Just you IMPAP or POP3. You are still tracked, but there are no ads.

</comment></comment></comment><comment><USER6> [http://www.bonkersworld.net/google-reads-your- email/](http://www.bonkersworld.net/google-reads-your-email/)?

</comment><comment><USER41> Give me Adblock for Reality and I might think about it.

[http://chromeadblock.com/freedom/](http://chromeadblock.com/freedom/)

</comment><comment><USER42> Took me a couple moments to figure out this was a joke.

</comment><comment><USER43> Disrupting postal services industry! Liked the idea. Except its name starting with 'sch' :/

</comment><comment><USER44> wonderful explanation</comment>


Survey Finds Foreign Students Aren't Applying to American Colleges - <AUTHOR> http://www.nbcnews.com/nightly-news/survey-finds-foreign-students-aren-t-applying-american-colleges-n738411?cid=sm_npd_nn_tw_ma <comment><USER2> Looks like it's this same survey[1], which was already reported a while ago in the NYTimes[2], and when you actually look at it, contains this phrase, which adds a little more perspective:

> 39% of responding institutions reported a decline in international > applications, 35% reported an increase, and 26% reported no change in > applicant numbers.

Note that it also says the "final" report will be released March 30, so expect to see this story reported again after that.

[1] [http://www.aacrao.org/docs/default- source/TrendTopic/Immigra...](http://www.aacrao.org/docs/default- source/TrendTopic/Immigration/intl-survey-results-released.pdf)

[2] [https://www.nytimes.com/2017/03/16/us/international- students...](https://www.nytimes.com/2017/03/16/us/international-students-us- colleges-trump.html)

<comment><USER3> I would be very interested to know what the overall change is as a whole.

</comment></comment><comment><USER4> Why should I enroll in a US college? I mean, I get probably the best education as an engineer for free, not counting that the scope and orientation of an american bachelors degree is more like german abitur than a bachelors degree here.

To clarify: Most countrys have cheaper high education. That's probably the thing you should fix First.</comment>