The Founders Visa Movement - <AUTHOR> http://www.feld.com/wp/archives/2009/09/the-founders-visa-movement.html <comment><USER2> Unfortunately, the proposals in this blog entry make me very nervous. I'm all for making it easier to allow talented people entry into the US, but I hate the idea of empowering investors to grant green cards. I think Paul Graham is an inspired investor and a smart guy, but should he be allowed to decide who comes into the country and who doesn't? Should a panel of credible lawyers, VC's, and entrepreneurs be allowed to do this?

I think that an employer should be able to offer a _job_ , not US residency. I think an investor should be able to offer _money_ (and advice, guidance, support). But not a green card, no way.

Think of the implications here. A young investor really doesn't need the money. He's ramen profitable. But he needs the investor's permission to be a startup _in the us_! Well, that's one way for VC's to get the upper hand in an era when their money doesn't matter as much.

Look, I know hacker news folks tend toward the libertarian side and are generally skeptical of government. But I want the people who decide to award green cards to report to the voting public, not to Larry Ellison. I admire PG, but he doesn't answer to me as a member of the voting public, and he shouldn't. Once VCs gain control over the immigration system, they assume a government role, but we can't exactly vote them out of office if we don't like their decisions. And even if you have faith that PG will be a good guy, do you feel that way about "credible VCs and lawyers?"

Winston Churchill said "It has been said that democracy is the worst form of government except all the others that have been tried." Personally, I'm not all that interested in trying out a regime of VCs, no matter how credible a panel has found them to be.

As for the "Green cards to all CS majors" idea, I think a very narrow rule targeting CS would discourage US students from this field, and encourage them instead to pursue more protected degree paths like law. I'm worried about any policy that would drive the already low interest in CS among US students even lower. I also think a University should be in the business of granting degrees, not US residency.

<comment><USER3> Yep, this part really struck a nerve: _(2) the founder has to own at least 10% of a company that has raised $250,000 within the same year as the application for the Visa._

This is a power trip from the VC's it's also a method by which they can extract more equity from the founder of the company using "coming to america" as a carrot.

What does raising money have to do with founding a company? This is a stupid and ego-centric view of entrepreneurship.

90% of VC funded startups fail. 80% of restaurants fail and according to the SBA, _as a general rule of thumb, new employer businesses have a 50/50 chance of surviving for five years or more_ <http://www.businessknowhow.com/startup/business-failure.htm>

Seems like it would be better for america if raising money was _not_ a requirement of being a founder.

<comment><USER4> This is indeed a terrible idea. Every day it seems like I read folks on hn who are indeed familiar with start-ups and _investment_ but who think they thereby understand _economics_.

The first thing they often don't understand is how _perverse incentives_ work. Consider, lots of folks with $250K in the bank would be happy to get a guaranteed $50K out of it. So they would "invest" (launder) the money into a _fake_ start-up which would serve only for the "found" to give them back their $250K plus $50K in return for the "founder" getting a green card.

Just one bad effect of this would be the fake start-ups themselves, which would pollute the start-up space with starting with more fake craiglist ads on up.

<comment><USER5> A book I had about US immigration said that the situation you outline actually occurred with the E-2 visa for quite some time. That's why the criteria for the E-2 are so strict now - if the criteria weren't so strict, it'd be the ideal "founders visa" already. Basically the post is proposing creating a lax E-2 (of sorts), which already failed once. (Even though people are throwing around numbers of $500k, etc, for the E-2 - that was certainly not the case even a few years ago.)

Perhaps the most interesting comment over there is on relaxing the criteria for the O-1 visa instead. Perhaps instead of being "incredibly famous" you could just be "well known in your field" instead.. I better keep in the top 100 on Hacker News then ;-)

<comment><USER6> My mother managed to get an O-1 actually - and she's not even college- educated. She's simply quite well known and regarded in her community (knitting, arts and crafts), and that was that.

Maybe more founders ought to look at the O-1.

<comment><USER7> Bearing in mind that the O-1 is a non-immigrant visa (my friend is on one).

</comment></comment></comment></comment></comment></comment><comment><USER7> I'm a potential user of such a visa.

As it stands, right now, I'm likely to start a company outside the US. I'll create jobs overseas instead of here just because of the hassles I've had with US immigration. I find the situation to be rather illogical.

I'm currently on a H1B and in the greencard queue. Anti-H1B people love to rave about my taking jobs from US citizens. I get to hear it in person from time to time because, since I'm white and speak English with an indeterminate American style accent, people presume I don't object to them bitching about the Indians and Chinese H1B holders while I wait at the coffee stand.

I'd rather start my own company. I've had a startup before in Europe so I know what I'm getting into. Then someone else could take my current job. I'm financially secure (close to $1m cash in the bank in addition to my long-term investments) but:

\- I want to solve my immigration status and not resort to non-immigrant temporary visas like E-2

\- I'm not happy to just hand $500k to $1m over to an investment of unknown risk to get an EB-5

\- There is enough to do while starting up without getting bogged down in convincing some non-expert in the merits of a business plan and a schedule of hiring etc.

\- My H1B NIW just got a request for evidence despite my letters of recommendation from "household names" in my particular industry (sorry to be deliberately vague).

\- I have a government in another country willing to throw money at me to startup there

Now I could startup abroad and transfer back and jump thru various hoops that way. But, frankly, I have a young family and want to build a permanent base for myself. I rather like Northern California for that but there are many other nice places in the world as well.

 _shrug_ it leaves me confused as to why the US is so hostile to my intention to build a home here and create jobs.

<comment><USER2> "Anti-H1B people love to rave about my taking jobs from US citizens."

I'm largely opposed to the H1B visa, but I definitely don't like to rave about your taking jobs from US citizens. I certainly don't think that you have.

This visa was truly a miserable piece of public policy, and I think the US should regard it as a failure and try to implement something that is in the better interest of the American public as well as the people who would like to work here and would make great contributions.

I read a bit about Australia's points system, and I think it's a good approach. You get points for having valuable skills, proficiency in english, and so forth. If you exceed a certain threshold, you get a "visa" (I'm not sure if that's the term they use, it's a residency and work permit). What's so cool about this system is that the visa is granted directly to the individual, so it preserves freedom. I also like it because it doesn't single out high tech - lots and lots of different professions and trades get full points, so engineers/programmers won't feel singled out and thrown under the bus, so to speak. While the needs of employers are a factor (a job offer adds points), it doesn't give employers control over the worker's right to reside in Australia.

I know you've had a bad time of the US immigration system, and anti-H1B ranters have given you plenty of opportunity to view critics of the program as anti-immigrant (and even potentially racist). But I'm hoping you can also agree that many US citizens who work in technical fields are legitimately outraged about abuses of this program.

I don't mind at all if you personally disagree that the H1B program has deterred Americans from entering the field at a time we badly need to ensure a steady supply from our own population, but I do think you should recognize that this is a reasonable point of view that can and should be debated.

<comment><USER7> Putting my frustrations to one side, it seems clear to me that there are problems with the program, there are abuses of the program, and there are people like me caught in the middle of it all. However, some of the worst abuses, such as by Indian consulting companies that bring people over and then don't pay them while they are "on the bench" should be solved simply by enforcing the existing rules. Anytime you hear some consultant mention "the bench" there are these types of abuse going on.

Both the Australian and Canadian processes look far more sane to me. The Canadian one also runs roughly along the lines you mention.

I don't know whether Americans have been deterred from entering the field or not. However, I do know that in my particular subfield there is a distinct shortage of qualified people of any nationality.

</comment></comment></comment><comment><USER8> If Brad Feld wanted to encourage entrepreneurship, he'd be bothering his Congresscritters about healthcare reform for 47 million uninsured, not making a special path to citizenship for a handful of people.

Yes, we lose some startups because of our immigration laws, but we lose far, far more to job lock-in because of healthcare.

<comment><USER9> I'm not sure that mandating young, healthy people to spend their own money on health insurance will make them more willing or more able to start companies. Health care reform can help, or it can hurt. It really depends.

</comment></comment><comment><USER10> I'm surprised this idea passes anyone's laugh test. There are all sorts of issues here with distorted incentives - if my ability to stay in the US is conditional on running a company, then I will do everything in my power to keep the company limping along, and I will be loath to take certain classes of risks. This seems in tension with the very concept of a startup.

But the more fundamental flaw here is privatizing decisions about citizenship. I can't think of anything that's _more_ appropriately handled by government.

</comment><comment><USER11> I like the way the UK/Canada do it. Why can't the US?

You need 75 points.

1) An advanced degree gets you 35. A PhD 50 and an MBA 75 (debatable, but good)

