New ventures should focus all their efforts on problem-solving - <AUTHOR> https://review.chicagobooth.edu/entrepreneurship/2019/article/startups-forget-about-technology <comment><USER2> I find it interesting that the two example companies of Uber and AirBnB that succeeded by "focusing" solving problems, did so breaking the law and pushing externalities onto others. AirBnB runs afoul of the hotel laws and makes the neighbors of AirBnb hosts have to deal with the problems while also decreasing supply of housing and pushing up housing prices in cities and communities. Uber basically was an illegal taxi service and succeeded by paying their workers often times less than minimum wage by classifying them as contractors. They also took shortcuts on their self-driving cars and killed a pedestrian. They have also tried to suppress rape victims stories going so far as to invade their medical records.

To succeed as a business, you have to do something that others can't do or won't do. If you have a tech advantage, you can do stuff that others can't. If you don't develop a tech advantage, you have to do stuff others won't. In these two cases of AirBnB and Uber, it was breaking the law.

<comment><USER3> You left out "be first" which is an advantage that is much harder to find these days, which creates even more pressure to differentiate by other means, legal or otherwise.

<comment><USER4> VRBO was loooong before AirBnB. AirBnB reduced friction by handing the payments and provided social mechanisms for buyers and sellers to vet each other, among other things. In the days before AirBnB I remember booking an apartment in Paris by sending half the payment by wire transfer and the other half in cash on arrival. The apartment was great and the host even better, but the payment was painful, and something very few of my friends and family would have done. AirBnB made it as easy as booking a hotel, and that made a huge difference.

<comment><USER3> AirBnb is the canonical example. They weren't first, so they built a business around doing something that in most places is illegal, and it caught on in a big way.

I'm not discounting their UX, I'm sure it was a big part of their growth.

</comment></comment></comment></comment><comment><USER5> I've worked for so many companies with a really shitty tech stack. Most of the time they just threw as much mediocre devs at it until it worked. Mind you I was often one of them!

Most of their business people weren't too good either in terms of leading a company or such things, working at those companies was horrible!

The only thing they were good at was finding people with problems.

It seems to me the only thing that matters.

If you find enough people bothered by something, the will throw money at it like no tomorrow. You can't imagine how much money makes up for bad tech and shitty leadership.

But somehow this is the hardest part for me. Solving problems is one thing, but finding problems worth solving is another discipline.

<comment><USER6> It's actually pretty hard for developers to find problems worth solving at startup scale. Your average developer doesn't encounter the kinds of problems non-tech people will pay money to solve very often. Developers are also often likely to look at a problem and come up with their own "simple" solution that non-tech people wouldn't even think of.

Dropbox is a good example here - developers were largely perfectly happy with rsync for a decade, but your run of the mill mom wanting to keep her Word documents synced at home and the office doesn't even know what Linux is, let alone how to run a terminal.

If you want to find non-b2b problems that are worth solving _and which people will pay you to solve_ you generally have to step out of the tech bubble, talk to non-tech people at length, and imagine a solution that your mom could use.

<comment><USER7> Far and away my most common experiences with business ideas others try to give me:

"Oh man you should make an app/website to do X! God it'd make my life/job so much easier."

"Cool, yeah, great idea"

Then I unlock my phone, check the app store, and yep, there are already 25 complete solutions to this exact problem on just this one platform. Oh but they would totally pay for it and it'll definitely make me rich, never mind they haven't even bothered to google for a solution, which already exists in exactly the same form I'd make it, and is free or cheap. Ok. Toss that one in the ol' round-file.

<comment><USER8> Here it only depends on whether its a zero-sum (winner takes all) market, or whether you can improve an existing model and eat chunk of it (look how many alternatives of Mailchimp spun out, I love all of the incl. mailerlite and EmailOctopus!). So I wouldn't through the towel just because there is competition, but rather look at the opportunity cost, do you really wanna spend time working on this?

<comment><USER7> What throws me is that they seem to think this would make their life much easier, and that there's no solution unless someone makes it... but there already is one. There are several. Specifically for their problem. Most of which seem to get the job done just fine. It'd be a big help to them, but they haven't even spent as much time as it took to describe to me what they want, looking for an existing solution. I'd bet they've never even asked anyone else in their line of work if they have a solution. Anyone who has, doesn't have the problem anymore. They don't need me to write an app, they need me to teach them how & when to effing _google_.

I'm aware of the ability to out-compete existing solutions on quality and UX and such, but most of the time when this happens, there aren't really any clear pain points in the existing solutions that I'm being told about, the person suggesting it is just totally oblivious to their existence, and they sure appear to do _exactly_ the thing they need.

I do like the affiliate link suggestion from the other poster, haha.

</comment></comment></comment></comment></comment><comment><USER9> Entrepreneurs, forget about going to Chicago Booth for an MBA if you want to be an entrepreneur. You should be solving problems and learning business development and management by doing. These people have nothing special to teach you but will put you $175,000 in student loan debt. Instead, take loans from friends and family or find angel investors to raise funds that will pay developers to build your mvp. Don't outsource to an offshore development center in Bangalore. Use technology that won't just validate your idea but will help you achieve your goals.

<comment><USER10> You can use your MBA to get hired onto promising startups sloshing around with billions of dollars of Saudi royalty money, though.

</comment></comment><comment><USER11> On the other hand, Google, Microsoft, and Apple started with technology right?

It doesn't contradict the point of focusing on problem-solving, it just contradicts the click-baity title

<comment><USER12> From the original paper published by Sergey and Page..

 _In this paper, we present Google, a prototype of a large-scale search engine which makes heavy use of the structure present in hypertext. Google is designed to crawl and index the Web efficiently and produce much more satisfying search results than existing systems._ [http://infolab.stanford.edu/~backrub/google.html](http://infolab.stanford.edu/~backrub/google.html)

They were solving a problem - a very common problem in the days when internet content exploded.

<comment><USER13> But they didn't directly make money from solving that problem.

<comment><USER14> But they solved a problem, gaining a massive userbase, and only then became a great company because they were able to make money alongside the problem they were solving.

</comment></comment></comment></comment><comment><USER10> >They develop technology that they think will solve a problem, rather than first identifying and understanding the problem and then thinking creatively about how to solve it.

Can you hear the creaking sound as cryptocurrency startups shift uneasily in their chairs?

</comment><comment><USER15> Of course solving a problem is the central tenet of a startup. Technology is an excellent tool to find problems to solve, though.

"Forgetting the technology" is dumb. Advances in technology enable novel ways of tackling existing problems. Keeping an eye on technology advances, and raising the question "Which problems can now be solved in better ways?" is an excellent starting point to find problems to center your company on.

<comment><USER16> People often state advice in rather extreme terms, then are surprised when people interpret them in a way that matches the meaning of their words. This seems like one instance of that.

</comment></comment><comment><USER17> Most successful businesses in the U.S. are not technology companies at all, they just solve problems in creative ways. Look at someone like Wayne Huizenga who started AutoNation, Blockbuster, and Waste Management. That is like if Computer/Math prodigy Reed Hastings started a couple billion dollar companies in the Auto and Waste industry alongside Netflix.

The point being that great entrepreneurs can repeatedly find problems to solve and create value from.

For example, the author of this article was a successful entrepreneur in his own right. "Previously, the Chief Executive Officer of The Tie Bar - the #1 e-commerce destination for stylish men's accessories. Prior to The Tie Bar, Alter was a co-founder and President/CEO of SurePayroll, a SaaS technology company that is now a wholly owned subsidiary of Paychex®. Alter co-founded SurePayroll in 2000 after six years with McKinsey and Company, where he was a co-founder and leader of its Service Operations Practice."

The mention of Steve Blank's methodology is interesting. The best work I've seen done on this phenomena of customer-value-driven entrepreneurship is from [https://www.effectuation.org/....basically](https://www.effectuation.org/....basically) that entrepreneurs start with what they have and the problems they know and go from there.

The counterargument is the Steve Jobs/Mark Zuckerburg argument for having a concrete vision and stopping at nothing to achieve a goal. But let's not forget that Apple started selling the Apple I which was primarily for hobbyists, and the Apple II didn't blow up until spreadsheets came out. Zuck was about to dedicate as many resources to Wirehog as he was to Facebook in the early days. Not to mention YouTube started as a dating site and many more classic examples of entrepreneurs having to figure it out as they go along.

I wonder what Keith Rabois would have to say to this. He has an interesting perspective in that he thinks founders will their companies into existence with clear visions that are often unwavering, and doesn't believe in the "lean" approach to building companies. Interestingly enough, Khosla where Keith worked earlier is the namesake of Vinod Khosla who does like the Effectual model of entrepreneurship (which is basically "lean" customer development based entrepreneurship). Another interesting thing to note is that most academic research into the age-old management question of what makes a good entrepreneur has far more to do with an individual's unique approach and perspective in the world, than it has to do with technology. Very few researchers are looking into "technology driven entrepreneurship" as much as they are personality, disposition, persuasion techniques, idea generation techniques, macroeconomic factors. This might change, but if anything when researchers look at entrepreneurial skill, technology skills are not the main focus. Again, this may be changing.

Personally, I think the only type of entrepreneurship that makes sense is very bottoms up. Look at the U-Haul story. The founder of that company simply did things none of his competitors would do because they thought it too risky.

<comment><USER18> My VC professor was the other co-founder of SurePayroll. He and Alter actually presented the idea to the CEO at Paychex in the late 90's. The CEO told them it was an extremely stupid idea that would never take.

About a decade later that same CEO was writing a check to them for $100M+.

They didn't even know how to design the algorithm for calculating payroll. They put the site up and had some elderly ladies who loved doing payroll calculate everything by hand and then send it back to a user within 24 hours. This went on for two months until they had figured out the algorithm.

</comment></comment><comment><USER5> People often say you have to start doing things to become better at it.

When I wanted to blog, I signed up at a blogging platform and wrote stuff. People started to read it and I got a book deal and some dev-rel jobs.

It just took me a few hours a week and I could start right away.

How do you start discovering problems of people that are worth solving?

<comment><USER19> Listen to them complain. Offer to solve in exchange for money. Repeat.

</comment></comment><comment><USER20> Most of the examples in this article are more of "Do things that don't scale", to solve problems as they arise and not "Forget about the Technology".

If you are a Tech startup, do not forget the technology.

</comment><comment><USER21> This logic falls into a cul de sac when you realize that many open problems can only be solved by new technology.

</comment><comment><USER22> It's almost like the customers are the ones paying money.

</comment><comment><USER23> What a gross mentality.. When people talk about "Silicon Valley tourists" this is what they mean.

<comment><USER24> Could you elaborate? It sounds like this is just promoting a problem/product first mindset, which - to me - sounds like a reasonable outgrowth of the lean startup method which you hear a lot about in startup circles.

</comment></comment><comment><USER25> Well, there are many paths I guess.

At Qbix.com we took the exact opposite approach. We are just in the Web / social networks apps space. But we reinvested half our revenues in new technology, for years, since 2011. Tortoise, not hare. Now we have superpowers. We can build anything, quickly, and we don't need venture capital.

On the other hand, we have heard no from like 20 VCs over the years. We had 7 million downloads now, $1M in revenues but we were still "too early" ;-)

In the last few years we made pretty "altruistic" or "anti-capitalistic" moves. We open-sourced it ([https://github.com/Qbix](https://github.com/Qbix)) and are exploring alternative financing to VC (ie actual _paying clients_ worldwide). We are trying to build a micropayment network ([https://qbix.com/token](https://qbix.com/token)) that helps everyone, not just us.

So basically it seems totally backwards from the current VC model but is actually compatible with it. I remember being inspired partly by DHH from Basecamp, and others. Remember — this is _your_ startup. Do you want to change the world? Innovate!

<comment><USER6> I'm having trouble reconciling your numbers here. You've been operating for 8 years, but your _revenue_ is only $1M and you've been investing half of that into your tech stack every year, so your operating budget for core business operations is $500k or less? That's like... two and a half developers. I'm guessing you're not US-based with those kind of numbers, but even so, at a glance, I wouldn't invest in you as a VC, either. From the numbers, you've built a lifestyle business.

<comment><USER25> This set of distinctions and decision tree is the problem.

A startup that has actual early revenues, has been around for years with millions of people using its apps and doesn't need VC to survive is called derisively a "lifestyle business".

You're right, most VCs wouldn't invest in such a startup. But if I spin off a "hot" NEW company with a cofounder growing 10% week over week with zero friction (no revenues) then the hockey stick looks attractive even with tens of thousands of people and a series of rounds can be closed before any revenue is made.

Why is having revenues and years spent developing in-house code less likely to produce exponential growth and a unicorn? Why is that worse than two college dropouts who cobbled together a solution and went viral for a while, such as Lantern or Shyo or Videology? Or a viral sensation flash in the pan like Down to Lunch? I have never heard it articulated well.

At any rate, we have a factory for making VC-attractive companies, if we wanted to go that route. Companies that do one thing, grow the userbase exponentially with no revenues, etc.

As for the numbers... yes we did spend most of our revenues on development. The team is in Russia and Ukraine, I live in NYC.

To answer your original question... we put out apps that have generated $600K very little upkeep, from 7 million downloads. We got additional money revenues and from angel investors. The platform is all about reusability — money spent on it is money spent on our projects and core business. But we open sourced it also. Just like Basecamp open sourced Ruby on Rails, or Fabien open sourced symfony etc back in the day. Just because we give it away doesn't mean it improving it isn't directly tied to our core business.

<comment><USER6> I didn't mean "lifestyle business" to be a negative term and don't use it that way... ever. The opposite, actually - I think actually-sustainable small businesses are far better in general than bullshit startups. However, you specifically said you have been trying repeatedly to get VC money and have been getting turned away. VCs don't invest in lifestyle businesses because that's not how their funds work.

The entire VC business model only works if they invest in companies with high risk/high growth prospects and the potential to be unicorns. To answer your question, the answer is statistics - VCs have a large history to draw from and have seen that viral companies and flash in the pan businesses either grow to massive exits or fail completely in a short time far more often than businesses like yours. On average, businesses like yours will continue a slow growth trajectory and have mediocre exits, if any exit happens at all, after the expected fund payout period has already passed. Basically, it's a drag on the fund portfolio and time/resources of the VC, so they won't invest - it's better that a company fail quickly while trying for unicorn status than it is that it chug along in sustainable small business mode for a decade.

On the flip side, there is an entire industry of funding available to you that isn't available to startups with awful financials - banks love to loan money to small, sustainable businesses with decent profitability. If you need growth cash, get a small business loan.</comment></comment></comment></comment>


"Mommy, why is there a server in the house?" by Microsoft - <AUTHOR> http://gizmodo.com/342499/microsofts-brainwashing-childrens-book-mommy-where-do-servers-come-from <comment><USER2> Hahaha! This was awesome.

"When daddy loves mommy, he buys her a server"

</comment><comment><USER3> WTF am I reading</comment>


101 Great Computer Programming Quotes - <AUTHOR> http://www.devtopics.com/101-great-computer-programming-quotes/

<comment><AUTHOR> "I think Microsoft named .Net so it wouldn't show up in a Unix directory listing."</comment>


Nook Simple Touch announced - <AUTHOR> http://www.marco.org/2011/05/24/nook-simple-touch <comment><USER2> The Kindle's screen, at the cost of some functionality and elegance, is not only relaxing to the eyes, but also completely kills the low-grade but omnipresent anxiety of a touch screen. Which means you don't have to worry about triggering a destructive action by accidentally brushing the screen somewhere and grip-placement is a lot less restrictive, i.e. if it's most comfortable to hold by a corner of the actual screen, you can. The physical buttons mean that I know for sure when I've made an input.

Not only that, but part of what made the iPhone's touch screen so much better than all the touch screen interfaces that came before it was it's insistence on a 1:1 direct manipulation paradigm, which simply isn't possible with current e-ink technology. This is more like a touch screen gesture based interface, which simply isn't that much better or more satisfying and is in some ways worse than physical buttons.

I find that the non-touch screen makes for a remarkably relaxed experience, but I'm afraid it's probably not enough of a concern for device makers to resist the whizz-banginess of the touch screen.</comment>


Opening the window in your home will not flush out the chemicals in the air - <AUTHOR> https://phys.org/news/2020-02-window-home-flush-chemicals-air.html <comment><USER2> It is really hard to interpret this. Opening the windows doesn't make the chemicals flee to the walls to wait out the exposure, or stop outgassing from surfaces. It seems like what matters is how long you leave the windows open, but it doesn't say how long they did. There ought to be a half-life of the surface reservoir for each chemical. They should say what they found it to be.

</comment><comment><USER3> The only way I can think this "chemicals are clinging to the walls" could happen is if during their experiments the air outside the house was colder. Then when opening the windows it would have flowed in and maybe pushed the sparser air to the sides, while they were sampling.

</comment><comment><USER4> This is not making any sense.</comment>


Ask HN: Was the free 1st episode of Silicon Valley an elaborate Googlebomb? - <AUTHOR>

I was looking for a way to watch ep2+ of Silicon Valley and I realized that most searches I would normally use to find places to watch it led to an interminable amount of blog posts and news stories about SV episode 1 being available on youtube. If they didn't intend to wipe out all links to pirate sites then it's a hell of a bonus. <comment><USER2> That's probably just because your keywords aligned with these more popular/recent blog posts. "watch silicon valley" would probably return that kind of thing - "silicon valley torrent" might have returned another set of results.

</comment><comment><USER3> That's not a Googlebomb.

</comment><comment><USER4> The second episode won't air until April 13th.</comment>


A 'Thank You' from Google - <AUTHOR> http://www.google.com/landing/thankyou/2010/

<comment><USER2> It's sure disheartening to see the majority of comments here say something to the effect of "20 mil is nothing—Google has so much more to give." Well they sure as hell do, but we wouldn't be saying anything if they'd donated nothing.

I don't see why it's Google's responsibility to donate a percentage of their income, or donate relative to other large donors.

I think it's cool Google donated 20 million. I don't know why it's on HN. I'm not going to take this as an opportunity to bitch about how they could have donated much more.

<comment><USER3> People choose to look at the relative value of money instead of its absolute value. 20 million for Google is nothing - true. However, 20 million as a US currency is huge and can benefit many, many lives. My question for HN is which way do you want to look at it?

Also, a question no one is asking: How much is Apple donating?

<comment><USER4> as I noted below, according to <http://www.google.org/> they gave "over $100 million" in 2009.

I think this video came from some specific campaign from google (notice if you go to the youtube page directly, the video is unlisted. also the whole "on behalf of our customers"...what does that even mean?).

maybe the OP can give some context?

<comment><AUTHOR> I got an email from Google with a thank you note and link to this video. I can't determine if the 'thanks to you...' is referring to me as a (one time) advertiser or as a regular Google user.

Edit (more clarity):

Here is the actual email from Google:

 _Dear ,

Thanks to you, this holiday season Google is able to donate $20 million to charitable organizations around the world. They in turn will help improve the lives of over 50 million people. Click here to see how.

Thank you for being a part of what Google is today. All this is possible because of you.

Have a wonderful holiday.

Google_

Note that my name was not included in the email. I'm guessing they're missing a record on me.

<comment><USER5> Advertiser, presumably. I didn't get one as a regular GMail user...

</comment></comment></comment></comment></comment><comment><USER6> I know this is a terribly jaded way to look at the world but when I see big corporations boasting of big donations to charity, which have to be only a small portion of their profits, it makes me wonder why they are paying their employees so little or charging their customers too much.

Their corporate voice doesn't speak for me and other individuals would have chosen different charities, so why don't they empower more people to make their own donations instead of taking from us and doing it for us in their own name.

What if instead Google just doubled the pay for all their employees in India (for example) and allowed those people to put the money back in their own economy as they buy things they need?

<comment><AUTHOR> I typically favor the 'hands off' approach to social causes. That is, individuals can do more good on their own than benevolent corporations or governments. That said, Google doesn't exist to do good deeds. It is a corporation designed to make a profit by providing a valuable service and charging for it. Donating was not necessary, and I applaud these 'giving back' efforts. I particularly like how it was quantified primarily in terms of number of people affected, instead of amount of money given.

<comment><USER7> Personally, I would rather they remove ads from YouTube videos. YouTube is a great channel for learning, but is becoming marginalized by needless, annoying crap popping up. Instead they have done what the rich always do, make a small, visible allocation of their profits to a "cause" that is easily marketed. They will certainly derive more revenue from increased traffic due to this advertisement than it cost them, and they get to feel warm and fuzzy about it at the same time.

This is not HN worthy.

</comment></comment></comment><comment><USER8> I'm honestly curious what they mean when they say "Google's customers". Are they referring to Google's _users_, or the much smaller group of people who pay for Google services?

This isn't just snark. I think that a corporation's responsibilities to its customers are different than the ones it has to its users, and its relationship to its customers should naturally be different than its relationship to its users. I wonder to what extent this distinction exists in Google's culture.

[Edited to fix an error in diction]

<comment><USER9> They would be stupid to make a distinction.

Users of Google's free services may not pay Google directly, but the currency is different and Google relies on both types of customers to stay in business.

As for responsibilities, they are the same as for any other company: provide better and better value while staying in business. Companies are not supposed to be socially-responsible, and shouldn't be treated as such.

</comment></comment><comment><USER10> Erm… I'm only seeing a "loading" throbber.

 _Edit after it becomes clear this is because I don't have Flash:_

They are not only blocking out users with Flash disabled and/or not available on their device, but also deaf users — there is no text equivalent provided. There isn't even an _explanation_ that a plugin is required.

<comment><USER11> This is also the first YouTube video I've seen, embedded or not, where the position slider doesn't work. I also can't click to view it on YouTube.

<comment><USER12> You can click on the YouTube logo in the video to go to the YouTube page. (I had to, because there no music played on the original site.)

</comment></comment></comment><comment><USER13> 20 million.

That's less than 0.1% of what Gates donates. That's about 0.01% of Google's market cap. That's about 4.6 work-hours of Google revenues.

Google is counting on people not having a feeling for what "million" and "billion" mean, aside from both being big numbers.

And part of what was advertised was charities using Google Apps.

I like Google, but this feels pretty cynical.

<comment><USER4> according to <http://www.google.org/> they gave "over $100 million in 2009." I'm not sure what this 20 million refers to, but it's not their total giving.

also, with Bill Gates you appear to be comparing total donations vs some yearly amount.

</comment></comment><comment><USER14> The URL to the YouTube video. <http://www.youtube.com/watch?v=R06EAUAi4MU>

HTML 5 enabled: [http://www.youtube.com/watch?v=R06EAUAi4MU&html5=1](http://www.youtube.com/watch?v=R06EAUAi4MU&html5=1)

</comment><comment> mike-cardwell This money is obviously doing a lot of good, but I have to ask why are they making a big song and dance about it? It's the equivalent of me donating 20 bucks to charity and then going around telling everyone. If they were doing it purely for altruistic reasons then they wouldn't even mention it. It definitely has a commercial purpose behind it. It's better than them not doing it, but don't fall into the trap of believing it's purely altruistic. Google employees don't have a higher set of morals than other companies.

<comment><USER15> The thing is, it doesn't matter. Money donated for ego purpose buys just as many polio vaccines as money donated for strictly self-less purposes. For some reason, we are taught that donating money should be strictly altruistic action and we get upset when someone is doing it for publicity or whatever. But in the end, it doesn't matter; money is money, and if people can feed their egos (or make their company look good), and charities get money, that's fine. Everyone benefits.

</comment></comment><comment><USER16> I'm as cynical as the next man, but at the end of the day a charity donation is a good thing.

All companies who do it should be congratulated, not winged at.

Encourage other companies to do the same.

</comment><comment><USER17> As one of Adwords' biggest advertisers, I'd like to thank Google for giving themselves a tax write off instead of giving me a holiday gift this year and last year.

It means a lot.

</comment><comment><USER18> Also, <http://www.google.com/chrome/intl/en/p/cause/#tnc>

</comment><comment><USER19> To be honest, I want Chrome for a cause to stay. It is one of the most fun dick measuring contests a bunch of web fiends can have.

I wonder what this did to Chrome usage ratings?

More on topic: how many of these charitable donations have a hidden agenda? Paying for schools in India, carefully nudging them to train engineers, having cheaper employees? etc ...

<comment><USER20> And to be honest it's a great way to showcase tabs.

<comment><USER14> Not when you hit the 250 tab max halfway through your browsing day.

</comment></comment></comment><comment><USER21> i don't think greedy is ever a word that will be used to describe google. ambitious, yes. greedy, no.

</comment><comment><USER22> you're welcome :)

</comment><comment><USER23> I wish youtube videos streamed just as nicely as this one.

</comment><comment><USER24> Are there really still people left, who are naive enough to think that charity really is for a good cause? It is basically just another business for rich people/comapanies to move money around. If it would work the way you think it does, why is Africa and South Asia still looking the same it looked 10 years ago, 20 years ago, 30 years ago?

<comment><AUTHOR> This is really something for a separate discussion, but a major cause for the poverty of the regions you mentioned have more to do with social and political troubles than economic issues. All of the money in the world donated to a region where warlords take it all will not make the intended recipients any better off.

Also, there is another argument that claims direct aid actually creates dependency, and development stalls because there is no motive to progress.

None of those arguments alone should be a reason to restrict your charitable giving, but keep in mind that there are situations in where even the most noble organizations will be helpless to improve a region.

<comment><USER24> I seriously think the idea of charity is flawed. There are so many things wrong with it, that it's really hard for me to put that into a comment.

Another point, quite important and often forgotten, is that people actually think, if they put some money in charity they did a great thing today. With a bright smile they walk on the street of their own city, letting drugs, raping, bad school education, homeless people and so on just happen. But that's okay. They come in heaven now, because they did charity...

But hey, when it is a company it must be better. Because they at least themself should know that it actually is a marketing campaign they are doing and not helping people.</comment></comment></comment>


Gamers Unlock Protein Mystery That Baffled AIDS Researchers For Years - <AUTHOR> http://www.pcmag.com/article2/0,2817,2393200,00.asp

<comment><USER2> Please stop posting articles with link bait titles. Even the abstract of the original article has more information [1].

[1] [http://www.nature.com/nsmb/journal/vaop/ncurrent/full/nsmb.2...](http://www.nature.com/nsmb/journal/vaop/ncurrent/full/nsmb.2119.html)

<comment><USER3> This seems to be a freely available version: <http://www.cs.washington.edu/homes/zoran/NSMBfoldit-2011.pdf>

</comment></comment><comment><USER4> This has always reminded me of the pilot episode of Stargate Universe, where Eli Wallace solves a real world complex math problem in a video game. Maybe Fold.It was thought up first, but it's a fascinating concept either way. It makes a person wonder what else could be accomplished via clever crowd sourcing.

Also see Google's reCAPTCHA project: <http://www.google.com/recaptcha/learnmore>

<comment><USER5> Ah. So these people are responsible for japanese, greek and formulas in my capchas.. they should really have a "I can't type this" button for more efficiency.

<comment><USER6> The top button out of the three (⟲) in the column is it.

<comment><USER5> Is it really? I thought it only gave a new capcha, without me giving a reason. I mean, there is a difference between being unable to read a word because it's so mangled and not being able to type something because I don't have that typeset installed / can't read the language.

</comment></comment></comment></comment><comment><USER7> Previous HN discussion about a different report of this same finding:

<http://news.ycombinator.com/item?id=3011044>

</comment><comment><USER8> For anyone interested in games incentivizing people to engage in research like this, I just saw a talk this morning that mentioned PhotoCity: www.photocitygame.com. It's a game to encourage picture taking of landmarks; the researchers then collate these into a 3d model.

<comment><USER9> There's also Eterna <http://eterna.cmu.edu/> \- I think it was on HN some time ago. (also biology-related)

<comment><USER10> looked interesting, but they want my email before they'll let me even try the tutorial. Disappointing.

</comment></comment></comment><comment><USER11> It's frustrating how this blogspam post, and the news articles it references, won't just simply link to the actual game's homepage: <http://fold.it/portal/>

<comment><USER12> all the pages in that site are identical to the home page. I guess there is some kind of problem going on.

</comment></comment><comment><USER13> this is a perfect exame of human computation

<comment><USER14> It is less "computation" and more "pattern matching/processing", something computers are really bad at, but people are relatively good at.

<comment><USER15> How is pattern matching not computation? The fact that you don't notice the underlying computational complexity is just a measure of how freaking good humans are at pattern matching.

<comment><USER14> It is true, at its core it is a form of computation. Though it blurs the line a little- the human brain isn't exactly pushing around numbers.

<comment><USER16> to be fair your computer isn't exactly pushing around numbers either. your computer does the same thing your nervous system does: push around electrical signals.

</comment></comment></comment></comment></comment><comment><USER17> Gameification - just another example.

</comment><comment><USER18> Maybe it's just me but this looks like major link bait no offense.</comment>


Attention CTOs: Culture Matters - <AUTHOR> http://pandodaily.com/2013/03/08/attention-ctos-culture-matters/

<comment><USER2> "you need to be in shouting distance or at least on the same floor"

What is, this a trading floor? For something that requires as much uninterrupted focus as coding, being within "shouting distance" of someone seems like the worst idea ever.

<comment><USER3> Fairly certain he means it as "be in the same room", "be present", "don't be in your high and mighty office". It's a phrase that doesn't actually mean shouting.

<comment><USER4> To any of the fair number of us who've worked in "best practice" open spaces, it means exactly that.

People standing up and shouting across two rows, for the sake of their own convenience.

I'd be careful in the use of such a description. And, overall, the OP reads as a pretty vacuous and narrow-minded post. He's looking for the like-minded, for all the "openness" to which he pays lip service -- that's how it comes across to me.

Not much value in my comment, I suppose, other than to point out that, for a fair fraction of us, "within shouting distance" is a quite literal (and unpleasant) experience.</comment></comment></comment>


Show HN: Discover coupons while you shop online - <AUTHOR> https://www.couponmate.com/?hn <comment><AUTHOR> RetailMeNot is a solid company, but organic search is their top traffic driver. They're incentivized to leave up the invalid/expired content.

In our case, the automation solves for expired/invalid codes, for sure.

And I understand the hesitancy around browser extensions. The coupon vertical doesn't have the most pristine history in that regard.

Appreciate your feedback!

</comment><comment><USER2> _When you discover a sale or coupon through CouponMate, and checkout on a affiliated merchant site after that, we earn a commission from the merchant._

Does this browser plugin interfere with and/or override tracking cookies from other cashback/points portals or is it additive? If it replaces, is there any way to disable or choose which one I'd like to use?

</comment><comment><AUTHOR> Oh, and.. ..video demo can be found at [https://www.youtube.com/watch?v=1Zwp09O4R2M](https://www.youtube.com/watch?v=1Zwp09O4R2M)

</comment><comment><USER3> Why shouldn't I use topcashback.com instead of you guys? With them you get to use coupons and get cashback also..

</comment><comment><USER4> Please don't use visual gimmicks like "¯\\_(ツ)_/¯" in titles.

</comment><comment><AUTHOR> We currently support ~1,000 stores for full automation.

Would love any feedback or suggestions.

<comment><USER5> At a glance it looks really neat. I have to admit, I'm still reluctant to install random Chrome extensions (as much as I am to install random desktop applications I guess) I really wish they would change their permission model somehow (Like this tab I currently have open gets access only)

How do you feel about RetailMeNot? I stopped using them fairly quickly on because the vast majority of coupons were expired or otherwise invalid. Do you think you'll run into that problem or is the automation you mention getting around that?

<comment><USER6> For what it is worth, the local code from Chrome extensions is easily available on your computer for browsing. On windows they are located in the "C:\Users\<ACCOUNT NAME>\AppData\Local\Google\Chrome\User Data\Default\Extensions" folder. The extension folders are named with the ID of the extension, so it may take some trial and error to find the right folder or you can dig into the developer mode of Chrome to find the ID for a specific extension . The extensions themselves are just javascript and potentially HTML. You still won't be able to see any server side code, but it should at least tell you if anything you think is important is being saved or sent elsewhere.</comment></comment></comment>


Why are software development estimates regularly off by a factor of 2-3? - <AUTHOR> http://michaelrwolfe.com/2013/10/19/50/ <comment><USER2> So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing. Let's extend the analogy somewhat... this isn't your first hiking trip. In fact, you've been on dozens and dozens of hiking trips. You're an experienced hiker. Yet, why do you continue to give meaningless as-the-crow-flies estimates of how long it will take you to get to your destination? The reason is that if you miss your estimate, it probably won't matter. Your sherpas will be there at every stop with your food, water, and tent. You have nowhere to be any time soon, so estimating your time just isn't important enough to worry about.

Developer estimates are regularly off because they seldom impact the developer directly. Experienced development managers will pad the hell out of the developers who give them the worst estimates. Most developers will explain all the complexity of what threw their estimate off without acknowledging the huge mistake of not anticipating extra complexity in the first place.

My estimates in my early career were no better than anyone else's, ie way off -- especially for more complex projects. I'd explain what happened to my managers and soldier on. The very next task that came up, I'd give my manager some best-case estimate of how long something would take and the cycle would begin again.

That all changed once I started to do consulting for myself using "not-to- exceed" pricing. The first multi-month project I did killed me. My effective hourly rate went down to sub McDonalds levels and took much longer to deliver than I had expected. After that project, I did a post-mortem on the project to figure out where I went wrong. I came up with several spreadsheet templates and checklists to run through before giving any more estimates.

Mostly I just concerned myself with getting a hell of a lot better at estimating project duration and difficulty. Like most things, when you really pay attention to it and practice it, you get better at it.

<comment><USER3> Been going at it for a couple years now with consulting and freelancing. I've finally gotten good at hitting my estimates. What worked for me was to keep strict time of everything (shoutout to toggl.com, love it!), so I could learn from my mistakes.

The trouble is now though, my competition seems to be underbidding me, but in reality they're providing those ~33% estimates they will never realistically keep, while I'm at ~100% estimates. Not really sure how to relay that to clients. One of the many reasons people like me need a salesperson in front, I guess.

<comment><USER4> You're probably losing more business than you think - customers have no idea who is accurate or who is just faster, etc. They will generally go with the lowest quote regardless of other factors unless they've been burned before multiple times. Most people haven't.

I don't have a solution here though other than noticing that underbidding and then getting skilled at convincing clients to do paid extensions later actually appears to make the most money at the cost of your ethics. I'd avoid that approach, but it does seem to work for a lot of companies.

My personal approach is to quote for very bare projects with only the bare essentials (eg, poor UI design, minimum possible feature for the client to see what they're asking for, etc). This can usually be done a lot cheaper than most people think as 90% of the work is in the last 20% of the features. Then once the client has something, you can give them a quote to touch up the parts they need. Basically you split the project up into many small projects each with their own quote which helps you to estimate tasks as they appear and helps your client to minimize costs by leaving off features that are more expensive than they initially appear.

<comment><USER2> I get contract work through referrals. I'm not interested in being perceived as a "low cost developer".

I would just as soon not keep customers only interested in the lowest price. They're the ones that typically will be the biggest headache.

<comment><USER5> The other side of that coin is that often the clients I get via referrals have no reasonable alternatives. They often have done all business through referrals and so the alternative to me is the open market which is intimidating and has a significant barrier to entry. The end result is that we build a solid and stable client relationship that generally only gets upended if/when money runs out.

It's a great position to be in, provided you have the throughput to expand to other clients and aren't dependent upon a single client for income.

</comment></comment></comment></comment></comment><comment><USER6> It's simple. People don't like the honest answer.

As a developer, I have pressure to keep my estimate down. I can give you a guaranteed date with few problems, _but_ the project is going to end up more time-consuming than what another developer is going to estimate.

The good news is that I will usually significantly beat my estimates under this system. However, I will then be accused of padding my estimates and will be given more aggressive targets, some of which I will miss.

The best way to combat this is to give me a team that has worked together on multiple projects within the domain, and account for changes and ambiguities as part of the process.

</comment><comment><USER7> The problem is that people try to eliminate uncertainty instead of trying to manage it effectively. If you're trying to make estimates with more than order-of-magnitude precision, then you're probably doing something wrong.

If we drove cars like we develop software, we would pre-calculate a list of instructions, set a timer, and then execute those instructions without regard to what's actually happening on the road. With practice, you could probably get better at making those lists of instructions, but why bother? The general approach is just ridiculous.

Decades of experience have shown that there is enough inherent uncertainty in software development that trying to plan everything from the start just doesn't have a high success rate. Even if you know everything that has to be done _today_ to get the job done, your environment will change, and your stakeholders will change their minds. What good is software that perfectly solves the problem you had two years ago?

Once you dig through all of the buzzwords, "Agile software development" is simply about applying closed-loop control theory to software development: You structure your project to provide high visibility and to allow frequent changes in direction, then you iterate and make adjustments until the result is satisfactory.

Everything else generates unnecessary risks that somebody ends up paying for.

</comment><comment><USER8> Because management looks at you funny when you say something simple will take 4 months. Then they lie and say that it couldn't possibly take that long. And the reason they lie is because there's no negative to them tying to you. Their job is to get you to go faster, and they are allowed to lie as part of their job, if it makes you go faster. The reality is that it doesn't make people go faster. It makes people leave faster. It makes people give up. Never give an estimate to management. Estimating is their job, as they control the inputs to production. If you give an estimate, they will pressure you to meet it, no matter how unreasonable it later turns out to be. That also makes people want to leave.

<comment> w0rd-driven Management giving estimates? No thanks. I'd rather them take my input and do their job of understanding trends. When I say something takes a long time and it takes longer, I'm not bullshitting. When I think something takes a long time and doesn't, its generally because shortcuts are rarely understood up front. Will I find the same shortest path next time? If I'm doing the same exact work maybe.

I do work in a place where we are a software company but very few people, even some of the devs, understand this culture. I don't say something is complex just for the hell of it. I want to give good estimates but at the end of the day that is all it is, a somewhat educated guess _before_ I've gotten in the weeds. I don't need people that absolutely don't understand this concept to mandate a timeline that is unrealistic. It does absolutely no one any favors. _That_ is why I leave. I don't need to promote unrealistic expectations down the line to customers who think everything is extremely simple. Especially when all we do is create custom software where almost 0% is turn key or off the shelf. Its just insulting to continue that nonsense and the quicker I can facilitate a reality check for all parties, the better and more trust is given to my judgment (and theirs if they actually take the time to learn)

<comment><USER9> > Management giving estimates? No thanks.

This is actually achievable in a sane way.

I have done it using the XP planning practices. Basically, you make the suit break everything down into relatively small lumps and place them in priority order. Every week, the team completes a few lumps. Before you do them, engineers grade their relative complexity in arbitrary units. (The smallest substantial thing you do is 1 point; something twice as big is 2 points, and so on.) Every week, you count up the points completed. That's your "velocity".

From there, you let managers do all the estimating they want to. If they want the complexity of a unit of work measured, they ask the engineers. If they want to know when X will be done, they look at the team's recent velocity, what's in the queue before X, and do some basic math.

The nice part about this is the mental judo involved. Whenever they want to know when something will be done, it's their problem to trade features against time. Working like this, it's not geeks vs suits; the suits channel their schedule pressure into productive work: grooming the backlog.

<comment> w0rd-driven I misspoke. What you are describing comes from developer feedback but indirectly in a sense. This, I think, is a nice standard of measurement. Its when people solicit absolutely no feedback either in the form of past projects where hours are measured somewhat or what they just "feel" something should take. I'm all for metrics based estimation because that's how most developers would likely estimate. Its when management seems to pull things out of their ass to get a prospective client I have a problem with. I understand when we need money but I can also trace some of our worst clients to some of the most unrealistic estimates we've ever given. They're almost a 1:1 direct correlation and its like no one sees how much of a drain they can be all around.

<comment><USER9> I have been there, and feel your pain. It has taken me a long time to learn to say, "Oh, you told somebody that? Well, then _you_ have a problem, don't you?" Of course, there are some companies that are so pathological that this stuff just won't get better: there's a broken feedback loop between the promises and the consequences. Ugh.

</comment></comment></comment></comment></comment><comment><USER9> I love this post; it conveys the feel of the experience so well.

One of my big aha moments about estimation was a bit in McConnell's _Rapid Development_. He pointed out that most estimates get made with executives pressuring for short numbers. When you iterate a few times with that, you end up with the smallest number that developers can't absolutely prove is impossible.

If you draw out a bell curve of probable completion dates, this is basically the same as picking one far to the left, so you have a 95-99% chance of being late. But somehow, executives are still surprised when their totally biased approach yields the numbers they liked, not the numbers they needed. All the estimation effort was pure waste; our time would have been just as well spent making cotton-candy raincoats.

I now have done a few projects with little to no estimation, and it has gone much better. I have a hard time now seeing why we ever bothered.

<comment><USER10> I once read an argument that went something like this: if you're actually going to go to the trouble to build something, its expected return to the business should be so large that how long it takes (within reason) shouldn't matter. Conversely, if a project is only economic to undertake if it can be done within a certain amount of time, it shouldn't be done at all.

I find that I often don't have a good feel for how long something is going to take until I'm about 1/4 the way through the project. If I absolutely had to produce accurate, high-confidence estimates, I would just do 1/4 of the work first, then estimate the rest.

As to _why_ estimating is so hard, here's how I like to think about it. Tasks form a tree: each project has a number of steps, each of which itself breaks down into sub-steps, and so on. We tend to estimate by thinking about the tasks near the root of the tree; but the actual time required is proportional to the number of _leaves_ \-- tasks we can implement without further breakdown. Without planning the entire project out in detail it's hard to know what that number is. But to plan to that level of detail requires making many design decisions; and researching and making those decisions _is much of the work of the project_.

The bottom line is, good estimates are expensive to produce, and my experience aligns with yours: it's rarely worth the trouble.

<comment><USER9> Agreed. Certainly, estimates of cost shouldn't be more precise than estimates of value, because ROI is the number that matters. And business is a black enough art that estimates of value are very rarely more precise than a factor of 4x.

What I think people try to get from estimates is a sense of control. But I think there are better ways of giving people not just a sense of control, but actual control.

</comment></comment></comment><comment><USER11> Good points in the article.

You can think of it this way. A coast line is a fractal line. As you zoom in its length gets bigger and bigger seemingly. From the top level on the map it looks fairly straight.

Related to estimates. Programmers have and operate with idealized mental models. A FIFO queue works kind of like this ("/closes eyes and sees a line of people lining up at the store"), a tree traversal looks like this ("/closes eyes sees a red cursor move down a tree drawn with blue nodes on an white board"). Same with estimates. How long will this take? ("/closes eyes and imagines an idealized sequence of events that will lead from now till project completion -- use this library, develop that API, test a little bit here, done... 2 weeks").

The problem is, zooming in is hard. "Oh this library we are about to use actually doesn't implement these corner cases". So now we are spending 3 days patching it. Oh, while working on this project, a critical support ticket comes from a customer. And then testing reveals a fundamental flaw in our API design. Re-write a huge chunk and repeat.

Some developers and managers just use heuristics. They do the mental estimate then x2 or x3.

^ All the above is true if the developer is everyone is honest and trusts each other. As other posts wrote, that is not always the case.

Then it is a more complicated game. The main question to ask then is "What is the punishment for overestimating vs the punishment for underestimating?".

Have people been fired for underestimating? No, ok underestimate. Have people been fired for missing deadlines? Ok then overestimate.

You can even play this game with yourself. What kind of deadlines do you set for yourself and how to you handle setting a too short or too long of a deadline? Do you get better with time at setting deadlines? If no, why not?

<comment><USER12> I think the fractal analogy nails it.

Haven't thought about it before but I realize I too use a heuristic of x2 or x3 when estimating my time. Nothing would stop me from getting a pen and paper out and stepping through the 'trail' in my head in pseudocode beforehand, but for most of my projects I'd benefit from just writing the real code from the start and apply the time I saved to the project.

</comment></comment><comment><USER13> Imagine you are going on a hike to the top of a mountain. Countless paths exist between you and your destination. Most of these are dead ends. Every dead end forces you to backtrack, sometimes all the way to the beginning.

Software is a lot like that.

<comment><USER14> Then whoever was planning the hike decides to go to a different peak when you're halfway up the mountain.

<comment><USER15> 99% of the time you'll die before reaching the peak due to lack of water or food.

</comment></comment></comment><comment><USER16> This post was originally an answer on Quora to the question posed in the title [1]. The question has so far received 222 answers - some of them arguably better, though not as popular as this one.

[1] [http://www.quora.com/Engineering-Management/Why-are- software...](http://www.quora.com/Engineering-Management/Why-are-software- development-task-estimations-regularly-off-by-a-factor-of-2-3)

<comment><USER17> This blog article is more popular than the quora post because this blog article doesn't require people to sign up to read it.

<comment><USER18> There was a trick posted recently to HN for reading Quora articles without signing up:

Tell HN: Add ?share=1 to Quora URLs to display content without login

[https://news.ycombinator.com/item?id=6300856](https://news.ycombinator.com/item?id=6300856)

<comment><USER19> I still don't want to support any site that uses this business model. You want me to use your site? Make it easy for me to come by for the information I need.

</comment></comment></comment></comment><comment><USER20> Software-development estimates are regularly off by a large margin for two reasons. First, the problem is inherently hard. Second, social and business pressures bias the estimates downward.

Why is the problem inherently hard? To see why, let's imagine that the All- Knowing Fairy Godmother of Software Estimation descends from the heavens and lends to us her magic estimating function _F_ that, applied to any software project _S_ , will tell us exactly how much time and money our preferred software team will consume to implement _S_. Don't worry about how _F_ works, just believe that it does. (Okay, okay. Let's just say that _F_ peers into a parallel universe in which our team has _already_ implemented a software system line-for-line identical to _S_ , and it just observes how much time and money were actually consumed in that universe. Anyway...)

Now that we have the magic _F_ , our problem is easy, right? Nope. The real problem is that we don't know what _S_ is. All we actually know is that our _S_ , whatever it ends up being, must satisfy some set of fuzzy constraints _C_ (commonly called "software requirements").

In truth, there are a countless number of possible values for _S_. In other words, _S_ is a random variable, a mapping that ascribes a probability to each of the possible software systems that we could build to satisfy _C_. Therefore, our best estimate, even with the perfect estimating function _F_ , is itself a random variable. In other words, it's not an estimate but a distribution of estimates.

See how fun this is getting?

But, wait, it gets funner. That's because people in the business world don't want a distribution of possibilities. They want a budget, a date on the calendar. So we must squeeze point estimates out of the true distribution. (And, remember, we don't even know what the true distribution is!)

That's where the second reason kicks in. Let's just think about the distribution of possible budgets for our distribution of possible values of _S_. Because _S_ can range from "the simplest thing that could possibly satisfy _C_ " to "the most insanely complex thing that a frighteningly gifted salesperson for an enterprise consulting firm could get our CIO to throw money at," that distribution is going to be w-i-d-e. From _X_ to 10 _X_ wide.

So if we're the folks tasked with coming up with those point estimates, we could plausibly estimate _X_ on the low end, or 10 _X_ on the high end, or anything in between. Guess which estimates are going to get us the most push- back from the higher-ups?

Now, we're swell guys and all, and we want to do a good job with our estimates. No question. But, still... We're human. If we think that giving a higher-end estimate is going to make us unpopular with the higher-ups, maybe we'll estimate a little lower. And when we get push-back on _that_ estimate, maybe we'll "take another look at the numbers" to see if we "missed any opportunities."

And that's the old one-two. We start with a hard, fuzzy problem and then add to it the pressure to deliver only feel-good solutions. The result: estimates that are often way low.

<comment><USER21> For what it's worth, I haven't seen hardware engineers complaining about this issue as much as software engineers, which I find baffling. I think if you're going to justify why software development is such a "hard" problem, you should mention what makes it so different from other fields.

<comment><USER20> Here's the thing. Software is profitable at much lower quality levels than the hardware market will tolerate. As a result, most hardware is designed through a process that could accurately be called engineering, even though most software is not. So hardware engineers get to make estimates with the benefit of having fairly reliable engineering outputs to use as estimating inputs. Further, the business side of hardware is more culturally attuned to the realities of engineering and is therefore less likely to challenge estimates coming out of mature engineering processes.

In short, on both sides of the old one-two punch, the hardware guys have got advantages.

<comment><USER22> So the hardware estimate is more "how long will it take to debug the prototype, and bring it to production"?

<comment><USER23> More like,

1) When someone buys custom built hardware, they know what they want, and the specifications for it. When someone buys software, they want "something that does xyz, is just like facebook and paypal, but also has our logo." And then it turns out that the problem they're trying to solve is completely unrelated to any of those things. But you can just rewrite it to do those things too, right?

2) If there's a problem with the hardware, the customer that paid the money for custom chips will notice, and will have the technical skill to lay the blame on the vendor accurately. This means hardware manufacturers need to deliver quality, and since point #1 guarantees they actually have a specification, they can therefore engineer to it. In software, often the client takes your application, puts it on machines from the mid 90s that it won't run on, gives it to minimum wage employees to use (so management may not really care if it works), and then ask if its too late for the product to also be an app on their iphone. When they can't do anything with it 3 years later because it was written by people who have never looked at a computer before, the customer will just say "software always has bugs / always going out of date, find a new consulting company to write us a new one", as if its normal to have to build a completely new system to do the same thing over and over again every three years.

</comment></comment></comment></comment></comment><comment><USER24> [http://coding.abel.nu/2012/06/programmer-time-translation- ta...](http://coding.abel.nu/2012/06/programmer-time-translation-table/)

I occasionally just paste this link with no explaination at the end of emails containing time estimates.

</comment><comment><USER25> Most people would agree that practice makes perfect, right? I think a big issue with software estimation is that it is hard to get practice. I'd done full project estimates for 4-6 projects in 3 years of working professionally. Compared to the amount of practice I have writing code, this is nothing. How can I ever hope to get good at something if I only do it once every 3-6 months and it might take 2 years to get feedback on if my final number was close to the actual cost? And unlike other skills, I can't practice on my own or take a course (I've never seen an open source project that did round-trip estimates, maybe that's something to try out...)

Another issue is when you have an "indirect estimate" \- basically I will estimate the work, but someone else is the one that ends up doing the project. If you aren't careful to consider who will be doing the work, you might estimate too low (if you are an expert and the work is done by a bunch of new hires).

And none of this even touches on misinterpreting client demands, scope creep, dev team turn-over, or often neglected timesinks like documentation and meetings.

</comment><comment><USER26> Kept waiting for the punchline where the friend has moved to Las Vegas and a total replan is required.

<comment><USER27> "Oh it's just one state over, I didn't think it mattered. See you tomorrow!"

</comment></comment><comment><USER28> The single biggest mistake in the example is giving an estimate for the whole project without knowing team velocity. He tried to plan everything up-front and committed to a completion date, strongly setting delivery expectations.

An Agile approach to this walk would have managed the expected target date much better and improved team morale by not overstretching each day ("sprint").

Lots of people think they know (and implement) Agile. I did, until a course I took about a year ago where I learnt skipping seemingly unimportant bits (measuring velocity, sprint retrospectives, etc.) bring the whole process crashing down.

<comment><USER29> _The single biggest mistake in the example is giving an estimate for the whole project without knowing team velocity._

I'm inclined to agree. Often though a client will want an estimate (to a ridiculous accuracy) before agreeing to the work. Unless you churn out web page templates or something equally repetitive it's hard to have that relevant velocity.

I still come up against client managers that don't "believe" in Agile approaches too.

<comment><USER28> Oh we still get regular "lively discussions" about exactly what features are going to be in a product with a release date 6 months away. I can completely understand though; it's very difficult to leave a conversation being told "we don't know yet, it's likely to be X & Y (but we're not 100% sure) and possibly Z too".

</comment></comment></comment><comment><USER30> I just had an estimate/actual conversation that went like this: I think it will take me X time. Ok, but I want it done in .5 X time. Ok, I'll try to get it done in .5 X time. I finish it in X time.

Is it a missed estimate? That depends on who answers.

<comment><USER31> > Ok, I'll try to get it done in .5 X time.

Never, ever say this.

Personally, I always give my estimates as a range. If you break down your project into small tasks, and estimate each task as an optimistic/pessimistic range, then you can get a pretty good idea of the expected completion date, along with the deviations from that which you might reasonably expect.

However good your estimate, committing to ONE number is madness - it hides the complexity of the situation, making it impossible for you or your manager to see the real picture.

</comment></comment><comment><USER32> Years ago, I was introduced to the (simplistic) dual concepts of profit centers and cost centers.

To many in Management and accounting (and with varying degrees of pointy- haired-ness), profit centers "make money" while cost centers "spend/burn/"waste" money.

The sun shines on the former, while the inquisition perpetually stalks the latter.

Systems and systems software are often seen as a cost center. There is constant pressure to "control" these costs and to do more with less.

People are required to be over-optimistic in their communication while at the same time overly pessimistic ("frugal") in their resource allocation. Note the use of the word "pessimism". It is not so much a matter of "optimisim" thinking that "we can get it done with less"; rather, it is the pessimism of "we can't afford that".

Much of my professional life has been spent in big, "conservative" (cough), risk-averse organizations. I'm sure things are to some degree different elsewhere -- some _degree_.

Nonetheless, it's worth keeping in mind this (simplistic, and to varying degrees counter-productive) concept of "profit centers" and "cost centers". And if you are working for the latter, expect to be squeezed into ever more unrealistic positions.

It's something the seasoned professional stays attuned to. There will always be some squeezing; when it starts to worsen and become excessive, it's time to go. Your personal solution, as a "simple" employee, is to find another organization -- the sooner, the better.

</comment><comment><USER33> I have found that providing estimates within a range is the most reasonable approach.

The range is usually between "this is the likely amount of time with everything going as it should" and "this is the worst case scenario time with all that can go wrong".

It's a pretty broad definition between the two but I find it gives clients a sense of the scope of the project. The minimum time does include some padding to include all the usual likely overruns (testing, requirements gathering, etc.) but not too much.

The worst case time better really be worst case as I provide clients the expectation that it should not take longer than this.

I find that usually I will end up somewhere in the middle of the estimate and the client is still happy since they didn't hit the worst case scenario.

I find that this usually tends to be relatively effective even if as a rule of thumb the worst case time is 3-4x the minimum time.

Of course, there is still a lot of analysis done to come up with this range and there is a lot of discussion with the client to help them understand the details on why and how it could go.

At the end of the day, communication is king. I find that educating clients about the complexities of the process always helps to gain trust.

</comment><comment><USER34> Forgive my username, there is nothing logical about this.

It's because estimates are really just a test of your imagination and skill. They're a "different game" from delivering something. Here are some examples:

How long does it take you to add 1 + 1 together? The only correct amount of time is "0 - no amount of time." But clearly that's not true, is it?

How long would it take you to multiply 5 by 7? Well, zero. No amount of time - you know it 'by heart'. It doesn't take you any amount of time to multiply 5 by seven. Well, clearly, that's not true is it?

How long would it take you to test whether 31337 is prime or not, by any means? Like, 1 second because Wolfram Alpha can tell me I bet. But clearly it wouldn't take me ONE second, would it?

How long would it take you to write a function to test whether an integer less than 2^32 is prime or not, without having to be super-efficient about it? Well like 10 seconds. But, clearly that's not true, is it?

And so on. How long does it take to put a twitter bootstrap page up? Like, 5 minutes.

How long does it take to...

You should be able to build an app that doesn't crash and does what you're trying to code in like a day.

You should be able to build something that is software you can launch with in like a week, as an MVP.

You should be able to replace someone else's mature product with a reimplementation in like a month.

You should be able to build a scalable business that is ready for a series A in like a year.

These things are not meant to be accurate, so much as show that you have imagination.

</comment><comment><USER35> This McConnell book[1] is a must read on the subject. Generally developers just fail at estimating at a fine grained enough level and forget about all the ancillary tasks that take up a majority of a project's time.

[1] [http://www.amazon.com/gp/aw/d/0735605351](http://www.amazon.com/gp/aw/d/0735605351)

</comment><comment><USER36> I enjoyed reading this the first time around. I purposely illustrates the complexity of software and perhaps inadvertently illustrates the challenge of getting schedules from inexperienced teams. In rebuttal, had they walked from San Francisco to LA along any freeway they would have been done much closer to their predicted date. Which they would have known had they been experienced in walking back and forth to LA from the Bay Area.

The "big" message is that if you have _never done_ something before, you have no idea how long it will take, even if you can describe what you are going to do pretty easily. Returning to the hike metaphor, this is why you need to listen to the cranky old guy saying "walk along the roads, not the beach" instead of the inexperienced folks saying "Hey its just walking, and walking on the _beach_ rocks! Walking along a road is boring and lame!"

</comment><comment><USER37> I admit it's funny but if I showed this to a non-programmer friend, he'd be asking why I didn't research my route better or start on an unknown trail with minimal planning.

<comment><USER38> Because the research will take a significant part of the project time. Once the thorough research is done - third-party libraries are verified (that they do what's needed, and not too buggy), prototypes are written (to confirm libraries and internal dependencies work as expected), proof-of-concepts are run (to actually see that it's possible for a reasonable effort), time is measured (to confirm the way to go), interfaces are clarified (as part of the research, specifically, in the architecture department), results are estimated (basing on all results above), specifications are formalized (and agreed upon) - there is an awful lot less of what to do.

<comment><USER39> Maybe part of the problem is that development organizations don't tend to charge for pre-estimate planning.

</comment></comment></comment><comment><USER40> To put it simply: software estimates are hard because nobody has made that particular bit software before. Why? Because software doesn't rust. There is little need to exactly duplicate software which has already been written. Thus, most software is charting unknown territory.

</comment><comment><USER41> Expect to be told, halfway there, that the party has moved to Tijuana. After all you agreed to hike to the party and it would be unreasonable to expect of the host not to move the party when the weather changes.

</comment><comment><USER42> We sometimes make white label geo apps for other companies. We've repeatedly had problems where our estimates were off by quite bit because we got data in incredibly bad formats from the customers. And not just once, every time they'd send us updated data it would be in a different format.

The first time or two it made us hate the customer, and feel like it wasn't our fault. But then we started writing it into the bid, and telling the customer they could save money if they delivered conforming data. Hopefully we'll be happier from here on out.

</comment><comment><USER43> To extend the analogy further: add the fact that you need to meet up with several other groups that are providing essential supplies and they are hiking from several different locations in the Central valley.

Some of the groups are showing up on time and are waiting for you, some are late, all won't have all the supplies you need.

And to make it more realistic: half way through the hike, your friends call to say the lunch has been moved to San Diego and is now a formal dinner party at which you will need to wear tuxedos. And can you bring the Champagne as well?

</comment><comment><USER44> After getting a number of my estimates wrong recently I was thinking about this question. While walking to work I determined a few things.

It's hard to estimate something that is complex. If I am very confident the job can be completed in under an hour my assessment is very close to 100%. This is because something simple does not have a lot of variables and interacts with very few things. Things like fixing a display bug, a simple calculation, adding a print now button are all easy. Once you go beyond this it gets more difficult to determine how long something will take.

Business wants the estimate done quickly. Many businesses want estimates done fast. An accurate estimate for a complex job cannot be given fast. There has to be several rounds of back and fourth. Use-case scenarios need to be determined, which will open up even more questions. The underlying architecture to accomplish the feature also has to be scoped which will take time and usually we don't get it right the first time we think about it

Some more reasons are, businesses want the job done quicker than is realistic. Businesses don't know everything they want. They think they need stuff that they never end up using. Haven't thoroughly thought out the feature or problem themselves and that uncertainty gets passed into the development phase more often than not. Business is not solely to blame though. Sometimes developers think a particular portion of their code will be simple when its not or difficult when it isn't.

Basically the whole process is riddled with human error on both sides.

</comment><comment><USER45> People are generaly optimists and with that anything in the future will be biased towards ideals, even planning for exceptions will bias towards a ideal.

The other factor is feature creep, if you find a project so well defined and set in stone then it would be fair to say it will have a better chance of finishing on time.

That is just the software side, then there is the hardware to run it and that opens up a whole new aspect of poetntual delays that will get leveridged at the project and when people say project behind involving software people will just focus on the software aspect and all other factors are buried.

Bugs and issues come from many factors and even suppliers of hardware can have bugs which can have a impact, design could have bugs and many aspects can have issues that impact the end result.

But it is impossible and silly to plan for every situation as whatever you plan for there will be an exception and you get a deminishing return, hence easier to have a area of time labeled contingency as a catch all. Best example of such exceptions would be say an earthquake killing your entire development team, that can and has happened and at the same time is not something you plan for. Partialy why we have insurance. Though you will find it very hard to impossible to get insurace again software development delays beyond life/death of parties involved, though that will not chance the delay into a non-delay, mearly compensate.

With all this Engineers have for many lifetimes gone with the engineering factor or whatever you think it will take, muliply that by 2-3 to counter optimisim. But that does not help feture creep and anything added to the design after code has started is creep.

</comment><comment><USER46> I loved the article, but I was hoping we'd get a reference to the Coastline Paradox[1]. Basically, since a coast is a fractal, its distance is infinite. The "zoom" that caused the very first delay could keep going, and going, and going.

Anyway, nice article!

[1] [http://en.wikipedia.org/wiki/Coastline_paradox](http://en.wikipedia.org/wiki/Coastline_paradox)

</comment><comment><USER47> That's a very interesting sort of analogy. Among most of the discussed issues,

a) For one, giving enough time to come up with a project estimate is often rare. Usually people try to ask for those upfront.

b) Usually we try to add a general buffer for any unseen issues. However, the deeper you go and list tasks against time, the closer to realistic is the total.

c) Often it is just a customer giving a requirement needed at date x, or a management guy setting goal for a date y. When all you can do is to cut features but have to deliver by a given date.

d) No matter what we say, but at the back of our minds, we are not enough prepared to defend a timeline when giving it in the first place. Implementing feature x needs a week? gosh boss would say it should take a day. Latter it turns out the assumption was based upon a library which for just internal implementation reason (that you only discover upon learning it enough through actual code) is completely useless and it should actually be planned for 3 weeks at least.

</comment><comment><USER48> The short answer is optimism and poor assumptions. The hiking analogy works well to illustrate this answer.

Everyone who has been a part of a software project knows about poor assumptions. From the start, you don't have well-defined requirements. You don't have a complete design. You don't understand the consequences of decisions you have made or will make. Any estimate is doomed to fail in the face of all these poor assumptions.

Staggering a software project into smaller chunks goes a long way to controlling these poor assumptions and the impact to schedule and, more importantly, customer expectations.

The principles of the agile manifesto go a long way for mitigating the too common pie-in-the-sky wishful thinking that dominates software engineering. They work even better when the customer realizes they are a part of the system under development and its success - if they can keep that balanced with giving the development team the space to do what it is they do.

</comment><comment><USER49> Well, yes, but also (stretching the analogy) how many times have we been asked for a schedule to an unnamed destination via unspecified waypoints and then told it's too long and we need to make it shorter?

Devs make mistakes, sure, but as often as not in my experience it's absurdly vague end user requirements married to unrealistic expectations.

</comment><comment><USER50> Dumbing down analogies aside, you can look at software development as a graph of connected tasks with each task having some variance around when it would complete. This variance accumulates as taskw are completed and you move on to next nodes in the graph. When you complete the graph, you have large probability distribution about average ETA.

Most decision makers have to choose some number for ETA however because world does not understand probability distributions or variances. Most likely this has to be lower end of the number to get project sponsored or fend off the competition.

This is not unique to software development. Any projects that requires large connected graph of small task nodes would show same characteristics. For example, fighter jets, Boeing Dreamliner, space station etc etc.

</comment><comment><USER51> Because the estimates are always BS, but teams get 2-3x slack before they are force to declare victory and launch whatever they have. The more over budget they get, the more they cut features (including QA and security details)

</comment><comment><USER52> I really love this article.

In practice a good strategy for companies is reduce unknown to a minimum, the Steve Jobs strategy, just focusing on very few products, with each having the less complexity possible(simplify and simplify).

Only focusing on very few products you could make perfection possible, estimates will be off, they always are when there is unknown, but at least completion will be finite (you will complete it!, which is number one issue with research work for example).

Sounds simple, but is really hard, leaving creative people on their own is dangerous for this reason, they could start new projects, not finishing anything.

<comment><USER18> Reducing the complexity of products is an enticing ideal, but in reality, some products are inherently complex. Let's take one of Steve Jobs' products, iOS, as an example. No matter how much you try to simplify it, it's going to be a huge piece of software (I'm guessing hundreds of developers and supporting staff). Apple's success has depended on keeping customers engaged by regularly coming out with improved versions of products, so they need to estimate fairly accurately what the release dates are going to be: being six months late could be disastrous for marketing efforts and the company's stock price (e.g., you want to get the next version of the iPhone in the stores by Christmas). So you can be sure that there are people at Apple whose job it is to make very careful estimates of how long it will take to develop stuff.

</comment></comment><comment> dj-wonk Summary: The fractal dimension of a software project is roughly 2 or 3. :) [https://en.wikipedia.org/wiki/Fractal_dimension](https://en.wikipedia.org/wiki/Fractal_dimension)

Now, if you think about that metaphor for a while you may find value in seeing: (a) the metaphor doesn't really fit intuitively because software projects are often charting new ground, not zooming in on a predefined complex problem (b) the metaphor is not too bad of an intuitive explanation -- you learn more about what is really needed as you get closer to the details.

</comment><comment><USER53> If you can suspend the obvious question of why are you hiking from San Francisco to LA in the first place, the general analogy holds quite well: With software development, you can not know how long it will take until you know exactly what you are building. You can not know exactly what you are building until you have fully described it. The act of describing it fully, precisely and with sufficient quality, is the act of coding.

Hence the completion estimate has to be continuously refined as the details of implementation are continuously refined.

Just like the slow zoom-in on the hike.

</comment><comment><USER54> I think the calculation usually goes like that:

      * Take a day to come up with "estimates" for the project,
        can't bill that time of course.
      * Sell fantasy gant chart to the customer.
      * Take 10-20% of the projects time away for "project management".
      * Actually develop the software.
      * Fix "bugs" until customer goes silent.

If you want good estimates you need to take estimates and project management more serious and get away from that waterfall methodology.

</comment><comment><USER55> Kahnemann and Tversky call it the "planning fallacy".[1] the interesting bit is that the predictions are pessimistic when you get "non-involved" parties to estimate time to completion of the same task. Perhaps using a figure between self estimates and third party estimates may work?

[1] [http://en.wikipedia.org/wiki/Planning_fallacy](http://en.wikipedia.org/wiki/Planning_fallacy)

</comment><comment><USER56> In this analogy, you have a single destination; anything short of that is useless.

What about the agile idea that you deliver something incrementally useful with every sprint?

Obviously, some projects can't be done that way. But if they can, it would mean 1) estimation can be done on a 2-week scale instead of maybe a 6-month one, and 2) they can start deriving benefit/making profit from what you've built while you build the next thing.

</comment><comment><USER57> Allowing for end-customer's bad habits, such as delayed payments, real-time changing of specs and other unknowns that are fact of life for developer.

</comment><comment><USER58> [http://en.m.wikipedia.org/wiki/Planning_fallacy](http://en.m.wikipedia.org/wiki/Planning_fallacy)

</comment><comment><USER59> If only they used one of those frameworks, that lift you off the ground and glide you towards the destination effortlessly, graciously pulled by flying pigs, there would be no delay. They would even have time for daily scrums. Always pick the right technology stack, guys!

</comment><comment><USER60> The joke between us engineers at work is to estimate the project time, then multiply by pi.

<comment><USER61> You sir are the inspiration for my new workflow. pi based software dev

</comment></comment><comment><USER62> For me, a lot of underestimation is about motivation. I work best with looming deadlines. I _feel_ like I will be motivated to work harder with a deadline that's less realistic, even if that' not always true.

</comment><comment><USER63> One reason is as an industry we are terrible at planning. We do a very unthorough job of planning details or requirements. Then we allow for changes and new features mid project with no respect for budget or time.

</comment><comment><USER51> That's a great story for why the first project is slow. But next time, you say, OK, we can hike 10 miles a day, so it's 60 days, and it _still_ comes out 2-3x of budget. Why?

</comment><comment><USER64> Okay, I agreed (had no other choice) with management to not have less than 20% variance in my estimates.(read: negotiated-and-reduced estimates) as a part of our performance metrics.

<comment><USER65> Reduce your batch sizes to reduce uncertainty.

</comment></comment><comment><USER66> For the same reason other estimates are off by a factor of 2-5, unless contractual penalties are agreed on. The cheapest contractor gets the job, and can adjust the estimates later.

</comment><comment><USER67> I try to do my estimates (team size, man-days) in Big-O notation. Haven't nailed how to do that yet, but it helps people understand that estimates are non-linear functions.

</comment><comment><USER61> when asked to estimate, i ask if the biz if they can also give me an estimate for meetings, UAT, changes, hiring resources, unscheduled downtime and scheduled downtime and historic data comparing previous project estimates to actuality. Its the only way to get closer to accurate.

The developers estimates generally are best case scenarios without any external or motivational factors included.

</comment><comment><USER68> Here's another question: "Why are software feature requirement estimates regularly off and changing while in progress?"

</comment><comment><USER69> Imagine estimating the time to complete a hike, and then being told that a bunch of children will be coming along.

</comment><comment><USER70> Because software estimate is impossible, if it's possible, then you are re- inventing the wheel.

</comment><comment><USER71> Another reason is, that there are the first 90 percent and then there are the other 90 percent.

</comment><comment><USER72> As opposed to what? Marketing estimates? Scrum and such can be used by Marketing and others.

</comment><comment><USER73> I just don't know why people won't arbitrarily add 2-3 more time on the estimate...

<comment><USER74> Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

<comment> dj-wonk According to DJ Wonk's Law (shamelessly self-named), when discussing software estimation, it is inevitable (only a matter of time) that someone will mention Hofstadter's Law.

</comment></comment></comment><comment><USER75> Because software developers, like most people, don't like conflicts.

<comment><USER76> also because we don't have Time Machines

</comment></comment><comment><USER77> All estimates should be multiplied by Pi.

</comment><comment><USER78> Only 2-3? Please tell me your secret!

</comment><comment><USER79> It's the halting problem.

</comment><comment><USER80> Here's my experience with this problem. First, a number of people go meet the clients, often several times, to see what the client needs. Generally however, none of the people involved with actually building the product are ever involved in the meeting (because, from the mouth of the Boss, "operations are too expensive"), and in the unlikely event that they are, they're essentially shut down because "nobody really cares about the technical details at this point"...

This is then followed by extremely loosely defined requirements being passed down to the technical people in hope of getting an estimate back. Technical people, especially experienced ones, know how this goes. First, you know you don't have half the details you should have, even though you've most likely asked for them numerous times. But you know, "all I need is an estimate" says the sales guy (who in this case also happens to share the board, made solely of other sales related people). You already know you can't win here, so you give a ballpark estimate considerably above what you imagine should be the real value, hoping it'll cover your ass, but highlighting the fact that until more details are given, this is still a ballpark figure.

It doesn't matter. The sales guy takes your estimate, shaves a third off of it, throws in a couple of bonus features in there (which are most likely of no use to the client), and makes it a hard estimate. When you point that out, you're told not to worry and that it's not your problem (spoiler alert: it very much is). So you write your specs down, or rather, you slap a few bullet point lists together with whatever little time you're given (you're expensive). This is given to the client as what both sides should abide by, despite you repeatedly saying that it's a bad idea.

From that point, you realize that the time you've been given to achieve the work is, roll drums, not nearly enough. You can already see poorly defined features growing arms and legs: clients, and I can't really blame them, will use any vague requirements to their advantage. You also realize that in order to do all the work and still meet the deadline (you still most likely won't), you have to half-ass a bunch of the work. You can already imagine the support issues pouring in once the project is in production, and you see all those legacy projects constantly getting in the way of your new, poorly estimated work, thus slowing it down even further. You will also get blamed for all these issues that are cropping up from past projects, and this ties to the next point.

The best one of all, that thing that wasn't your problem, suddenly is. You've somehow become responsible for the poor estimates you clearly said weren't to be relied on. So you know, you better make an effort and fix that by, say, working extra hours here and there, like, every single day. You burn out and grow frustrated, which slows the work down even further. Even better is that your crazy work hours become an expectation, if you happen to finish a project on time this way, it'll be used as "See, no problem here, you got it done!", pat on the back and condescending compliments ensue.

So you realize you're never given time to do decent work, that at the end of the day you're better off not meeting deadlines, and that whatever happens, you're always on the losing side.

I'm not saying this is the case in all companies, but I've also seen this far too often. On the very few occasions I had the chance to be the main point of contact with clients, projects were on time, clients were satisfied, and of course, some sales guy still slapped his name somewhere on there and got his bonus, but at least I got to do good work on reasonable deadlines.

I loathe most sales and marketing people, I often find they're a completely unnecessary layer in product and value creation. It's not that their position couldn't be of value, but I don't believe it can be if the money incentive is always more prevalent than the idea of good work done or happy people. As Henry Ford said, _" A business that makes nothing but money is a poor business"_.

Note: I've resigned from this job to work in research.

</comment><comment> zupa-hu thanks, was a great read!

</comment><comment><USER81> My estimates are always off because management decides to constantly change requirements or didn't have all of the requirements in the first place.

</comment><comment><USER82> Because no one wants to admit they still have to learn more about the system they are going to build.

<comment><USER83> There's something to this, no doubt. I recently took part in a project where a firm was contracted due to their "expertise", which they fulfilled by hiring a team of contractors, most of whom were woefully unprepared, in terms of knowing the system on which they worked.

</comment></comment><comment><USER76> why? focus very closely on the following word:

estimate

</comment><comment><USER84> Egos.</comment>


Federal investigation of Facebook could hold Zuckerberg accountable on privacy - <AUTHOR> https://www.washingtonpost.com/technology/2019/04/19/federal-investigation-facebook-could-hold-mark-zuckerberg-accountable-privacy-sources-say/ <comment><USER2> You can't be the CEO, chairman of the board, and majority voting shareholder, and not be accountable.

<comment><USER3> While I agree I really can't see him being held responsible by US laws.

<comment><USER4> or any other national or international court for this matter

</comment></comment></comment><comment><USER5> For those of us facing the GDPR pay-wall:

[https://web.archive.org/web/20190419064551/https://www.washi...](https://web.archive.org/web/20190419064551/https://www.washingtonpost.com/technology/2019/04/19/federal- investigation-facebook-could-hold-mark-zuckerberg-accountable-privacy-sources- say/)</comment>


Boy, 8, evaluates software for Silicon Valley company - <AUTHOR> http://www.statesman.com/news/content/news/stories/local/10/04/1004whiz.html

<comment><USER2> registration required, copy/paste in here please

<comment><USER3> Works fine for me.</comment></comment>