2) Gross salary over the last year gets you another 30 points (so if you made above $70k/yr)

3) Age gets you another 20 (below 28)

4) Work experience in the UK and English language qualifications get you another 10 points

Sure, this may not work for the people straight out of school (you do need 1 year of earnings and any decent dev with a Master's should be able to pull 75k) - but a couple of years of real world experience after school is probably a good thing, right?

Why does the US tie you to an employer? Probably because the H1-B program was a way to bring (relatively cheaper) labor into the US.

<comment><USER12> Let me guess, you are a UK native MBA holder under 28?

Not for nothing, but valuing an MBA higher than, say, a math Ph.D. is a bit insulting to some. MBAs are just taking jobs from other MBAs, really.

Edit: braino

<comment><USER2> I agree that it's offensive, but it's also honest. If companies are going to pay MBAs more than they pay PhDs, then they _should_ lose their right to claim that there's a "shortage" of PhD's!

<comment><USER12> In my opinion, MBAs are a commodity almost. PhDs may well be unique and irreplaceable (although not all). Note that Google founders were in a PhD track, not MBA.

<comment><USER2> Yer preachin' to the choir dude. But if you look at the starting salaries for MBAs, JDs, and Math PhD's (from top programs), the market signal clearly suggests that lawyers and MBAs are more valuable than PhDs.

Personally, I suspect this reflects cartel building and market coercion (lawyers), as well as the reality that finance people can earn large salaries without actually producing any wealth.

So personally, I do think that math/sci/engineering folks are often far more valuable than the MBA/JD folks, but I can't get behind any "shortage" argument until their pay reflects this.

</comment></comment></comment></comment></comment><comment><USER13> This is fantastic. And the initiative speaks volumes of why US is the hub of startups.

I would any day opt to move to US and build a company over there given US is relatively a superior matured market segment for online businesses and more than that for the excellent startup ecosystem.

In the past have built products predominantly for US audience including a book readers community on facebook (which was my baby) that eventually got acquired by lulu publishing. But now when I am on my own startup I am devoid of deeper & closer understanding into the market/customers, the US presence to promote my products and access to funds, mentors and product launchpad.

Recently got a B1 visa to visit US but I was so uncertain of even that given I am self employed, single, with not much assets and in all ways seem to fit a potential immigrant in the view of the consulate. I couldn't have thought of any way to explain the consulate "a regular job" doesn't interest me and I am not going to take away jobs.

I am sure a lot of entrepreneurs in this part of the world would be blessed and move to silicon valley following their dreams of building a business and fortune.

</comment><comment><USER14> %10 of 250k company would simply create a visa for money path.

Getting VCs to sit in a government committee and review thousands of visa applications seems rather unlikely, and their success prediction ratio is questionable.

The various legibility profiles I've seen (like those in Canada etc) all seem to filter out Steve Jobs, Bill Gates, Larry Ellison..

Perhaps a solution is to allow investors like YC sponsor something like H1B granted to their companies' founders rather than their own employees.

But, is there really a need for all this? Why does anyone have to be in the US in order to start a company? If anything, shouldn't the web make geography _less_ of an issue?

</comment><comment><USER15> Good to see that someone is acting on it. However, the following quote makes me worried about the bureaucracy.

(1) set up a non-government board consisting of credible VCs, entrepreneurs, and lawyers to vet applicants.

It probably is a better solution than what PG proposed in his original essay. "let the market decide. Startup investors work hard to find the best startups. The government could not do better than to piggyback on their expertise, and use investment by recognized startup investors as the test of whether a company was a real startup."

PG's version would eliminate anyone who would bootstrap a startup without external funding. Brad's is a little inclusive.

I would rather prefer to leave it at "let the market decide."

Any interesting ideas as to how you could convert that statement into an actionable policy for immigration authorities to follow?

<comment><USER16> I would feel uncomfortable giving recognizable VC firms a competitive advantage in this way. If KP gets to select who gets into the US, chances are they will have a lead on getting to invest in those people.

That said, I also don't like the idea of having a non-government board decide.

</comment></comment><comment><USER17> Being in the situation myself, I think the implementation Brad is proposing might not be good in the long run (reasons posted by other users).

IMO, any co-founder of the company who owns more than a particular amount in the startup and the startup is at a stage where it can afford paying $100k+ salary to the co-founder should be able to obtain a visa. If the startup is VC funded, even better. But again there should be a complete background check and the startup business plan should be assessed by an independent committee before granting a VISA. Also, educational qualifications of the co-founder should be taken into account like PhDs should get the top most priority.

</comment><comment><USER18> I am a (US) college senior and i really want to start a company after i graduate. But the regulations just make it so difficult for me. It is good to hear that someone cares enough about this issue to start a conversation.

</comment><comment><USER19> It's a great idea, and with a reliable vetting process in place, could help spur US innovation even further.

</comment><comment><USER20> Grant citizenship to anyone who comes to the US and completes a PhD.

<comment><USER2> Thomas Freidman suggested this in "The World is Flat." I liked some things about this suggestion. It doesn't specifically target engineering or science, so it wouldn't distort the market, and a Ph.D (I think Friedman included all doctoral degrees) from an accredited institution is sufficiently rigorous that I don't think it would be as easy to "game" the system.

But still, there are a lot of things I really don't like about this proposal as well.

My experience as a grad student in engineering at Berkeley has left me convinced that these programs are utterly abusive of their students. If there's a shortage of Americans willing to sign up for PhD's in STEM fields, these institutions _deserve it_. Plus, starting salaries for PhD's in science/engineering lag badly behind MBA/JD/MD programs. This would only exacerbate the situation. And if a Ph.D granting institution is able to award citizenship along with a PhD, there's pretty much no limit to the abusiveness they'll get away with. Hey professors - Want to keep your highly trained poorly paid lab tech around for another year? No problem - you control his dream of citizenship, so trust me, he'll keep working 80 hour weeks for you for $22K a year.

When this sets the standard for treatment of grad students, Americans will all but abandon the field. Expect the already high percentage of foreign students in PhD programs to jump even higher if this becomes policy.

<comment><USER7> My experience as a grad student in CS at a UC left me with the same conclusion. I left, in ABD status a year after getting my MS because of the working conditions. It makes no financial sense to do a PhD in CS unless you want a pure research or Professorship. I'm significantly ahead financially of my peers who completed the PhD program and professionally as well due to my experience.

Of course there are neat ways for PhD holders to sidestep labor certification to hugely speedup up their greencard applications so I am somewhat being punished for making the saner professional/financial decision!</comment></comment></comment>


Second woman claims she was paid to pick up ballots in US House District 9 race - <AUTHOR> https://www.wsoctv.com/news/local/second-woman-claims-she-was-paid-to-pick-up-ballots-in-us-house-district-9-race/883177036 <comment><USER2> It's really sad that we have such low visibility into _actual_ voter fraud. It seems our elections are broken in such a way that no one is interested in fixing them lest they lose some particular advantage.

It's enough that now I've had enough. I want ID required. I want real paper trails. I want to know exactly how many ballots were issued and where each of them was sent. I want to enforce laws such as cutoffs.

People who say there's no evidence of voter fraud. How would you even know?

<comment><USER3> > _It's enough that now I've had enough. I want ID required._

I understand and agree with the sentiment. I worry, though, about placing too many administrative hurdles in front of a fundamental right. ID is already required; but I assume you mean photo ID. But photo IDs aren't free, and neither is transportation or time off work. Some part of me is concerned that photo ID laws amount to a poll tax. I'd be interested to know your thoughts on that.

<comment><USER4> >I worry, though, about placing too many administrative hurdles in front of a fundamental right

>Some part of me is concerned that photo ID laws amount to a poll tax.

All the arguments against ID requirements, poll taxes and other measures used to disenfranchise poor people can be turned right around and used to argue against licensing requirements, fees and other typical tactics used to keep (mostly poor) people from exercising their right to keep and bear arms.

Either restricting people's fundamental human rights is ok or it isn't. I know which hill I'm dying on.

<comment><USER5> > Either restricting people's fundamental human rights is ok or it isn't.

Are you equating the right to bear arms (as part of a _well regulated_ militia) with fundamental human rights? I think that one might need a bit more explanation.

<comment><USER6> My opinion is that the individual right to self-defense is a fundamental human right.

<comment><USER5> Okay, but self defense does not necessarily mean firearms. Applying the argument to firearms restrictions is like applying the right to have a voice in governance by requiring a specific type of governance (such as a true democracy instead of a representative one). I don't believe there's a fundamental human right to have a firearm any more than I think there is one to have a nuclear bomb. Both can be (and have been) used for defense, but we do not allow individuals (or even all countries!) to have both.

A firearm is one tool of many that can be used to defend yourself. Voting is _the_ method for the citizens to control government in a Democracy. Once you take away or impede someone's ability to own and operate firearms, you have hampered their ability to protect themselves in some small or large part, but there are other methods available to them. Once you take away or impede someone's ability to vote, you are affecting their only way to actually affect their own governance. (all the above all assumes _legal_ recourses are considered).

Note: This isn't to say I think we should ban guns or anything, I just think as fundamental rights go, what was presented originally was not equivalent in my eyes, as explained above.

<comment><USER4> >Okay, but self defense does not necessarily mean firearms.

There is a fundamental human right to defend yourself from physical violence. If there are tools that are used for that task then it follows that one has a fundamental human right to posses tools that give one the means to do so. If the year was 1018 we'd be discussing bows and swords instead of firearms. In 3018 we'll be discussing lasers or something like that. In 2018 (or 1788 for that matter) the tool is firearms.

>Voting is the method for the citizens to control government in a Democracy. Once you take away or impede someone's ability to own and operate firearms, you have hampered their ability to protect themselves in some small or large part, but there are other methods available to them. Once you take away or impede someone's ability to vote, you are affecting their only way to actually affect their own governance. (all the above all assumes legal recourses are considered).

While I understand where you're coming from I think you're wrong because I don't believe there is a meaningful distinction. The union of all fundamental human rights is greater than the sum of them individually and each right is so important in the context of the others that a threat to any one human right is a threat to them all.

>Once you take away or impede someone's ability to own and operate firearms, you have hampered their ability to protect themselves in some small or large part, but there are other methods available to them. Once you take away or impede someone's ability to vote, you are affecting their only way to actually affect their own governance. (all the above all assumes legal recourses are considered).

So is it ok that the government routinely tries to side step the people's right to not be subject to unreasonable searches and seizures and right to due process because people can still vote for a government that won't do that?

I don't think the right to vote is any more important than any other fundamental human right.

</comment></comment></comment></comment></comment></comment></comment><comment><USER3> The lengths North Carolina Republicans will go to cheat democracy is hard to stomach. (N.B.: This is not a partisan attack on Republicans generally, but a criticism of one specific organization.)

To my knowledge, they're also the only ones in recent history to be overturned by a federal court for just how gerrymandered the districts in NC were.

[https://www.washingtonpost.com/politics/courts_law/supreme-c...](https://www.washingtonpost.com/politics/courts_law/supreme- court-sends-case-on-north-carolina-gerrymandering-back-to-lower- court/2018/06/25/03c1119e-787e-11e8-93cc-6d3beccdd7a3_story.html)

<comment><USER7> To be fair, this appears to be the work of a rogue candidate, Mark Harris, and his supporters, not the GOP establishment. The Republican incumbent, Rep. Pittenger, was also targeted, when Harris challenged and narrowly defeated Pittenger in the Republican primary earlier this year.

[https://fivethirtyeight.com/features/what-the-heck-is- happen...](https://fivethirtyeight.com/features/what-the-heck-is-happening-in- that-north-carolina-house-race/)

> _It turns out that the data irregularities in Bladen County extend to past > elections, too. The 9th District saw a contentious and razor-close > Republican primary in May 2018, when Harris ousted incumbent Rep. Robert > Pittenger by 828 votes. Bladen accounted for 56 percent of the absentee-by- > mail ballots (456 of 811) cast in that primary despite being home to just 6 > percent of those who voted — and Harris won 437 of those absentee-by-mail > votes to Pittenger's 17, a massive gap nowhere near either the absentee-by- > mail results in other counties or the other results in Bladen. And in the > 9th District's 2016 Republican primary, 22 percent of the race's absentee- > by-mail ballots were cast in Bladen County. That time, they went > disproportionately to Pittenger challenger Todd Johnson — he won a whopping > 221 of Bladen's 226 absentee-by-mail votes._

[https://www.rollcall.com/news/politics/rep-pittenger- fully-a...](https://www.rollcall.com/news/politics/rep-pittenger-fully-aware- of-unsavory-people-in-election-fraud-claims)

> _"We were fully aware of it. There's some pretty unsavory people out, > particularly in Bladen County. And I didn't have anything to do with them," > Pittenger said in an interview with Spectrum News in Raleigh._

> _Pittenger, who lost his GOP primary to Baptist minister Mark Harris by 828 > votes earlier this year, said he did not know what would happen to the > general election results. Harris holds a 905-vote lead over Democrat Dan > McCready in the election that has now been cast in doubt._

> _"I don't have a clue. I have my feelings about what's right or wrong, but > let's leave that to those who're [leading the investigation into the > irregularities]," Pittenger said._

If the North Carolina Republican party were smart they'd support the bipartisan ethics panel and wash their hands of Harris.

</comment></comment><comment><USER8> Elections are woefully behind the times - I can track my pizza, but I can't track my vote? I feel that political infrastructure are where technology can really positively disrupt the landscape.

I know it's _en vogue_ to show how easy ballot machines are to cheat and hack -- and maybe they are indeed incompetently built. However, this doesn't mean there isn't a way to use technology to make democratic processes more accurate and streamlined. I pay my rent online, I see my doctor's appointment lab reports online, and I have a powerhouse in my pocket. Technology can be used for evil in this context (see Cambridge Analytica and Russian troll farms), but we need to figure out how to use it for good.

<comment><USER9> Seems like vote tracking would open elections up to massive vote buying problems and possibly de-anonymization.

</comment></comment><comment><USER10> What's more interesting is what they're doing out in California. Campaign workers are going door to door and pushing voters to fill out absentee ballots, then delivering them to polling places.

<comment><USER11> That sounds like either something that didn't happen, or something legal that you are intentionally twisting to make sound equivalent to the (very illegal) things that are going on in North Carolina. Care to provide some evidence backing your claims?

<comment><USER10> It's anecdotal at this point but I think ballot harvesting did play a role in California. Why keep ballots from people you think might be opposing your party? Toss them and keep only those you think will vote for your party. Next time the Republicans are going to go big for ballot harvesting and I think we're going to see huge fraud issues.

[https://www.sandiegouniontribune.com/opinion/the- conversatio...](https://www.sandiegouniontribune.com/opinion/the- conversation/sd-what-is-ballot-harvesting-in-california-election- code-20181204-htmlstory.html)

[https://www.latimes.com/opinion/editorials/la-ed-ballot- harv...](https://www.latimes.com/opinion/editorials/la-ed-ballot- harvesting-20181207-story.html)

</comment></comment></comment><comment><USER12> I dont understand how the US people and courts allow everything that has been going on.

If here in Australia they tried any of the Gerrymandering/voter suppression/political power-plays/outright fraud that has been going on for YEARS in the US, there would be heads rolling.

I mean we're pretty apathetic when it comes to politics, but the turning a blind eye to the activities in the US system is just astounding.</comment>


Using Behavioral Economics, Psychology, and Neuroeconomics to Maximize Sales - <AUTHOR> http://www.shopify.com/blog/6563013-using-behavioral-economics-psychology-and-neuroeconomics-to-maximize-sales

<comment><USER2> If folk found this interesting I'd recommend they get hold of a copy of "Neuro Web Design: What Makes Them Click?" by Susan M. Weinschenk. It's not the most academic of books and a quick read (about 150 pages or so) - but it gives a bunch of high-level pointers to stuff that you can google around and dig into if you like.

<comment><USER3> Yeah - I've read that. EXCELLENT book. You can get it here... [http://www.amazon.com/Neuro-Web-Design-Makes- Click/dp/032160...](http://www.amazon.com/Neuro-Web-Design-Makes- Click/dp/0321603605) (No I didn't put an Amazon affiliate code at the end) ;)

<comment><USER4> Why? You don't like making free money?

<comment><USER3> Who doesn't like free money? I just didn't want to come across like that was the only reason I was posting the link.

</comment></comment></comment></comment><comment><USER4> My favorite behavioral economist is Dan Ariely - his TED talk "Are we in control of our decisions" is really valuable to entrepreneurs. Link here: [http://www.ted.com/talks/dan_ariely_asks_are_we_in_control_o...](http://www.ted.com/talks/dan_ariely_asks_are_we_in_control_of_our_own_decisions.html)

<comment><USER5> There's also a good book called Subliminal that discusses the neuroscience of how our subconcious brain make decisions that we often believe we made ourselves.

[http://www.amazon.com/Subliminal-Your-Unconscious-Rules- Beha...](http://www.amazon.com/Subliminal-Your-Unconscious-Rules- Behavior/dp/0307378217/)

</comment></comment><comment><USER6> Nice article ! One comment : on the "Selling Time Over Money" part, it seems to me that some business manage to do the opposite. Take Ikea, for instance. Typically you buy some furniture there, hoping to spend little money in exchange of giving up your sunday afternoon precious time. If you take into account the time spent assembling the furniture, with a reasonable hourly rate, some furnitures there are not so cheap anymore.

The Ikea business implies that sometimes we prefer money over time.

<comment><USER3> That's a really good point, and I guess IKEA often uses their low prices in their advertising. Wal-Mart does the same.

</comment></comment><comment><USER7> I don't normally just make blanket comments for articles, but this article is spot on. Can't add much more to the conversation, other then, READ THIS.

</comment><comment><USER8> These are so primitive and obvious manipulations, that most of target customers already evolved (learned by experience) to ignore them.

<comment><USER9> Got a source on that? My experience _and_ the research disagree, these take advantage of lower level cognitive biases that are prevalent (or maybe universal) in human beings.

<comment><USER8> Lots of people have even a habit of identifying such tricks. Others, like me, have an automated tendency to map them to the list of cognitive biases from Wikipedia - <http://en.wikipedia.org/wiki/List_of_cognitive_biases> \- the thing that deserves to be printed and framed.

<comment><USER9> I certainly have that same tendency, and have fun playing the "name that bias" game.

But we are both in a tiny minority and are still influenced by those biases even when we recognize them. I would argue we would be less influenced when we recognize them but that's conjecture on my part.</comment></comment></comment></comment>


Cosmography of the Local Void: 3D depiction of galactic density data - <AUTHOR> https://player.vimeo.com/video/326346346 <comment><AUTHOR> Here's the link to the original paper, which focuses on mapping a vast empty region of the universe right next to our galaxy:

[https://arxiv.org/abs/1905.08329](https://arxiv.org/abs/1905.08329)

The video is a great example of how to present complex volumetric data, and probably of interest to the data scientists on HN.</comment>


Ask YC: Working around Cross-site scripting Restriction - <AUTHOR>

We have a browser and another iframe that loads within it.  We want to capture information within the iframe but are unable to do so because of cross-site scripting.<p>How do we workaround these issues to capture data from the iframe such as URLs and images? <comment><USER2> Wow, could you imagine the security implications if this was possible? Put up an invisible IFRAME that links to a major credit card's account page, scrape the account number, and hope that lots of people are logged in. Or set the IFRAME to GMail, scrape the e-mail links, and read each one to look for passwords and confidential info.

Assume it's not possible, because if it is, the web has a massive security problem.

(If you control both ends of the IFRAME, it _is_ possible to pass small amounts of data back, but I think the exact technique used falls under the confidential information of one of the startups I've worked with.)

</comment><comment><AUTHOR> Nostrademons, when you mention "control both ends of the IFRAME" are you referring to controlling the severs on both ends of the iframe?

<comment><USER2> Yeah. If the page source for both the parent frame and the iframe is generated by (or can be changed by) you, it's possible to pass small amounts of information between them (even without using cookies or server-side communication). But I can't go into details about how, because it's company- confidential to one of the places I've worked.

<comment><AUTHOR> got it. so you do not see any way possible of doing this without controlling both sources of the iframe? understand the security implications, but there's got to be some site that does this for other purposes or some way to work around...

<comment><USER2> If there is, I'd expect it to be fixed as soon as someone does it, which'd break your architecture. It really is a potentially gaping security hole, and it's not wise to depend on security holes for your application's core functionality.

</comment></comment></comment></comment><comment><USER3> do you have to use javascript and an iframe for this? splash in something like php and you can scrape the information you require.

</comment><comment><USER4> You're describing a broken solution to a problem instead of the problem itself.

<comment><AUTHOR> please expand... what's the problem itself?</comment></comment>


Why Software Development Estimations Are Regularly Off - <AUTHOR> http://diegobasch.com/why-software-development-estimations-are-regu

<comment><USER3> The OP is correct if you do not have clearly defined goals for the project, and it is a field that you have not really worked in before. This is probably true of some start-ups.

However, if you are working for an engineering company, often you have projects that were similar which can provide a guideline for the scope of the software or software modification that you are undertaking.

I would posit that for the majority of software projects, the invention hypothesis cannot be true, because you are not really inventing anything new.

You are more likely replacing something that is done manually or done via a hideous and error prone excel spreadsheet machinations.

So my complimentary hypothesis is that estimating the budget for a software project is a social issue.

Example: My manager and I come up with some really cool feature that will let us market our product to new people. My manager asks me for a time estimate. He says:

>How long do you think this project would take for you to do?

Basically, it is a simple question that is also completely overloaded with little details, philosophical questions, and other minutia.

I can give an estimate of how long it will take for _me_ to get this project done. But how long a project will take _me_ is a derivative measurement. It is units of software engineering multiplied by my units of software completion rate. What we really want is units of software engineering work. This does not exist. You can't invoice for 10,000 ml of software engineering.

The punchline for this is that my rate of completion will be different from Steve or Charlie's and we don't have the rate or the units, just the aggregate for any given project. And it seems to be that the tendency is to go to your best programmer to get an hours estimate, rather than your mediocre programmer, regardless of who will be working on the particular project (you probably don't know who will be working on it when you are figuring out financials for a project that is 6-10 months off).

There is no standardized software engineering test that gives you a baseline for probable programmer efficiency/ability so that you can adjust the budget of the project accordingly.

There are also questions about 'what is done', interruptions from other projects that you have going on simultaneously, interpretation of various details in your spec.

And there is other bureaucratic stuff. I've had it where I was budgeted for a few months and had a delivery date representing that, and I hadn't received the relevant input documents that I needed to complete the project 2 months into the timetable.

Or the other version, you budget for a few months and some know-nothing pushes back and tells you do not need that much time (or really that his financials will look better if you finish it this quarter rather than next).

There are certain unsolved problems in computer science that you may encounter. When asked to solve them as part of my day job, I prefer to gracefully decline and offer a solution that I know has a chance of working and being implemented in a reasonable amount of time (by doing some research beforehand and figuring out what is reasonable within current technology/knowledge and what is pipe-dream/'interesting research' material).

There may be things that you do not yet fully understand when working on a project. But it is possible to estimate how long it will take you to learn those things. It is very difficult to estimate the complications of many of the social factors. If stupid steve is working on the project, instead of me, it might never get completed. If a jackass up the chain of command cuts my budget halfway through, i can't predict that. If I get pulled off onto an emergency project, who knows what will happen. I think this is the real reason why startups and small workgroups do so much better at software. By reducing the number of people involved, you reduce the chaos factor and the amount of damage control you have to do due to someone monkeying with your project when they really shouldn't be.

</comment><comment><USER4> When someone asks me for an estimate I like to pose this question: You just realized that you lost your keys. How long will it take you to find them? You've lost your keys before so you should be able to estimate how long it will take, right?

Well, maybe. Probably you can retrace your steps and figure out where you set them down while you were on the phone, or maybe they fell into the couch. There is also a possibility that it is going to take you a long time to find those keys.

The software estimate often depends on environments being available, other people finishing the piece you interact with on time and working the way that you expected, and you may have tricky defects that you really can't estimate how long it will take to fix them or how many there will be.

A clear specification is only one piece of the puzzle. To switch metaphors, pretend it is 1812 and try to give an estimate of how long it will take to get from Chicago to San Francisco. Yes, you have a map with routes, but there is also weather, broken wagon wheels, dysentery, bandits, you name it. (just ask the Donner party). Let's just estimate it at 90 days and probably we'll lose some people along the way and pick up a few more.

At best I try to give the suitcase estimate: I can estimate that you will need one suitcase for a weekend trip, you most likely will not need two.

</comment><comment><USER5> This guy is wrong, and this is an issue of correlation vs. causation. Just because software tends to be something new, and software estimates tend to be off, doesn't mean that things that are new cause estimates to be off.

If you give a software developer a very clear specifications of what they need to do, and don't change those specifications, it's very likely that they'll give an accurate estimate and get it done in time. Probably even faster, because most software developers pad their estimates somewhat.

Also, it is possible to "invent new things" that have very clear specifications that don't change much. It might not be very common, but it _does happen_. Especially for relatively simple things.

Two things actually cause inaccurate estimates:

1) a lack of clear specifications of what the project is going to be

2) a change in the specifications

In many cases, the expense of providing clear specifications is not justified. This is normally the case when companies develop their own products, where they would implement them regardless of how long it would take and bear the expenses themselves.

When software development services are provided for other parties, there is normally a "requirements gathering" phase where the developer tries to get a very comprehensive specification for the project. Normally, this specification and its estimates will be very accurate. However, after realizing their mistaken assumptions in the requirements gathering phase, the client tends to want something different from what they wanted before - it is these _changes of requirements_ that cause initial project estimates to be off.

In the end, no estimate has to be off if we provide clear specifications - <USER2> just have to accept that requirements/specifications are very likely to change during the development of any product.

<comment><USER6> You've just made the problem one of specification. How do you make clear specifications for something you are in the process of inventing? It's not possible. You'll try to invent it in your head. Early on in implementation what's in your head won't match reality, and it diverges ever more.

<comment><USER5> No, you cannot say that every project is impossible to provide clear specifications for. Many projects are simple enough that you _can_ provide accurate estimates for them. Let me give you a trivial example:

I want a program that adds three numbers together and appends the string "asdf1234" to the result.

1) I can provide a very clear specification for this. 2) I invented something new. 3) I can provide an accurate estimate for how long it will take to develop.

It's not very useful. But there are many "mini-projects" in organizations that are of small enough scale that you can provide accurate estimates and specifications for them. A more complicated, but "useful" example, would be to implement a logging server according to a REST API. The specifications are clear, the project is simple, and the estimate will be very accurate unless the software developer is not very experienced.

<comment><USER7> If you write your very clear specification down in a formal language, you can simply execute it:

        print(($ARGV[0] + $ARGV[1] + $ARGV[2]) . "asdf1234");

The reason you can provide an accurate estimate for how much longer it will take to develop is that, by providing that clear specification, _you've already done the development_. All that remains is the trivial step of writing it down and invoking a compiler or interpreter.

> A more complicated, but "useful" example, would be to implement a logging > server according to a REST API.

If the REST API in question is well-defined, it's because there's already an implementation of it. Just install that implementation and use it, and you'll be done in half an hour. Are you not sure if you can use the existing implementation? Well, then your project might take 45 minutes, or it might take two weeks. Suddenly you have two orders of magnitude of uncertainty in your estimate. Maybe you _know_ you can't just use the existing implementation; how much of it can you reuse? Is there another piece of software out there that implements the same API? You may be able to get it to work for you in an hour and a half. Or you may be better off writing stuff from scratch.

Then, either with the off-the-shelf software or the software you wrote from scratch, you may encounter a killer performance bug — which could take you two weeks to resolve. Or you may not.

Maybe you think only the not-very-experienced software developer would consider using off-the-shelf software, or encounter a critical performance bug that could take weeks of work to resolve. If that's what you think, I suspect you're the one who's not very experienced!

<comment><USER8> _If you write your very clear specification down in a formal language, you can simply execute it..._

This isn't necessarily true. Two examples:

        for x, y in sorted(lst), assert(x < y => index(x, sorted(lst)) < index(y, sorted(lst)) )

        assert( sqrt(x) * sqrt(x) == x )

In more practical terms, at my company we've hired someone to build scrapers for us. They have a fixed interface - scraper.getBrand, scraper.getPrice, etc. The clear specification is that on 100 examples, the scraper needs to agree with humans viewing the webpage (i.e., scraper.getPrice(page) == whatever a human viewing the page says it is).

<comment><USER7> Insightful. A few comments:

1\. It's true that those specifications are clear (although you might also want to specify that multiset(sorted(lst)) == multiset(lst)), and sqrt should be allowed an error of half an ulp and perhaps required to be nonnegative and restricted in its domain to nonnegative numbers.) But they are not necessarily specifications that are easy to estimate, either. (I should have said "your very clear, easy-to-estimate specification", since writing specifications like the ones you have above is clearly not doing the development work.)

2\. It is at least theoretically possible to automate the finding of programs that satisfy specifications like your two examples above. Given the knowledge that λx.x*x is strictly monotonic on nonnegative numbers, for example, you can apply a general binary chop routine to compute sqrt(x) in O(log numberofbits) time.

3\. For your realistic example, it seems very likely that you could write software to build the scrapers rather than hiring a person. [http://lists.canonical.org/pipermail/kragen- hacks/2004-Janua...](http://lists.canonical.org/pipermail/kragen- hacks/2004-January/000375.html) represents a prototype solution to this problem from 2004, but without the knowledge of AI algorithms I have now, and of course with much less computational power than is available today.

</comment></comment></comment></comment></comment></comment><comment><USER9> I believe that it is erroneous to believe that this has anything to do with software. Estimates in most or all fields are off because humans are bad at predicting timelines. This is referred to as the planning fallacy: <http://en.wikipedia.org/wiki/Planning_fallacy>

I heartily recommend reading the studies associated with the Wikipedia page, as they demonstrate that this applies to more fields than just software. I will agree that the data does appear to support the hypothesis that the less repetitive the task, the more likely it is to fall subject to the planning fallacy.

<comment><USER10> That's appealing, but I'm not sure it is correct. My father spent his career designing power plants. His company had an estimation group tasked with estimating costs and schedules before they ever bid on a job. We're talking projects that could easily run over a decade and cost hundreds of millions of dollars. They did an internal study to see how well the estimators did compared to reality. When management didn't lean on them to shave down an estimate, they were really amazingly accurate.

Now, we're talking about a dedicated group of people who aren't going to do the work themselves and who do nothing but estimation, but still....

<comment><USER11> But the power plant was not of a different kind each time. Software is missing the sort of standardisation and components that made that doable. Why not is another question....

</comment></comment></comment><comment><USER12> In my experience, it's usually way off because the people in charge change the specifications at the drop of a hat. Every company I've worked for has done this. No matter how much you plan and try to stick to that plan, things always change. Many times, even with these changes, you are expected to get the project done in the original time-frame.

At my last company, they needed an e-commerce site done. I had the coding finished in roughly 3 months and we were just waiting on the design. We went through 3 artists and a design by committee (the boss rounded up everyone in the company once a week to give their feedback). 2 entire finished designs were also scrapped. In addition to all of this, the boss would change his opinion of it on a daily basis (I think it depended on his mood).

A year into the project, they questioned me as to why the project wasn't finished. This was after I had been telling them for months why we couldn't run a project this way. A year after this, the project was finished. What infuriates me is that a company like this is still making money. Every aspect of the company was run like the above scenario. Over time, every good person they ever had left in frustration (including me).

</comment><comment><USER13> Here's how I like to think of it. Consider the project as a tree of goals with subgoals. The root goal is the whole project; it can be broken down into components which are the subgoals; each of those has sub-components, all the way down to the individual lines of code.

The fundamental problem is that until you're actually well into the project, you can only see down a few levels; but the amount of effort that is going to be required is a function of the length of the _fringe_ of the tree, which you can't see, at least not very clearly, until you get there.

</comment><comment><USER14> Honestly I thought it was quite prescient when this guy wrote:

"Hey inventor, I need a drone that will pick up mice (but not other animals), locate my ex-girlfriend and drop them on her head. Give me a budget and a time estimate."

For a good amount of software (excluding boilerplate, plumbing e-commerce-type software) - this is what it's all about. I had a long argument with an uncle of mine who's getting into the field of software project management. I get the sense that among the project management types, there's a sense that software can be constructed by building gantt charts, costing spreadsheets, and "staff months". They claim computer science degrees "don't teach the practical stuff" and it's as if they are completely unaware that there lurk hard problems.

</comment><comment><USER15> All this is true, and there's another statistically-rooted problem that pertains even to mundane "enterprise" projects where there's little new invention and where reliable time estimates should be possible.

Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour.

How long is this string of tasks going to take? Summing the _median_ time expectancy, we get a sum 110 minutes, because the median time for a task is 5.5 minutes. The _actual_ expected time to completion is 222 minutes, with 5+ hours not being unreasonable if one rolls a lot of 9's and 10's.

This is an obvious example where summing the median expected time for the tasks is ridiculous, but it's exactly what people do when they compute time estimates, even though the reality on the field is that the time-cost distribution has a lot more weight on the right. (That is, it's more common for a "6-month" project to take 8 months than 4. In statistics-wonk terms, the distribution is "log-normal".)

Software estimates are generally computed (implicitly) by summing the good- case (25th to 50th percentile) times-to-completion, assuming perfect parallelism with no communication overhead, and with a tendency for unexpected tasks, undocumented responsibilities, and bugs to be overlooked outright.

<comment><USER16> _Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour._

That is a beautifully accurate description of modern software development. I hope you get quoted.

<comment><USER17> It mirrors my experience as well. For about 6 months, management wanted us to time against user story. At the time, we used scale from 1 to 5. The concern was estimates weren't linear and for planning, a 5 one point story did not equal 1 five point story.

Then, we ran the numbers. This was our graph for median time for a swag:

      |        *
      |      *
      |    *
      |  *
      |*
      |</comment></comment></comment><comment>---
       1 2 3 4 5

The ah-ha for management was the standard deviation. The more points estimated, there was greater and certain variance.

We went to fib, because it felt more natural with the effort. The end result is if a story is estimated on the end, everyone knows there isn't enough information, it's a black hole or it should be broken down.

</comment><comment><USER18> To me the problem of estimation is fairly straightforward. Mike Cohn's work in AEAP is thorough and worthwhile and probably still the best resource for solving the problem of estimation with any regularity.

[http://www.amazon.com/Agile-Estimating-Planning-Mike- Cohn/dp...](http://www.amazon.com/Agile-Estimating-Planning-Mike- Cohn/dp/0131479415)

But the simple version of the problem, in my experience, is related to the 80/20 rule. No matter how many times a developer goes through the process of estimation -> development -> slippage, whether on a big scope or small, we will inevitably estimate the very next project as if only the clean 80% exists and the 20% will magically disappear _this time_.

Let's back up. In my experience the 80/20 rule (or Pareto Principle) applied to software estimation means that you will spend 80% of your time writing 20% of your features. Usually this has to do with various technical blocks, edge cases, framework incompatibilities -- the list goes on and varies wildly from one feature or application to the next.

You will spend 20% of your time working on 80% of the feature(s). This is the stuff you have done before: basic CRUD, ORM-fu, REST actions -- these are the clean, easily understood software tasks that you see right in front of you as the happy yellow brick road to feature completion.

And no matter how many times we wash-rinse-and-repeat this cycle, the next time a PM or colleague asks us "how long this will take," we will stare at that beautiful, pristine part of the path that we understand and know and have done before, and conveniently elide the fact that our development process has never been that clean and there is a nasty 20% (what? my code won't connect to the staging server because of some weird certificate problem? what do you mean my gems are incompatible? I can't get 'make' to build this gcc lib!! IE is doing what?? Why do our servers treat HTTP basic auth in such a non-standard way?) just waiting to jump out, muss your hair, laugh in your face and dance like a hyperactive monkey all over your keyboard.

</comment><comment><USER19> Several reasons. Managers want to believe that programming is like installing a kitchen. It should have a clear start, middle, end, and a reasonable estimate of time and cost that could almost be written in a contract. Devs don't want to admit they never installed a kitchen before and need to research the topic first, because if they do the job will be given to someone else who is willing to say they install kitchens all day long.

Oh yeah, managers also believe that changing the counter top from marble to granite in the middle of the project should be free, because, hey, it's software.

</comment><comment><USER20> The article states the problem quite well, the people who want software solutions really don't understand what software is. I find that users' and managers' mental model of software is all too often 'magic box'.

From Frequently Forgotten Fundamental Facts about Software Engineering: [http://www.computer.org/portal/web/buildyourcareer/fa035?utm...](http://www.computer.org/portal/web/buildyourcareer/fa035?utm_source=bronto&utm_medium=email&utm_term=Forgotten+Facts+About+Software+Engineering&utm_content=andrew%40badera.us&utm_campaign=BYC- Issue+38-December+3)

RD1. One of the two most common causes of runaway projects is unstable requirements. (For the other, see ES1.)

ES1. One of the two most common causes of runaway projects is optimistic estimation. (For the other, see RD1.)

ES2. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that this occurs before the requirements phase and thus before the problem is understood. Estimation therefore usually occurs at the wrong time.

ES3. Most software estimates are made, according to several researchers, by either upper management or marketing, not by the people who will build the software or by their managers. Therefore, the wrong people are doing estimation.

Glass has a book that goes into more depth on these points and has numerous citations (Facts and Fallacies of Software Engineering, Robert L Glass) and covers a wonderful variety of other topics.

<comment><USER21> I'm not sure about ES3, its just my own experience but I've worked for some companies with rather broken processes and they would still involve the engineering team in giving estimates, sure there is pressure to give a lower estimate but I don't see how a company could function by having non- engineering people give firm estimates

<comment><USER20> Have these been software companies? In software companies, software is the product. In other companies software is an expense. It makes a difference in how it is managed.

Some companies certainly are behaving better software wise. I recommend his book, he goes into a longer discussion of the details, has citations, and includes counter points. It's also possible that this has shifted since the book was written (2002 I believe), but I suspect it's more that you've been at companies who managed to get this part right.

<comment><USER21> Yes, they are software companies where its their core product.. basically IMO they had some horrible, broken processes but at least they did rely on engineering for estimates of time.

</comment></comment></comment></comment><comment><USER22> It's interesting that nobody has yet mentioned deliberate under estimating so that the project sounds like it will come in on budget. Basically, for political reasons.

Every project I've ever worked on in the AAA games industry was deliberately underestimated so the publisher is happy with budget going in, with the added benefit that you can put pressure on the programmers because they are behind schedule from day one.

<comment><USER23> > with the added benefit that you can put pressure on the programmers because > they are behind schedule from day one.

Are there still people who believe this works? I have been on teams who sometimes go into the super-effective mode where the team seems to work as one unstoppable goal-reaching mind. Yup, but this _never_ happens due to external pressure, especially one perceived as bogus from the start.

"So you say we need to work "smarter not harder" because we are on "aggressive" schedule? Yeah, right. Can you please also hang some motivational posters around so we can watch them while we utilize the synergy to maximize shareholder value?"

</comment></comment><comment><USER24> Diego, I don't disagree with your post...there is no reason that someone hiking from SF to LA shouldn't do their homework, be realistic, be prepared, push back on their boss who wants them to do it faster, and do it better the second time.

But I'm not covering how the world should work. I'm covering how it does work. The reason this article resonates is precisely because we all see the same mistakes being made again and again.

I also agree that many software projects are more analogous to Columbus's trip to the new world...a tough trip even if you knew for sure there was a new world and where it was, almost impossible if you don't.

But realistically most people are working on web sites, enterprise apps, mobile apps, where there is enough prior experience that we should be able to make reasonable estimates. We aren't curing cancer here.

Yes the same mistakes get made again and again...

</comment><comment><USER25> I think as software developers we are collectively ignorant about the estimation accuracy possible in other engineering disciplines. Every time we talk about estimating software we point out it isn't analogous to building a bridge or a car and we try to reason about why that is.

Both of my parents are engineers in several different areas (road, civil, and HVAC engineering). Through talking to them I realized that their projects and estimates are always off and by similar margins as the softare projects I've been involved in.

I'm not sure why that is, but people just seem to generally suck at estimating engineering activities. With software I think the problem is more pronounced because the engineering phase so dominates the cost of construction. If designing a bridge takes longer and costs more than what you expected it really isn't such a big deal because actually building it is much more costly and delay-prone. The people financing the project won't have a hard time absorbing the cost associated with incorrect engineering estimates. Quite clearly the situation when it comes to software is different.

</comment><comment><USER26> Because you don't know what you don't know. That's why.

</comment><comment><USER27> I think michaelochurch's comment <http://news.ycombinator.com/item?id=3522910> is more accurate than the article, but I think the type of problem does have quite a lot to do with it.

If the problem domain is defined by physics or physical function, I think most time estimates are going to be a lot closer. You might still get outliers, but most experienced people in the domain will probably give you decent estimates.

When you get human's preferences, design, business processes, and regulations into the mix, estimates can be wildly off. I once thought a defined business process would yield a decent software specification, but that never seemed to work out since the "flexibility" argument seems to creep in. Never mind multi- national companies that have a defined business process that is actually executed totally differently at every location.

</comment><comment><USER28> Most enterprise software is based around forms, validation and business rules. Where things start to become unstuck (look for "itfailures" on Delicious) are:

1\. The languages and tools change - but are often immature for the task, which means a lot of reinvention and re-workarounds

2\. Users ask for nice-to-haves but are often difficult to implement as it is a once-off operation - federated sign on in frameworks that do not support it natively

3\. The specification problem - the more people you have involved, more people are required to understand the problem domain in order to translate into code. The problem is particularly bad when rolling out new payroll systems in Government/heavily unionized industries, as there are just a lot of rules which can be very difficult to implement.

4\. It is still ridiculously difficult to test enterprise software across the full stack.

</comment><comment><USER7> We should call this Basch's Law: "Software projects worth doing are not repetitions of previous projects."

The software tasks that are easy to estimate are the same ones that you already should have automated, maybe with a DSL. However, automating them is hard to estimate.

</comment><comment><USER29> Not always the case, but sometimes Godel Incompleteness gets in the way, and other times, the problem is inadvertently made NP-hard, and other times, it's like a lambda calculus term, you can't tell if a term has a normal form without going ahead and reducing it.

You can think of this by imagining that you're asked to solve a Rubik's cube. You can look at 5 of the sides, but not touch it. Tell them how many moves it will take to solve. The theoretical maximum is 20, I believe. In this case, and many others in programming, you can't know how long it will take to get something done. The fastest way to find out how long it will take to finish a system, is to do the work and finish it.

</comment><comment><USER30> If software development is inventing, why aren't software patents OK?

I'm in part playing devil's advocate because I don't agree with software patents. But the problem with us (technical people) not communicating consistently is that if we can't get our story straight how do we expect others to understand what we say?

In the software patent arguments we stay firmly away from the word invention, wary of how it will be used against us. Yet here, for the sake of arguing about estimatation, we seek to embrace the word invention?

I'm not sure we can have it both ways. We've got to collectively get our story straight.

</comment><comment><USER31> I like this analogy, and it applies to a number of projects I've been involved with. On the other hand, at work I also encounter change requests that are basically repeats of existing projects with slight modifications, and/or changes to well understood subsystems such that I can pretty much nail the estimate. Not surprisingly, these are also relatively simple changes.

It's the whole "known unknowns" vs. "unknown unknowns" thing, and I think it's useful to distinguish between the two.

</comment><comment><USER32> If you want to really dig into it, and learn some approaches to getting better at it, I suggest you read Software Estimation: Demystifying the Black Art, by Steve McConnell.

</comment><comment><USER33> There is a rule of thumb that has me served well in the past. Whenever I try to estimate the time for a project I literally program it in my head. This gives me a feel how long it will take for a certain module.

Then I double the result.

It's always closer to the amount of time I really need in the end. For some reason I'm always off by half. And I have heard of others with the same problem using this approach.

</comment><comment><USER34> I've always found estimating hours for a project to be somewhat difficult, especially when the client wants a concrete number right at the beginning for the entire project. I usually roughly estimate how long I think it will take, and then raise that by 1/3 to account for changes in specification by the client along the way.

<comment><USER35> I have a/b tested this approach and have come to the conclusion that it is a little larger. I usually increase my estimates between 3/4 to double.

</comment></comment><comment><USER36> Estimations are regulary off cause they are just estimations, not futurology. And even if they are accurate is hard to know if that's due to a good estimate or because of Parkinson's law.

I'd like to hear some thoughts on how to improve those estimations rather that explaining why it is hard as Brooks did on MMM.

</comment><comment><USER37> Anyone else unable to access the article? Could the content provider be so kind as to provide the content here in the thread, or get the page back up again?

</comment><comment><USER38> There is a term which describes that mode of thinking, "Not Invented Here Syndrome."

<comment><AUTHOR> Not sure if you refer to the mode of thinking on my post, or the thinking that causes the "reinvention of the bridge."

Not Invented Here would be rewriting bridge4j because you feel like it. A good software engineer does research, and invents what needs to be invented because it doesn't exist. If it exists and it's freely available, you use it and write glue code.

The reason web startups can pop up so quickly is because we all do this. IndexTank was an example, the list of open-source technologies we used is very long. Big companies on the other hand are prone to unnecessarily rewriting stuff, sometimes just to keep developers entertained in between meaningful projects.

<comment><USER21> Yes, exactly, one issue that I've seen, at least in the Java world, is the original web application they have is so out of date and obsolete (but its still making money) that you literally have to bend over backwards to not mess things up which means severe restrictions on using new libraries, etc and then this leads to having to do stupid things like forcing people to write their own CSV parser because its too much hassle to put in a library for it and make sure it doesn't break anything.</comment></comment></comment>


Microsoft loses ground in mobile as Google Android continues to soar - <AUTHOR> http://www.geekwire.com/2011/microsoft-loses-mobile-market-share-google-android-continues-soar

<comment><USER2> _This_ is what people mean when they talk about the decline of Microsoft - rather than disappearing overnight, that they are failing to establish themselves in areas the computing market is heading towards.

And this is version SEVEN of their mobile OS.

</comment><comment><USER3> Did WP7 ever have ground in the mobile market?</comment>


No-man's land on the road to bootstrapping a start-up - <AUTHOR> http://www.thisux.com/2012/06/25/watch-out-for-no-mans-land-on-the-road-to-bootstrapping-a-start-up/

<comment><USER2> I've never understood the math behind this attitude that bootstrapping a profitable business needs to take up 100% percent of your time, to the exclusion of sleep, friends, and life in general. It just doesn't need to be that way.

Example: During the first year of bootstrapping Twiddla, I lived quite comfortably in a nice little apartment overlooking Plaza del Castillo in Pamplona, working the days I was inspired to and rock climbing the days I wasn't. Money was going out the door (though not particularly fast at Spanish real estate & wine prices), but nowhere near fast enough to sweat about it at all.

At one point, I downed tools and did 3 months of consulting (with the aforementioned climbing breaks mixed in and plenty of days back on the real project when inspiration struck) to sock away enough to bootstrap the next year. No 60 hour weeks. No broken marriages. Just a really fun time spent writing code and building something that would eventually start paying the rent.

Consulting pays _very well_. Like _embarrassingly_ well. If what you're doing doesn't pay enough to sock away 3 month's runway for every month you do it, you're either not charging enough or are living way too large. Bootstrapping from consulting income is absolutely doable. No need to pull out pie charts to make it work. It just does.

</comment><comment><USER3> I am in a similar situation, but attacked it from a different direction. We are almost ramen profitable, and built our company (<http://codiqa.com/>) almost exclusively while working 9-5 jobs. We'd work 9-5 then come home and work four hours a night, sometimes more. We did that for several months before we launched in February of this year. I don't sacrifice personal time, and we are still growing. Granted, we are young and have very few obligations, but it works. We have never taken on client work, but it's definitely an option should we need to.

The point is, I don't agree you have to sacrifice personal time to be successful. I think it's very healthy to have things outside of work, if only because it makes you do the work that's most important when you _are_ working.

That being said, I probably work way more than I realize, because it's not really work to me.

<comment><USER4> Absolutely. We started out in very similar fashion, working on our product on the side and only quitting our day jobs when we absolutely had to to progress further.

For the first two months we regularly put in at least 12 hours a day seven days a week. We progressed, but towards the end of it we were barely recognizable. The amount of stress it put on us, our family, and our friends was immense. I'd drag myself to a bar to see friends and I'd spend most of the time zoning out, thinking about what I needed to work on as soon as I was back at home.

We've since forced ourselves to adopt a more structured approach, and factored in time to go fishing, play snooker, sing karaoke, or just relax. We're still working like crazy, but with a little bit of balance it no longer feels like the drudgery it had become before.

</comment></comment><comment><USER5> I must admit my big difficultly when trying to get this balance right is saying no to client work in order to have time to develop the product. It can be incredibly hard to say no to a few $ when you have no guaranteed income.

<comment><USER6> We don't have a problem saying no to new clients. Our problem tends to be dealing with expanding needs from existing clients.

<comment><USER5> Agreed! Saying no to a new client who contacts you is not too difficult (although depending on circumstances a pile of bank notes being waved at you can influence the decision...) - but it is much harder, at least I find, to say no to existing clients for fear of damaging the relationship.

</comment></comment></comment><comment><USER7> I wonder if you can do a bit more for clients and take the money and use it to hire more people doing outsourced work.

If you can pay for 2-3 hours of outsourced work for every hour of client work, doesn't that effectively 'buy' more time?

<comment><USER6> I guess it would depend on the type of client services you do. We do specialized product design and development, and that's not something you can easily outsource.

<comment><USER8> I think the idea is to replace other types of work with fewer hours of client work. Eg you can get some big wins by hiring a personal assistant and cleaning service to handle stuff on the "fixed personal commitments side", outsource some of the product work, etc.

</comment></comment></comment><comment><AUTHOR> Interesting piece from someone who has built, shipped and had success. Personally we're just climbing out of what he described as no-man's land... A situation that we seemed to slowly slip into.</comment>


Why Don't Companies Want You to Work from Home? - <AUTHOR> http://seanoneill.me/why-dont-companies-want-you-to-work-from-home/ <comment><USER2> This topic is covered all over this site with numerous reasons. If people wan't a work from home job and theirs currently won't support it, they have every right to look for a new job. Work from home doesn't work for every employee, and it's definitely not perfect for every company.</comment>


Take a photo of yourself every time you commit - <AUTHOR> https://coderwall.com/p/xlatfq/take-a-photo-of-yourself-every-time-you-commit <comment><USER2> but why?</comment>


Put Your Face in It: How Gaming Helped Me Understand My Dog - <AUTHOR> https://www.npr.org/sections/monkeysee/2018/07/18/629760717/put-your-face-in-it-how-gaming-helped-me-understand-my-dog <comment><USER2> There's something to be said for creating face putting safe experiences that don't feel restrictive. Stardew Valley is designed so that worst that experimenting can do is waste time. There are no items or challenges that destroy all of your hard work if mishandled. Similarly, dog owners make the world safe for their dogs, stopping the dog from sticking its face in a porcupine or from eating rancid roadkill (although how much of this hidden safety net is designed for the dog's benefit and how much to suite our human tastes is debatable). I think what makes Stardew Valley enjoyable for players and what makes pet life enjoyable for dogs is that, in addition to making face putting safe, the restrictions never feel smothering. Players and dogs still feel that they have agency, and for the most part they do.

Most games and software is not designed like this. Either they assume that users know what they are doing and will happily let them kill their characters or corrupt their files—even if the user had no clue that this is what they were really telling program to do—or they restrict the user so much that the safety net becomes obvious.

<comment><USER3> This is an interesting thought to me: what if human life were designed this way more broadly?

<comment><USER2> School can create these sort of spaces, at least to a degree. University for example is many people's first taste of independence, but that independence is supported by some fairly extensive safety nets (financial, social, educational, etc.) that should prevent screwing up too badly. These safety nets are certainly not perfect, and putting your face in bottle can still end quite poorly.

I think one way to create a face putting safe community (physical or virtual) is to allow anyone to safely propose actions but only let these actions effect the world if other community members agree. PR based workflows sort of fit this model. As a new programmer, I should be able to safely submit garbage PRs while learning without actually hurting anyone, and if my code does get merged and it breaks something then it's the community that failed. There are roleplaying communities that also work like this: users can only state their actions and not the effect of their actions, which are determined by the people effected. Of course learning and history also has to be considered. That first garbage PR is understandable, but if I keep submitting garbage PRs without learning then there's something wrong.

</comment></comment></comment><comment><USER4> Go read "Animal Happiness" by Vicki Hearne. Don't project your mindset into animals. They have their own mindsets, and they are not humans.

As a horse owner, I have to get this. You have to have a reasonable understanding of horse minds to deal with half-ton animals at close range. "Talking with Horses", by Henry Blake, is perhaps the best book on that.

<comment><USER5> I feel like dogs have co-evolved with humans to such a high degree that they are much more approachable with an anthropomorphic perspective than equines. They, for example, understand human facial expressions, pointing, and words, among other things. There's a massive amount of research done on how well dogs understand humans - maybe the reverse is also true.

<comment><USER6> I don't know, I love dogs but I doubt they are doing that much research on how well we understand them.

<comment><USER7> I agree I've never seen my dog do any research

<comment><USER3> Save for sticking their face into things, which is a form of research if you think about it...

</comment></comment></comment></comment></comment><comment><USER8> Text-only version: [https://text.npr.org/s.php?sid=629760717](https://text.npr.org/s.php?sid=629760717)

</comment><comment><USER9> I want to live my life like this.</comment>


Shocktrooper: mass server patching for shellshock - <AUTHOR> https://github.com/EvanK/shocktrooper

<comment><USER2> I don't really understand the point of this. Aren't there already simple tools that take a list of server credentials and run the same command on all of them? (I could understand if it was made for fun but the FAQ says it's "out of necessity" and patching multiple distros can be a "nightmare". How? Just attempt to execute apt and yum everywhere.)

Though maybe I'm just disappointed that it doesn't log in via shellshock as I hoped from the title.

<comment><USER3> For those wondering, "What simple tools take a list of server credentials and run the same command on all of them?", Fabric is a great one: [http://www.fabfile.org/en/latest/](http://www.fabfile.org/en/latest/)

<comment><USER4> Fabric is a great suggestion! Here is a small fabfile as an example.

It's super-simple (wrote it for this answer), but should be less than 5 min if anyone need something quick.

        from fabric.api import *

        # Fabric
        #
        # Simple tool to execute commands on multiple machines.
        # Use for easier, ad-hoc changes, such as package updates.
        #
        # http://docs.fabfile.org
        #
        # Installation on OS X
        # `brew update && brew install python && pip install fabric`

        # use local ssh config
        env.use_ssh_config = True

        # Hard-coding host IPs is not ideal! There are better ways:
        # http://docs.fabfile.org/en/latest/usage/execution.html#defining-host-lists
        all_nodes = [
          '10.10.10.1',
          '10.10.10.2',
        ]

        # print uptime
        # usage: `fab uptime`
        @hosts(all_nodes)
        def uptime():
          run('uptime')

        # install package via apt
        # usage: `fab install_package:my-package-name`
        @hosts(all_nodes)
        def install_package(package):
          run('sudo apt-get update && sudo apt-get install {name}'.format(name=package))

        # check package version
        # usage: `fab package_version:my-package-name`
        @hosts(all_nodes)
        def package_version(package):
          run('dpkg -s {name} | grep Version'.format(name=package))

</comment></comment></comment><comment><USER5> Shameless plug: [https://commando.io](https://commando.io) provides a great way to run commands on groups of servers via SSH and a web interface for patching shellshock. We also store the result of stdout and stderr and who executed the commands for a complete audit trail.

See the following tweet: [https://twitter.com/alexandermensa/status/514811145887027201](https://twitter.com/alexandermensa/status/514811145887027201)

</comment><comment><USER6> I gotta say, if this is what you have to resort to for one single security advisory, I'm scared to think how the remaining ~weekly advisories are handled.

</comment><comment><USER7> ansible main -a "sudo apt-get update; apt-get install --upgrade-only bash"

<comment><USER8> That should be "\--only-upgrade", but ya, that's what I did.

</comment></comment><comment><USER9> So... instead of connecting to all my servers securely and 'yum update bash'ing I can download this script that I don't trust, configure it with all my super secret passwords and let it run riot.

</comment><comment><USER10> Neat project. ;)</comment>