Nobody Knows What They're Doing (2013) - <AUTHOR> http://prospect.org/article/nobody-knows-what-theyre-doing <comment><USER3> An obvious counter-argument to this: NSA. If someone had said 10 years ago that an organization like NSA exists, and that it is conducting electronic surveillance at the level that it currently is, they would have been laughed at as a conspiracy theorist. One can only imagine what Ezra Klein would have said to such a person.

 _" What you're saying is too improbable. No one can carry out complicated plans. All parties and groups are fractious and bumbling."_

Turns out organizations like the NSA do actually exist, and they are capable enough to carry out complicated plans in secrecy for many many years. Despite it being a non-partisan government agency staffed by government workers reporting to our elected leaders. One can only wonder what other kinds of scheming and backroom deals are being done by private organizations such as lobbyists, super-PACs and think-tanks.

<comment><USER4> > An obvious counter-argument to this: NSA. If someone had said 10 years ago > that an organization like NSA exists, and that it is conducting electronic > surveillance at the level that it currently is, they would have been laughed > at as a conspiracy theorist.

The NSA has been well known for decades; while it was initially secret (its name and existence, not just its work), its existence has been public knowledge for a long time, and its massive, widespread, and frequenrlt- politically-abused surveillance was revealed in the Church Committee hearings in 1975, and was the key impetus behind the restrictions on domestic surveillance adopted at that time in the Foreign Intelligence Surveillance Act (restrictions that were weakened by amendments in the war on terror _exactly and publicly so that_ the NSA could engage freely in widespread, massive surveillance to identify and track auspecred terrorists and their associates several steps removed.)

Anyone who was paying even a little bit of attention 10 years ago — or even _forty_ years ago — was well aware of the NSA and it's widespread surveillance.

Now, if you said this about "10 years ago" in 1977 instead of 2017, you'd have a good point.

<comment><USER5> > Anyone who was paying even a little bit of attention 10 years ago — or even > forty years ago — was well aware of the NSA and it's widespread > surveillance.

It was even a joke in the Simpson's Movie (2007).

<comment><USER6> The knowledge was not widespread, but people in the field certainly had suspicions and started getting an idea in the late 1980s, at the very latest. The EU conducted an investigation in 2000 and certainly knew what was going on pretty well when the final report [1] was presented in mid 2001. Probably not in too much detail but they certainly had an idea of the [possible] scale.

[1] [http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//...](http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+REPORT+A5-2001-0264+0+DOC+PDF+V0//EN)

</comment></comment></comment></comment><comment><USER7> That's painfully true. There have been, though, broad long-term plans that succeeded. Here are two classics:

* "Attack on American Free Enterprise System" (1971), by Lewis J. Powell.[1] This is the founding document of the modern conservative agenda. Powell later became a Supreme Court justice. He proposed heavily funded groups to push a conservative pro-big-business agenda, with the U.S. Chamber of Commerce taking the lead. This was quite successful, especially noting how politically weak big business was at the time.

* "The Overhauling of Straight America" (1987), by Marshall Kirk and Erastes Pill (pseud. of Hunter Madsen). This is the founding document of the modern gay agenda. This, too, was quite successful. It outlines a detailed program, and most of the goals listed were achieved.

[1] [http://lawdigitalcommons.bc.edu/cgi/viewcontent.cgi?article=...](http://lawdigitalcommons.bc.edu/cgi/viewcontent.cgi?article=1078&context=darter_materials) [2] [http://library.gayhomeland.org/0018/EN/EN_Overhauling_Straig...](http://library.gayhomeland.org/0018/EN/EN_Overhauling_Straight.htm)

<comment><USER8> _" The Overhauling of Straight America"_ seems to be eye-poppingly accurate on first read because one can easily trace back the past 10-20 years and identify events that fit much of what was written... However I think I'd label this one moreso prophetic than any sort of targeted plan.

By that I mean if you were to pick any behavior that is generally unacceptable to society and attempt to change the tide of public opinion, the game plan would come out looking very similar to this document, with simple substitutions for the behavior.

I say that because there is a direct Biblical reference in this article to spiritual warfare - _the shield and sword of that accursed "secular humanism"_ \- which is a dig at Paul's instructions to Christian believers on how to remain on-guard in their faith (Ephesians 6:10-17).

So the fact that the strategy in this article mimics what Christians would recognize as spiritual warfare is not really surprising... The article's "six things" are very similar to how Satan works to deceive (John 8:44) and move just about any sin from abhorrent to acceptable -- desensitizing, redefining truth, identity attacks, guilt/shaming, social pressure & ostracizing, etc.

So I've seen that playbook before, and it wasn't written in 1987.

<comment><USER7> To make something happen politically, both a plan and an organization are needed. This was the plan part. The organization was the Human Rights Campaign Fund, originally a political action committee (PAC).[1]

A plan without an organization behind it is just an essay. An organization without a plan just thrashes around. That's what happened to Occupy. They never had a coherent agenda.

[1] [http://rmc.library.cornell.edu/HRC/](http://rmc.library.cornell.edu/HRC/)

</comment></comment></comment><comment><USER9> This is a false dichotomy: either everyone is "ceaselessly, ruthlessly, effectively scheming" or "all parties and groups are fractious and bumbling"

How about the truth is somewhere in between? Some people are scheming - <USER2> some schemes do come off successfully.

There has been nothing but scheming and counter-scheming since this U.S. election - the removal of General Flynn being, according to some commentators, just the latest example: [https://www.youtube.com/watch?v=7j_ZfKmcnSk](https://www.youtube.com/watch?v=7j_ZfKmcnSk)

<comment><USER10> The article doesn't say that no one is scheming, just that what starts as a plan devolves into a mess of reaction and counter reaction. No battle plan survives contact with the enemy and all that.

Schemes are occasionally successful, but that is because the schemer either got lucky and everyone reacted the way they wanted, or because the scheme was incredibly simple.

What the article is talking about is the mythical scheming that involves correctly predicting the behavior and reactions of the opposition through multiple iterations of attack and counter attack--the hypothetical chess master who can see 5 moves ahead.

The systems we are dealing with are generally just too complex for that.

<comment><USER11> > No battle plan survives contact with the enemy

I always (as a Vet) thought this was a misnomer - it's often best described as "no battle plan survives contact with reality" \- reality being the new info you get that you didn't get or couldn't have gotten.

<comment><USER12> "Everybody has a plan until they get punched in the mouth." \-- Mike Tyson

<comment><USER13> It's also a great quote, but it's a different one. "No battle plan survives contact with the enemy" is more like you get punched as much and in a way that you didn't expect, even if you planned to get punched. Tyson's saying "When you get punched the sensation is so unexpected that your brain stops working for some time". The 'counter' to the changing environment quote is to be flexible from the beginning. The 'counter' to Tyson's situation is to train so much, that your muscle memory will continue to work even if your brain doesn't.

<comment><USER14> > your muscle memory will continue to work even if your brain doesn't

Indeed, it is only when you encounter an actual combat situation that you understand why the karate elders insist on so many thousand mindless repetitions of basic movements back & forth: even though you have no time to think (and even if you did it would do no good because combat stress reduces your intellectual capacity by 80%), it instantly executes spontaneously and afterwards you find yourself thinking "wow - I did that ?". Brutal repetitive training that focuses on the basics: it works.

<comment><USER12> I feel like the there is something similar at play in long distance running. By repeating the same motion a lot, your nervous system probably works out the most efficient pathways to activate and can work without your conscious mind getting too involved.

</comment></comment></comment></comment></comment></comment></comment><comment> charles-salvia I'm inclined to be very sympathetic to this article, even though I don't agree entirely. In an age when conspiracy theories about "global elites" are rampant, it helps to remind everyone that most human designs fail due to unforeseen complexity and unpredictability. When faced with people who actually believe in "master-plan" type conspiracy theories, I have to really wonder if they've ever actually tried to do anything hard.

That said, it's certainly possible to apply long-term planning and coordination in a very effective way. It's just that hindsight and selection- bias tends to make success stories look like the human agency involved was hyper-competent, while glossing over all kinds of factors like simple luck or even just gross incompetence on the part of those who were opposed to the goals of the planning.

And how exactly is the NSA a refutation of anything? They leveraged enormous government resources to pull off massive surveillance covertly for a while, but now we're talking about it publicly so I guess they weren't exactly so hyper-competent after all.

Seeing hyper-competent human agency and design behind everything is essentially just another example of the general human brain-defect called Apophenia ([https://en.wikipedia.org/wiki/Apophenia](https://en.wikipedia.org/wiki/Apophenia)).

</comment><comment><USER15> This doesn't just apply to politics.

That was probably my earliest epiphany as a founder: nobody knows what the fuck they're doing. Nobody.

That VP of marketing at a fortune 100? No idea what he's doing. That young startup CEO who's successful while being 10 years your junior? No freaking idea at all.

Even in areas where you would assume process and numbers outweigh the human element (e.g. finances), I was surprised to see how the sausage is made (and how messy it is).

Once you've internalized that truth, the world is a lot less intimidating, especially as a founder.

<comment><USER16> Hanlon's Razor in action, as I see it.

</comment></comment><comment><USER17> So... My honest take away is: Can you disrupt Washington by coming up with a better coordination tool?

I mean - that's clearly not the bulk of the problem (unclear causal relationships between the actions you can take and the outcomes you want seems to the real problem), but it's specifically cited and seems doable...

...until I think about how well teams inside companies communicate.

<comment><USER18> Part of the problem is probably that there is no money in it: Congressional offices don't have a big enough budget for the _staff_ they need, much less any pieces of software/services.

<comment><USER19> Isn't software a tool for leverage? If staff is additive, then software is multiplicative. The right software would allow a staff of 10 to do the work of 30 or 100.

</comment></comment></comment><comment><USER20> Seems a slightly simplistic analysis.

We know there are people who scheme and plot to get what they want, and will stop at nothing to do so.

We also know that the real world is chaotic, that no battle plan survives first contact with the enemy.

The most successful schemers are not those who can think ten moves ahead, because no-one can do that.

Instead they're the ones who can turn on a dime, who can rapidly re-scheme, and re-scheme again, always adapting to circumstances so quickly that the rest of us are left wondering wtf happened.

</comment><comment><USER21> Reminds me of this ramble [https://nickbradbury.com/2014/12/11/the- programmers-dream-a-...](https://nickbradbury.com/2014/12/11/the-programmers- dream-a-ramble/) . I printed it out and hung it in my livingroom, keeps me sane.

<comment><USER22> Well one can argue that people "in charge" are not at all the people that hold the public offices so we have no clue whether or not they have a clue. If one wants a decent conspiracy theory one could start with the fact that Capital Group, Fidelity , BlackRock and Vanguard have 13 trillion under management majority of which is invested in US stock market so if they collude they would have majority of votes in a majority of US public companies.

<comment><USER23> But the point of both articles is that these groups are not even unified within themselves, much less can they collude effectively, or out-maneuver the various forces that would not want them to control everything. And even if they could - what then? Managing even one company is difficult, trying to coordinate several thousand is essentially impossible.

More pedantically, you're assuming those groups could take all of those assets from where the owners of those assets put them (including bonds, commodities, foreign investments, etc) and put them into the US stock market. Even if they did so they're barely above 50% of the US market cap (put at 25 trillion by World Bank).

[http://data.worldbank.org/indicator/CM.MKT.LCAP.CD?locations...](http://data.worldbank.org/indicator/CM.MKT.LCAP.CD?locations=US&name_desc=true)

<comment><USER22> You are not counting effects of circular ownership citi owns 5% of Chase and Chase owns 5% of Citi and on and on you effectively don't need 50% to control the vote. Even if those 4 are off you can add next two or three with trillion +/\- under management. So worst case you need 7 people to collude.

</comment></comment></comment></comment><comment><USER24> Having studied the deep state for a long time now, I have come to a more nuanced conclusion:

Incompetence abounds, but is useful cover for the few malicious actors.

Often in discussion I have derided the use of Hanlons razor, for I think it a logically fallacious statement from the get-go, but I understand the spirit of it. The problem is that at a certain point, incompetence becomes indestinguishable from malice. At some level, attributing incompetence to everything because _nobody knows what they are doing so it 's just the complicated process of organic failure_ no longer suffices.

The irony is that I most often hear this defense from the realpolitik subscribers of the Kissinger type defending bad actions... the ones I highly suspect of being the primary malicious actors abusing the incompetence in the first place!

You want a perfect example of this? High level manipulation of events via the triple agents of the Cambridge 6. This is also why I theorize that the deep state is largely unkown the middle-high level managers, they simply corrupt from the top down.

For those curious about the deep state, I suggest starting with works of Peter Dale Scott.

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

</comment><comment><USER25> The truth is that the difference between many companies is the perception, that they can create towards the external world, and 3rd parties: that they KNOW what they are doing.

Eventually, when you talk to your friends, you notice it's a mess at most workplaces. Management often is very shaky and clueless. People keeping up apperances etc. This is all more or less the same in alot of companies (though not all), however: the perception of it to the outside world, is what makes the difference.

I've been validating this theory many times throughout the years and it's very applicable and true.

</comment><comment><USER13> How about nobody knows what they are doing, but people are making plans to screw other people anyways, and sometimes they work. And as always there will actually be people who do this for so long and really work on improvement that they will beat the others in most cases, even if sh*t hits the fan.

</comment><comment><USER26> I've seen this written slightly differently:

"Never attribute to malice that which can be sufficiently explained by stupidity."

</comment><comment><USER27> I think it was Jessica Yellin on NPR's On Point who said something about Washington being way more like VEEP than House of Cards. Comforting somehow.

</comment><comment><USER28> So _The Thick of It_ is more accurate than _House of Cards_?

</comment><comment><USER29> Well, I would agree that _most people most of the time_ don't know what the heck they're doing...

...but some people DO know what they're doing, at least some of the time.

Applies to business too.

</comment><comment><USER30> No reference to Adam Curtis yet?

[http://www.bbc.co.uk/blogs/adamcurtis/posts/BUGGER](http://www.bbc.co.uk/blogs/adamcurtis/posts/BUGGER)

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

</comment><comment><USER31> This article was written with the intent to make its readers worse at recognizing patterns. Put bluntly, it was written to make you more stupid for the benefit of the authors or their principals.

It doesn't belong here. The persuasion is ham-handed and obvious, but clearly effective enough to get it on the front page here.

</comment><comment><USER32> I agree with the premise but not the conclusion. Worked at/have seen a few start-ups close up; people don't know what they are doing-- I mean this in a "cliff jump build parachute" way not pejoratively.

With that in mind, you have a fragmented ecosystem and a lot to gain. I don't think people are organized or agreeable enough for an "illuminati"-esque conspiracy, but people and groups can scheme so well here w/ little oversite.

Article seemed to say that small specific task goals can get done but because some large groups can't execute a large scale goal there is no "scheming". I disagree.

</comment><comment> wu-ikkyu Tldr; a strawman + an anecdote: Author posits fictional conspiracy movies are fictional, and the author has never personally witnessed a successful "scheme", so you have nothing to worry about.

History shows otherwise.

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

</comment><comment><USER33> Think in terms of natural selection. Behaviors (and personalities) that make more successful choices in that environment will tend to survive in the environment, regardless of whether they know what they are doing.

Most of the bumbling fails. Some of the bumbling works. And so the most "effective" politicians (and organizations) will survive, even if their success has little to do with deliberate scheming.

</comment><comment><USER34> That probably applies much more to underfunded grassroots activists then to large corporate lobbyists. The large corporate lobbyists have organized long term plans working from state houses to DC to accomplish multi year goals. Take a look at ALEC for example.

It's like the difference between some GPL open source project and Google's latest Android release.

</comment><comment><USER35> This article reminds me of a book I read several years ago: None Dare Call It Conspiracy by Gary Allen, written in the 1971

For anyone who wonders whether there are sinister things being done in concert by groups of individuals, I highly recommend reading that book.

</comment><comment><USER36> I have a theory: human civilization is at about the peak of what can be achieved, with people in charge. We're just too error-prone and selfish and shortsighted to ever form a larger functioning society.

<comment><USER27> There are some theories, such as those laid out by Francis Fukuyama in the Origins of Political Order, which postulate that homo sapiens are optimized to form functioning societies of about 120 units. However, certain features have evolved in our species, such as the ability to speak AND write, and form mythologies and stories, which allows our ability to form political societies to exponentially increase. Who's to say we won't keep evolving to find ways to cooperate in ways that were impossible before?

<comment><USER36> Because, look at the newspaper (or blog or whatever). Its coming apart at the seams.

</comment></comment></comment><comment><USER37> The biggest thing is that people are scheming "behind the scenes".

People are scheming in politics, in business, in family, with friends.

We all agree on this?

Why we are living in such a Machevellian society? Are there any alternatives?

</comment><comment><USER38> Hell, all you need to know that is to read Frank Rich's bio and then watch _Veep_. You'll learn just as much, and laugh a lot more while you do it.

</comment><comment><USER39> I agree with the title. The few places I have worked where things were not horrible, were places where one guy had a masterplan for it all.

</comment><comment><USER40> I upvoted this before I read the article, simply because I agree with the headline. I wonder how many others here did the same?

</comment><comment><USER41> Since the rise of Trump, first political comments stopped being flagged. Now HN is entertaining daily threads on politics.

<comment><USER42> If you think a submission is inappropriate for HN, please flag and move on.

<comment><USER41> What's with the hostility? I'm pointing out something factual that some users (especially new users) may not be aware of.

<comment><USER42> There's no hostility. There are plenty of comments from mods, including the discussion on Political Detox Week, that discuss politics on HN, which are actually helpful rather than just observations.

Here's one such comment:

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

<comment><USER41> What? Well I'm sorry my comment was not helpful to you. In the future should we judge everyone's comments with respect to someone in a position to offer better information?

For example, here is a comment by you:

>Disclaimer: I don't have a comp sci degree.

>I've found having an understanding of the underlying theories supporting the tools (that includes languages and libraries) I use makes me use them better, understand their strengths, weaknesses, and how to improve them. It also helps me look at problems from various perspectives and see how other solutions may fit, including those that don't already have a tutorial or library.

>I suspect that if you're an effective programmer, you're doing more than copying and pasting and growing in experience, and you're actually absorbing and apply more computer science than you realize.

You also post observations without being an authority. That is fine. You need to relax with the, yes, hostility.

<comment><USER42> I'm sorry you're reading so much hostility and negativity into my replies. It's very much not intended.

</comment></comment></comment></comment></comment></comment><comment><USER43> J. Edgar Hoover.</comment>


Ask HN: Why does Tesla battery last so long, but not mobile and laptop battery? - <AUTHOR> I recently read[0] that the Tesla battery pack degrades just 5% after 50,000 miles. Why aren't we seeing this kind of performance with our mobile and laptop battery packs yet? My new phone's battery is already lasting only ~80% of what it used to in just one year.<p>[0]: https://electrek.co/2016/11/01/tesla-battery-degradation/ <comment><USER2> Not 100% sure but I believe it is due to the size and type of batteries used by Tesla.</comment>


Show HN: GitHub's Top Repos, an Interactive Visualization - <AUTHOR> https://github.com/donnemartin/viz <comment><USER2> Is there a way to see commits, issues and releases

eg Would be interesting to see if there are repos that have disproportional issues/stars</comment>


Testing like the TSA - <AUTHOR> http://37signals.com/svn/posts/3159-testing-like-the-tsa <comment><USER3> This is why I left Microsoft. Automated testing was a separate discipline - meaning there were "dev devs" and "test devs". Automated tests were written based on what the "test devs" had time for, not on the need or usefulness of such tests for the actual code. I was hired as a "test dev" - I had no industry experience at the time and figured I would give it an unprejudiced try to see if I liked it.

I quickly realized that my job was futile - many of the "good" tests had already been written, while in other places, "bad" tests were entrenched and the "test dev" had the job of manning the scanner to check for nail clippers, or upgrading the scanner to find as many nail clippers as possible.

Here's a useful rule on the subject that I picked up from an Artificial Intelligence course back in the day: The value of a piece of information is proportional to the chance that you will act on it times the benefit of acting on it. We all realize there is no benefit in testing if you ignore failures rather than acting to fix the bugs, but in much the same way that doing nothing when tests fail has no benefit, doing nothing when tests pass also has no benefit - so tests which always pass are just as useless as failing tests you ignore, as are tests which only turn up corner-case bugs that you would have been comfortable with shipping.

If you're doing the right amount of testing, there should be a good chance, whenever you kick off a test run, that your actions for the next hour will change depending on the results of the run. If you typically don't change your actions based on the information from the tests, then the effort spent to write tests gathering that information was wasted.

<comment><USER4> I disagree that there is no benefit in passing tests that don't change your behavior. Those tests are markers to prevent you from unknowingly doing something that should have changed your behavior. That is where the nuance enters: is this a marker I want to lay down or not? Some markers should be there; others absolutely should not and just introduce noise.

<comment><USER3> I don't understand what you mean by "prevent you from unknowingly doing something that should have changed your behavior". If you do something without knowing it, how could it change your behavior? If it's a case where you should have changed your behavior, why would you prevent it?

<comment><USER5> I believe the above comment refers to regression testing. For instance, if I write a test for an invariant that is fairly unlikely to change, then the chance that my behavior will change in the next hour based on the test run is small. However, if and when the invariant is mistakenly changed, even though negative side effects might not be immediately visible, it could be immensely valuable to me to see the flaw and restore that invariant.

<comment><USER3> Yes - but the test would fail when the invariant is mistakenly changed. On the test run after the invariant was changed, you would get new information (the test does not always pass) and change your behavior (revert the commit which altered the invariant).

That is the point of the "changing behavior" rule - you do not gather the benefit of running a test until it has failed at least once, and the benefit gathered is proportionate to the benefit of the action you take upon seeing the failure. The tricky part of the rule is that you must predict your actions in the future, since a test that might have a very important failure later could pass all the time right now. Knowing your own weaknesses and strengths is important, as is knowing the risks of your project.

There are possible design benefits to writing tests, since you must write code that is testable, and testable code tends to also be modular. However, once you have written testable code, you still gain those design benefits even if you never run your test suite, or even delete your tests entirely!

<comment><USER4> Your comment reads like you can know when a test will fail in the future (how else can you know the difference between a test that "always passes" and a test that will fail in the future to identify a regression?). You may have a test that passes for ten years. When do you know it's OK to nuke the test?

Based on your follow-up, it is clear that my reading was not what you intended.

<comment><USER3> You can't know, but you can guess, based on past experience or logic. The simplest way to estimate the future is to guess that it will be similar to the past.

For example, if you personally tend to write off-by-one errors a lot, it's a good idea to write tests which check that. On the other hand, if you almost never write off-by-one errors, you can skip those tests. If test is cheap to write, easy to investigate, and covers a piece of code that would cause catastrophic problems if it failed, it's worthwhile to write the test even if you can barely imagine a possible situation where it would fail - the degree of the cost matters as much as the degree of the benefit.

You don't "know" when it's OK to nuke a test just as you don't really "know" when it's safe to launch a product - you decide what you're doing based on experience, knowledge, and logic. The important step many don't take is developing the ability to distinguish between good tests and bad tests, rather than simply having an opinion on testing in general.

<comment><USER5> Re: "The simplest way to estimate the future is to guess that it will be similar to the past."

When we say that the future will be similar to the past, for code, we really mean that the probability of certain events occurring in the future will be similar to their prior probability of occurring in the past.

In my hypothetical example of testing an invariant that is unlikely to fail but damaging if it does, it might be valuable to keep that test around for five years even if it never fails. Imagine that the expected frequency of failure was initially <once per ten years>, and that the test hasn't failed after five years. If the expected frequency of failure, cost of failure, and gain from fixing a failure remain the same, we should keep the test even if it's never failed: the expected benefit is constant.

Not to say that we should test for every possible bug, but if something is important enough in the first place to test for it, and that doesn't change (as calculated by expected benefit minus expected cost of maintenance), we should keep the test whether or not it changes our behavior.

Thus, if we could estimate probabilities correctly, we really would know when it's OK to nuke a test.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> A thought that folks reading this post might have an opinion on:

"Libraries should be mostly unit tested. Applications should be mostly (and lightly) integration tested. Naturally, some parts of a complex app will behave like a library..."

Agree or disagree?

<comment><USER7> Strongly agree, but also I think that the interesting thing is why this might be so and what it tells us about application architecture.

The basic thing about tests is that once you have them passing, they represent statements about constraints on the program. In other words, they express your opinion of things that should not change. Unit tests are a bet that certain aspects of the implementation will not change. Integration tests are a bet that certain aspects of the externally visible behaviour will not change.

Libraries tend to be smaller and with well-defined responsibility. Applications tend to be bigger and have many responsibilities. In general, I think it's true that the requirements for libraries change less often than the requirements for applications. I think this leads us to expect that applications may need to be rewired "under the hood" and have their implementations changed as responsibilities are added, removed, or changed.

This, I believe, leads us to want to unit test applications less, because a unit test expresses implementation semantics, and we expect application implementations to change. No what about integration tests? Well, if we're unit testing less in the application, we need to make up for it by integration testing more, otherwise where do we get our confidence?

Now if we throw the words "library" and "application" away, this suggests to me that those parts of the code that are small and tight and with a single, clear responsibility should be unit tested, while those parts that involve a lot of what the AOP people call 'scattering and tangling,' should be integration tested.

Thoughts?

<comment><USER8> Unit testing didn't fully make sense to me until I played around with quickcheck (and eventually theorem proving in Coq). Unit tests vanish nicely to theorems and (empirical) proofs if your code expresses a succinct API. This is one end of the testing continuum.

I use this sort of stuff extensively when doing mathematical computing and statistics because there's usually a clear mathematical boundary. Once you're inside it, it's relatively easy to write down global properties (theorems) of your code's API.

The moment you cross that boundary your testing apparatuses have to get more complex and your tested properties less well-defined. Unit tests are hazier than quickcheck properties and integration tests hazier still.

This continuum seems to be precisely the same as the code reuse continuum. Highly abstracted, testable code with a shapely API is a highly reusable library whether you like it or not. Maybe it's being called by other code, maybe it's being called by your UI, maybe it's being called by the user themselves.

<comment><USER9> I view unit tests as a kind of proof by counter-example. You have a logical structure your program embodies. This structure is very hard to specify mathematically and prove deductively so you come up with key statements that must at least evaluate to true for this structure/theory. The tests are a bunch of counter-examples that should be false (test passed).

If a random testing framework is available in your language they really should be integrated as they are able to come up with some pathological examples.

<comment><USER10> For Haskell you can do even better than random testing: There's Lazy SmallCheck for exhaustive testing. (For some values of `better' and `exhaustive'.)

</comment></comment></comment></comment></comment><comment><USER11> _Don't use Cucumber..._

Thank God someone with a bullhorn finally said this. I was beginning to think I was alone in my hatred of Cucumber. (And my love of Test:Unit/Minitest.)

<comment><USER12> I'm in the same boat as you, but I don't tend to voice my opinions on Test::Unit because there is such a strong opinion _for_ RSpec and Cucumber. IMHO, I tend to like my tools to be tried and true, and not do any fancy magic.

<comment><USER13> Learned my lesson the hard way(s) with Rspec and Cucumber a while ago - <USER2> waste of my time.

There's a group of devs that have fooled themselves into thinking anyone outside their group understands how they are testing. I've seen this firsthand. DHH has always been right, imo, in this regard; test what you think is important, use simple tools.

TestUnit still serves me well and it perfectly fits my needs of do more with less.

</comment></comment></comment><comment><USER14> I largely agree - there is a certain testing dogma that goes into testing that this article dispels nicely. Of course, it comes with its own dogma, though I guess that's a bit tongue in cheek considering the author says: "let me firebomb the debate with the following list of nuance-less opinions".

So let me add some nuances:

1) DO aim high though, just recognize that the work in getting there is probably better spent elsewhere in your app.

3) BUT ignore this advice if you don't write tests yet. When you learn to test, or start working on a new feature that you may not know how to test, it will take you as long to test it as to code it. From there on though, test cost of testing is pretty cheap, so the 1/2 or 1/3 ratios start to make sense.

4) Do test that you are correctly using features and libraries (yes, standard activerecord stuff is probably going overboard).

5) But dont forget that many bugs occur at the boundaries of functional units.

6) Do what works for you, and what makes sense for you code base and business priorities. I don't love cucumber myself, but when others swear by it I can see why they like it.

Kent Beck's quote at the end is lovely. The first and only book on TDD I read was Beck's, and it's good to know that he's not actually as dogmatic as the book makes you think.

</comment><comment><USER15> Brilliant article. Testing for testings sake is wrong. Testing for 100% coverage sake is wrong. Write just enough tests at the level where it catches most of your regressions. Drill down into unit tests for complex logic, because you can test that more extensively and much faster than an integration test. Then leave a case or two for an integration test to make sure things are hooked up right.

Don't be afraid to unit test little complex things here and there. Are you writing a function to parse a string in a certain way? Pick that function, elevate its visibility if need be, write a simple unit test to make sure you didn't make a stupid off-by-one mistake. Does the rest of the class otherwise not loan itself to unit testing? That's OK, move on.

We've learned that each line of code is a liability, even if it's a configuration file, which is why we have come to appreciate things like DRY, convention over configuration, less verbose languages, less verbose APIs. Likewise, each line of test code is a liability, so each line better justify itself.

<comment><USER16> _Write just enough tests at the level where it catches most of your regressions...make sure you didn't make a stupid off-by-one mistake._

One thing that I've seen in inexperienced coders (including myself in the past) is that they tend to think of every bug as a fluke one-off mistake in an otherwise mostly flawless and awesome record. New coders tend to want to just fix a bug, then pretend it didn't happen.

This is exactly the wrong attitude to take. As a discipline, we programmers should be studying our mistakes and taking steps to prevent them in the future. As a craftsperson striving to improve, each of us should be studying our own mistakes and taking steps to prevent them in the future.

<comment><USER15> I think you might be misreading what I wrote. While your points are correct, I was specifically referring to "off-by-one mistake", which is a common "silly" error (since many indices are zero-based, it's often easy to request one too many elements, or chop off the first item).

Also the way you quoted me above, "make sure you didn't make a stupid off-by- one mistake" looks like it's talking about writing just enough tests. However, in context, I'm actually referring to writing unit tests for small items where you might make a stupid off-by-one mistake.

So I was never referring to "one-off mistakes", as in mistakes that are flukes.

Your points are all good otherwise! Never rest on your laurels and always think about what you can do to catch your mistakes.

<comment><USER16> I did misread what you wrote, but I thought the point was a good one to make, so posted it anyhow. Not disagreeing, just adding.

</comment></comment></comment></comment><comment><USER17> Nice read.

I'm no Rails dev, so I'm curious about this one point from DHH:

> _6\. Don't use Cucumber unless you live in the magic kingdom of non- > programmers-writing-tests (and send me a bottle of fairy dust if you're > there!)_

I mostly do C#, and teams I've recently been on have found SpecFlow tests to be an _excellent_ time saver in communicating requirements and acceptance test criteria with customers. Has Cucumber not been designed for the same purpose?

I might guess that David included the point because a product business such as 37signals has no non-programming stakeholders to communicate about requirements and acceptance criteria with.

Using BDD for having non-programmers _write_ tests sounds far-fetched to me indeed. It's excellent to have them able to _read and understand_ the tests, though. Any opinions? Is BDD as dead horse, or is DHH a little narrow minded here?

<comment><USER11> My own observation is that some ruby/rails developers get so enthralled with testing that it becomes an obsession that eclipses the product that they are building. The result (strong opinion coming...) is libraries like rspec and cucumber. They're complex and burdensome, and tend to attempt to mimic english, but often do so poorly and are totally unsuitable for non-coders. You spend a lot of time learning "the way" to do things and wind up with code that is unintelligible to less experienced developers.

I use test::unit and minitest and it gets the job done without having to keep up with the latest trends. It's simple and can be written in a way that correlates well to actual English requirements. It takes all of an hour to digest minitest from zero.

That said, Cucumber and rspec are very popular, so I may be the weird one.

<comment><USER18> For a long time, I had a deep hatred for RSpec because we used it on a project before the API stabilized (and before it was easy to maintain an environment where all developers had the same gems).

We got stuck on some particular revision in the RSpec Subversion repository. The choice was re-write all the specs, or stick with that ancient version. We re-wrote all the specs -- to test/unit.

Several years later, and I have never picked up RSpec for my own use. However, I am working on another project that chose RSpec and it is working out pretty well. I have turned on render_views so I don't have to test those separately and am only using mocking for external services.

Cucumber, on the other hand, I do not understand at all. Why write tests in English when you have Ruby?

<comment><USER19> There's a few solid reasons I've heard for using Cucumber, although in my life I've not found a need for it yet.

1) Although it's a Ruby tool, it works with a ton of languages. Someone can write code based off Cuke tests in Ruby or .NET or whatever without much trouble.

2) it makes web workflow testing cake

3) it keeps people strongly out of the "implementation" zone when they are thinking about how a program should be properly executed

4) it works with many spoken languages so if you're collaborating with an international team it could be useful there.

5) it has a whole bunch of report formats built in

If you don't find any of those features incredibly useful, I'm not sure you're going to ever see a need for it. I've played with it but for me it seems more hassle than anything. I do LIKE it but that's not enough to justify the time spent messing with it.

</comment></comment></comment></comment><comment><USER20> _You're probably doing it wrong if testing is taking more than 1/3 of your time. You're definitely doing it wrong if it's taking up more than half._

"No generalization is wholly true - not even this one" said Oliver Wendell Holmes.

What proportion of your time do you spend writing tests for a one-off bash script to fix some filenames? What proportion of your time do you spend if your writing the fly-by-wire code in a 777? You should spend "enough" time writing tests - where "enough" is extremely context dependent.

I also worry about this sort of advice because the reason many spend too long testing is that they're _really bad a testing_. I fear this group will use the quote as an excuse to do less testing, rather than get better at testing.

Also, to be honest, I'd be hard put to tell anybody how much time I spend writing tests vs. writing code. I've been practicing TDD for about ten years now - and I just don't think about "testing" vs "coding". I'm developing - which involves writing tests and writing code. Trying to separate them out and time them makes about as much sense to me as worrying about whether I type more with my left or right hand.

<comment><USER21> _Also, to be honest, I'd be hard put to tell anybody how much time I spend writing tests vs. writing code._

That's a good point. Test writing versus code writing is not black and white. Spending time writing tests is also time spent thinking about what's going to be coded. Writing tests should make the coding process go quicker such that there exists a lot of overlap in test writing and coding.

</comment></comment><comment><USER12> I completely agree with David's assertion that there is too little focus paid to how to test properly or what over-testing looks like.

Here's a question to the HN community... For a library you write yourself to, say, access a Web service, how do you go about testing it? (For example, if you want to write tests against an Akismet gem)

I tend to write both unit tests and integration tests for it. My unit tests mock out the HTTP calls made by the library and only test that the library is able to handle both good and bad inputs.

My integration tests allow the library to speak directly to the web service in question, to test that the correct connection is being made and the service is providing the correct data back to the library.

Is this overkill?

<comment><USER22> I'd have to lean toward yes and here's why:

1) Config, connections, or whatnot are one-time only. You're not going to screw up many times.

2) Not all WebServices have their own test-server so count yourself lucky if the ones you use have them :)

3) You're testing their code instead of yours if you have to make sure correct data etc comes back.

I usually only write unit-tests if they came back with bad data and we did not anticipate it (edge-case situation).

</comment></comment><comment><USER23> I don't get the "don't aim for 100%" point. What are you aiming for then? 50%? What happens when you reach 50% and remove some code - do you remove enough tests to match the ratio?

We may just phrase the same idea in 2 different ways, but I'd go with "don't force yourself to do 100% coverage if it's not that relevant" / "don't add a test for a simple getter if you have more important things to do". If you can do 100% and have time for it - you should definitely do that. For example in case someone rewrites your getter, but it's not that simple anymore.

<comment><USER20> _I don't get the "don't aim for 100%" point_

For me the point of that one is that test coverage isn't the goal - good code is.

I've seen folk disappearing down a rabbit hole focusing on getting that last 2% of branch coverage using some baroque mock object monkey patched into the system. Their focus was on test coverage. What people who focus on test coverage get is an evil complex test suite that's very brittle in the face of change.

Other, smarter, folk go "damn - I can't test that easily - this code sucks", factor out unrelated functionality into appropriate classes, add some code that makes some duplication between branches obvious, factor out the duplication and end up with something that's better code, with simpler tests - and better test coverage too. Their focus is on the code - not the test coverage.

[Edited for... erm... English]

</comment></comment><comment><USER24> This reminds me of the old joke about the man who went to his doctor and said: "Sir, those deposiwhatever pills you gave me were no good. I might just as well have stuck them up my ass".

Using a tool (or a medicine) to do something else than what it was designed for rarely has a positive effect. Cucumber was not designed to be a testing tool. Most people don't realise this, and end up with a verbose, unmaintainable mess. They blame the mess on the tool without realising that they used the tool wrong.

I don't use Cucumber to test my code. I use it to discover what code I need to write. This is a subtle, but important difference. This approach can work whether there are non-technical people involved or not.

I typically start out with a single Cucumber scenario that describes from 10.000 feet how I want a certain feature to work - without getting bogged down in details.

This allows me to reason and think about the domain in a way that helps me write the simplest possible code. What usually happens (to me at least) is that I end up with a simple design that reflects the domain.

Last week I wrote a small application like this. It is 1000 lines of Java code. I have 6 Cucumber scenarios - a total of 100 lines of Cucumber "code" (Gherkin) and about 200 lines of Step Definitions code (the glue code that sits between the Cucumber scenarios and the app).

I could have used JUnit instead - or I could have just written the code without any tests at all. For me, this would have made it harder to start coding. I would have started off with a much more muddy picture about how the app needs to behave and how it should be designed internally. I would have spent more time experimenting.

If you use Cucumber as a starting point to discover the code you need to write - and keep your scenarios few and high level - then you're more likely to reap benefits instead of pain.

And never fall for the temptation to use Cucumber to test details. That's what unit testing tools are for.

</comment><comment><USER25> Hey, while we're slaughtering sacred cows, lets kill mocking, endotesting, expectation based testing, and the whole nine yards. It's a horrible practice that causes you to write too many tests, too many assertions, and results in tests that stay green even if you _delete entire files from your codebase_.

<comment><USER26> How would you test, say, payment processing, in any sane way, without mocking?

How do you test failure handling code when the failure can not be reproduced in a known way by the current code base?

I agree these tools are often overused, however they do have their roles.

<comment><USER25> Yeah I'm not referring to mocking external services, which is both smart and useful. I'm referring to the practice of endotesting whereby you mock your own objects and interfaces as a means to test interactions between them.

</comment></comment></comment><comment><USER27> @dhh was talking about this on twitter before he made this post. And I think @dchelimsky has a very fair point that @dhh ignores: testing is all about effort to eliminate some amount of risk.

 _Test x but don't test y can't be universal. Risks are (often radically) different in every app/team._

(from <https://twitter.com/#!/dchelimsky/status/190096365794230274> )

@dhh and 37Signals have a different perspective on acceptable risk for their own product (which they maintain every day) vs developers writing software for someone else/handing it off to someone else. 1 dev to 1 project vs 1 dev to x projects. As a consultant, my acceptable risk level is very different than an entrepreneur trying to push out a MVP and I think testing will reflect that.

<comment><USER28> I think dhh tried to address that with his comment _yes, yes, if you were working on an airport control system for launching rockets to Mars and the rockets would hit the White House if they weren't scheduled with a name, you can test it—but you aren't, so forget it_

<comment><USER27> That's a hyperbolic comparison. Yes, focusing on outliers makes all the other data points look the same. My point is that in the context of each team/app, those differences in acceptable risk matter.

</comment></comment></comment><comment><USER20> _Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink_

I think this depends on the domain. Some code ends up with a metric shed load of important edge cases because it's modelling something with a metric shed load of important edge cases - not just because your code sucks.

For example one project I worked on involved a lot of code to manage building estimates. It involved a _stack_ of special cases related to building codes, different environments, the heuristics that the human estimators used, etc.

There wasn't any sane way to remove the special cases - the domain caused them. There wasn't a way to sensibly avoid writing tests - since we didn't really want estimates for the amount of drywall in a multi-million pound skyscraper to be wrong :-)

</comment><comment><USER29> Testing isn't just about preventing bugs, it also encourages better design, and good design makes extending and enhancing your application much easier and faster.

...in general, of course, there's always exceptions, don't be dogmatic.

<comment><USER30> I think this aspect of unit testing is largely overrated. True, it does stop people from writing something ridiculous, like a 1000-line method that handles a dozen different things. But it also encourages developers to go overboard in the other direction: creating endless, needless layers of abstraction, chopping logic into bits that are to small to represent anything in reality and doing dependency injection when it's not needed. It's important to keep in mind that ease of unit testing doesn't automatically ensure ease of use of your library in real code.

In short, it's better to think of unit testing as bug-prevention mechanism. Thinking of it as an ultimate design mechanism doesn't end up well.

</comment></comment><comment><USER31> Discussions like this arise mostly because developers today think less about whether a feature should be built and more about how it should be architected and tested.

For decades, we've been conditioned to think that by the time a feature is written down on paper, someone else has crossed all the Ts and dotted all the Is to determine that the feature has value and should be built.

It's far easier to focus on low value testing issues than attempt the harder work of convincing the customer/product owner that certain features should not be built.

</comment><comment><USER32> If you're looking to manage code smell, check out Code Climate - <http://codeclimate.com>. We use it as an awesome gut check for your code coverage as you write more code. It helps you see at a macro level: "Are you writing better or worse code over time?". Pretty cool stuff.

</comment><comment><USER33> _Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink._

I think this is stated backwards. A code-to-test ratio of 1:3 is _lower_ than 1:2, and based on the wording (smell, stink), it sounds like David is saying it's _higher_.

<comment><USER34> It is. Most of the time this is expressed as test-to-code, and I suspect it was originally written that way before being reworded.

</comment></comment><comment><USER18> I am glad DHH has put up this piece. This is one of my favorite topics to be contrarian about. I am a strong believer in the importance of developer testing to ensure code quality, but some people take it way too far. I gave a talk about this at RubyFringe: <http://railspikes.com/2008/7/11/testing-is- overrated>

I also am utterly opposed to the Cucumber-style programming-in-English-via- regexp testing approach. Unless someone who doesn't know how to code is writing those step files, why subject yourself to that?!

</comment><comment><USER35> My first unit testing experience (Django), it wasn't 1:2 or 1:3, it was more like 2:1. As far as time spent, I don't even know if I could separate the two, I spent so much time in tests and production at the same time. I actually want to scrap that code and restart it, it's not worth changing all those damn tests any time something else changes. I tend to go to extremes, I'm actually thinking of switching to Yesod next to see if I can mitigate a lot of the reasons for testing.

</comment><comment><USER36> I disagree about coverage.

First, I've found tests to be an excellent way to debug, much better than trying to manually get the app into the state I want and then stepping into the debugger.

Second, having a good coverage lets you refactor with a lot more confidence. I often open some file to fix a bug/add a feature and notice some piece of code that is horrible. I can comfortably fix that code too and if the tests pass (including the one that failed before fixing the initial bug/adding the feature) I'm done.

</comment><comment><USER37> There are too many managers that just want Metrics. for example: Bill created 100 tests this month, Sam has 95% automated test coverage.

These metrics don't mean anything.

</comment><comment><USER38> Great points. What not to test is just as important as what to test. If you're interested in learning how to start TDD, Typemock is hosting a free webinar next week introducing TDD: <http://j.mp/IVmQNi>

</comment><comment><USER39> I've always enjoyed Testivus on test coverage metrics[1]

[1] [http://googletesting.blogspot.com/2010/07/code-coverage- goal...](http://googletesting.blogspot.com/2010/07/code-coverage-goal-80-and- no-less.html)

</comment><comment><USER40> This seems to be almost the opposite attitude of the people behind Jester: <http://jester.sourceforge.net/>

</comment><comment><USER41> STOP. BREATHE. THINK.

Here's the Stack Overflow post that I think triggered this post:

[http://stackoverflow.com/questions/153234/how-deep-are- your-...](http://stackoverflow.com/questions/153234/how-deep-are-your-unit- tests/153565#153565)

Yes, he said "fuck". Let's get past that, because it's a super boring discussion to have on HN.

Also: pointing out specific 37signals or Rails bugs as evidence that this view is flawed? Also a super super boring way to argue. Argue with the idea, not the proponent of the idea.

Ok, feel better? _Now_ comment on this story.

</comment><comment><USER42> What a bunch of hogwash; 1000 lines of code to to test validates_presence_of? What testing framework is he using? x86 assembler?

The only part I agree about is the view testing and partially cucumber.

Then again I dont think 37s has a large amount of business logic to test (compared to some of the other commenters in here) and their testing is mostly front end, and testing front end ajax-y stuff with cucumber, does indeed suck.

</comment><comment><USER43> It is not fun to pull out the power tools on a huge piece of software with 50 thousand unit tests and see that 600 of them fail because you changed an important part if the code.

It means the unit tests will have to be deleted, and or updated. If each takes 10 Minutes that is 6000 Minutes.

On the other hand, seeing one unit test fail in another module you didn't expect to fail can save you a week of work, so it's all in how brittle and organized the tests are.

<comment><USER15> In my experience, it means that you have to treat your tests with nearly as much software engineering respect and prowess as your real code. You have to factor things out and try to avoid DRY (particularly tough sometimes in testing) as much as possible.

If there is one "concept" that you're asserting in your test suite, you want that concept to only be repeated once or as close to once as you can get. Often times, people copy paste sets of assertions that have mixed concepts. Then, when a requirement changes, hundreds of tests end up having to be updated.

This is why many large companies, that contract out test automation development or train manual QA people with enough programming skills to write tests, end up with brittle test suites. One look at those test suites by an experienced developer and it's no wonder: there's conceptual/semantic duplication everywhere.

</comment></comment><comment><USER26> The phrase "Don't test standard Active Record association" jumped out at me, since I've discovered a major bug in the most basic function of Active Record associations in 3.0.x.

<https://github.com/rails/rails/issues/5744>

That said, I generally agree with DHH that many developers write too many of the wrong kinds of tests and this can make products brittle.

I share his disdain for Cucumber and rspec. I prefer clarity over syntactic sugar and non-programmer readability.

<comment><USER22> The point is not to test the library you're using. Test your own code and assume the library has been taken care (even if there are bugs there).

</comment></comment><comment><USER44> One line in this article may have given me an epiphany: >" If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it."

My primary objection to TDD is that it doesn't seem to work, because when I've tried it, the tests caught no bugs at all. I believe that tests can be important for APIs to prevent regressions when you have to work with external components, but its frustrating to put time into tests and then never have the tests fail.

Its not that I'm a perfect programmer, its the kind of bugs I make. The kind of bugs I make are caught by the compiler. This may be because, over the years of my career (many of which occurred long before the idea of "test first" was widely heard) I've trained myself in a style of programming where I can trust the compiler to catch my mistakes (most of which are typos, frankly.)

I don't know if others can do this, but for me, it came about by doing things like:

Old way: if (variable == 1) then whatever New way: if (1 == variable) then whatever

Every time I mistype that as "(1 = variable) the compiler catches it because I can't redefine 1.

</comment><comment> excuse-me Testing, or at least coding, like the TSA thinks is remarkably common in industry.

TSA logic - somebody tried to get on a plane with a bomb in their show so everyone everywhere has to remove their shoes

PHB logic - somebody somewhere had a bug because of a misuse of inheritance so you aren't allowed to use any inheritance in your C++ code anywhere.</comment>


The Twitter Revolution Must Die - <AUTHOR> http://blog.ulisesmejias.com/2011/01/30/the-twitter-revolution-must-die/

<comment><USER2> Who is calling this the Twitter revolution, besides people like Robert Scoble and Michael Arrington? The tech bloggers of the world might be adept enough at covering the constant soap opera of startup culture (and the relatively very rare technological advances that it sometimes produces), but I think when one of the most important countries in one of the most important regions in the world is on the cusp of a total revolution, we their readers would do well to, well, completely ignore anything they have to say about events of global political importance. When the Howard Zinns of the world start describing the nature of social technology in the Tunisian and Egyptian revolutions, I'll listen. But one shouldn't imagine that somebody on BoingBoing—or even a deeply entertaining futurist like Clay Shirky—is going to be a voice of any substance in analyzing the events of the last couple weeks.

<comment><USER3> @JaredCohen has some pretty interesting things to say:

<http://twitter.com/#!/JaredCohen/status/31726988934778880>

Every Egyptian I talked to on ground this week laughed when I told them some think tech was not a vital tool for organizing #jan25

<http://twitter.com/#!/JaredCohen/status/30662558541152257>

People on ground in #egypt adamant about critical role tech playing in crowdsourcing logistics #jan25

<http://twitter.com/#!/JaredCohen/status/31836874016296960>

Tech doesn't make activists, but creates space for unlikely leaders to emerge and redefine civil society as smthg more inclusive/expansive

<http://twitter.com/#!/JaredCohen/status/30665407077556224>

One Egyptian says, "facebook used to set the date, twitter used to share logistics, youtube to show the world, all to connect people" #jan25

</comment></comment><comment><USER4> The title is hyperbole, but the author makes two good points:

1\. A revolution is created by people, not by technology. Calling the uprisings in Egypt and Tunisia the "Twitter" or "Facebook" revolutions doesn't reflect the reality on the ground.

2\. The more centralised and widely used a networking service like Twitter or Facebook is, the easier it is for governments to control it or use it to track down dissidents.

Very valid and interesting points.

<comment><USER3> I think the article contains a little hyperbole, too.

Leica were not the only manufacturer of cameras while there is only one Twitter.

Blogging, Facebook, YouTube (and no doubt good-old email) have played their part in this but Twitter has a special place in getting information out and to journalists.

There is no other technology that can spread grass roots information as widely or as quickly - especially to important recipients outside of the country. Important twitter messages travel amazing quickly and people seem to inherently pass them in the direction of high-follower and well-connected accounts.

The fact the Egyptian Government turned the internet off and banned Al-Jazeera shows the weight that they placed on these media.

And, while there is a mix of internet technologies being used in these revolutions, the term "internet Revolution" was already all used up.</comment></comment>


Looking for a Venture Capitalist or Angel Advisor - <AUTHOR> http://www.spoiledtechie.com/post/Looking-for-a-Venture-Capitalist-or-Angel-Advisor.aspx

<comment><USER2> A word of advice... You mention having 14 ideas...

Find the 2 or 3 (at most) that seem most viable. Research them, prototype them, find a co-founder. THEN seek angel funding.

Ideas are free, VCs/Angels get thousands of half-baked "idea" pitches regularly. Hard work, data, prototypes, co-founders and enthusiasm are far less common (and you won't convince anyone that you are equally enthusiastic about 14 different things).

If you're just looking for some free guidance, I like your ideas #5, #15 and #8, in that order ;)

<comment><AUTHOR> :) thanks for the free "guidance". I agree with you on finding the most viable. I just wish this process was easier. I wish I could take a few months off work to pursue these business ideas that I have.

<comment><USER3> Go through your ideas and pick the one that you yourself need and that you can make at least a version 1 of in a reasonable time. Then do so, preferably with a friend you've known for a while and who you admire for his/her ability.

This was the recipe for Apple, Microsoft, Google, Yahoo, and many other startups.</comment></comment></comment>


Maze Generation in Thirteen Bytes (2012) - <AUTHOR> http://trixter.oldskool.org/2012/12/17/maze-generation-in-thirteen-bytes/ <comment><USER2> As the article states, it's impressive but _The output isn't really a true maze_.

It looks more like the simplest possible implementation of a diagonal type _Truchet tiling_ algorithm with a single tile and 2 unique rotations:

        "\", "/" rendered as ╲ ╱

[http://en.wikipedia.org/wiki/Truchet_tiles#Diagonal](http://en.wikipedia.org/wiki/Truchet_tiles#Diagonal)

<comment><USER3> The link you provided suggests it is a 'simple maze'? What is a true maze by your definition?

<comment><USER2> One that has at least an entry and a connected exit or some defined goal somewhere in the maze with a connection to the exit.

For proper maze generation see: [http://en.wikipedia.org/wiki/Maze_generation_algorithm](http://en.wikipedia.org/wiki/Maze_generation_algorithm)

Here's a simple JS snippet that overwrites any loaded page in the browser when pasted into the console. Or live here: [http://jsfiddle.net/15fmx4L7/](http://jsfiddle.net/15fmx4L7/)

        var d = document, tiles = ["\u2571","\u2572"], i = 0, s = 12, b, s, l;

        d.open();
        d.write("");
        b = d.body;
        b.style.cssText = "font-size:" + s + "px;"
        b.style.cssText += "word-wrap:break-word;padding:0;margin:0;line-height:100%";
        l = Math.floor(b.clientHeight/s) * Math.floor(b.clientWidth/s);

        while (i < l) {
          d.write(tiles[Math.round(Math.random())]);
          i++;
        }

        d.write("")
        d.close();

It's dead simple and relies a lot on known output formatting, which requires some CSS fluff. The core function though is a simple stream of random code points from a set of two, really nothing spectacular to see here:

        while (1) {document.write(["\","/"][Math.round(Math.random())]);}

This does not generate a maze, it's a pure tiling side effect, which might generate by chance a tunnel through the pattern. If you look closely you'll find no T-type intersections or any other kind of path bifurcation.

<comment><USER4> In K you could do:

        {x}{`0:"/\\"1?2;x}/1

{x}{...;x}/1 is essentially while(true) {}.

`0: writes values to standard output.

"/\\\"1?2 indexes into a two element array given the result of selecting one random result from the numbers up to but excluding 2.

</comment></comment></comment></comment><comment><USER5> My favourite part about this article is that his original solution of 13 bytes was quickly beaten down to 10 by some friendly competition in the comments. Sizecoding may not have any real practical use in most cases, but I think it's still a good form of mental exercise since the type of creative thinking it requires is a useful skill in thinking about other problems too.

<comment><USER6> While I was the beat-down recipient, it was my favorite part too. I have no problem getting beaten if I'm laughing the entire time (same goes for getting my ass handed to me in 1st-person shooters).

</comment></comment><comment><USER7> I love that each step further down in size has you thinking "nope, it won't get smaller". Here is a C64 version in 13 bytes:

        .pc=$7c
        loop:
            lda $d012 ; content of $d012 into accumulator
            lsr       ; shift accumulator right, moving lsbit into carry
            lda #$cd  ; value of diagonal line into accumulator
            adc #0    ; add 0 + carry. if carry, accumulator will hold $ce, opposite diagonal line
            jsr $ffd2 ; call CHROUT in rom; outputs character in accumulator on device
            bcc loop  ; branch to loop if carry is cleared; an effective branch-always which saves 1 byte from a jump

I'm sure it can be golfed further with the illegal opcodes that I am not familiar with.

EDIT: Shed one byte, added comments, moved the origin to $7c which means that adding 2 bytes of header will make it a runnable C64 PRG.

<comment><USER8>
      I'm sure it can be golfed further with the illegal opcodes that I am not familiar with.

Possible. But not necessarily. Long time ago I reviewed the many illegal opcodes of the 6502. Many are simply doing nothing and most of them are not useful at all. The few that are useful give little benefits, because they can be used in very very few situations. I finally did not use them, since I don't wanted to break compatibility with 6502 successors (which where very few, finally).

<comment><USER7> I mean "sure" only as a manner of speaking, not to say that I am absolutely certain. The challenge for me in using the illegal opcodes is internalizing them and recognizing the situations where they can actually be used effectively to save a byte or a cycle. When writing code for platforms with very little memory or harsh time constraints, they can certainly save you headaches. Something like LAX for example can be used to do an y-indexed load to the x register, which often times can save you an accumulator transfer when doing doubly indirect loads.

<comment><USER8> Sorry for the inconvenience. I am not familiar with the details of English language, so sometimes I just understand things wrong.

Yes, there are some interesting opcodes too, but I found their usage so limited, that it was not worthwhile to drop compatibility. Of course, with a fixed setting, where you need every byte .... but I must say, that for me today it is just academic, since I also do no embedded programming today. With computers of today, I still think, that optimizing is worthwhile, but not to that degree, that breaking compatibility makes sense.

</comment></comment></comment></comment><comment><USER9> I grew up with this stuff. Such a long long time ago since I've played at this level of optimisation. Very very very clever.

</comment><comment><USER10> My USENET signature..

      int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
      +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
      ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

</comment><comment><USER11> reminds me old punchcard computer homework days where students competed on the minimal number of punchcards for a homework problem

</comment><comment><USER12> This code displays forward slash and backslash randomly over the entire screen. This may look a bit like a maze, but it is not. Title should read "How to display random garbage to the screen as slashes in 13 bytes". Still impressed?

<comment><USER13> What constitutes a maze? Enforced solvability?

<comment><USER14> Forming a spanning tree; or equivalently, having a unique path between any two cells. Sometimes a few additional connections (adding cycles to the spanning tree) are considered ok.

<comment><USER15> Really, multiply connected mazes are more interesting and more aesthetically pleasing.

A question, though. If, in 2D, having all walls in one piece is simply connected, and having some islands is multiply connected, what are the possible types of 3D maze (let's call it a cave). You can obviously have simply connected walls, or multiply connected walls (floating shells of rock) but what name would you give the type that has some looping paths but no floating rocks? Do we talk about genus?</comment></comment></comment></comment>


Understanding JavaScript Execution Context like never before - <AUTHOR> https://blog.greenroots.info/understanding-javascript-execution-context-like-never-before-ckb8x246k00f56hs1nefzpysq <comment><USER2> Just a general note that the grammar in this article could use some help. I wanted to continue reading but found myself tripping up and losing my train of thought. I'd be more specific if I weren't on mobile.

</comment><comment><USER3> Another good resource for understanding JS execution context: [https://tylermcginnis.com/ultimate-guide-to-execution- contex...](https://tylermcginnis.com/ultimate-guide-to-execution-contexts- hoisting-scopes-and-closures-in-javascript/)

You can use its JavaScript Visualizer to step through the context creation (ES5, doesn't work too well with ES6): [https://tylermcginnis.com/javascript- visualizer/](https://tylermcginnis.com/javascript-visualizer/)

</comment><comment><USER4> Using looping gifs everywhere makes it really hard to focus on the text I'm trying to read.

<comment><USER5> Huh?

Maybe my adblocker is blocking some, but I only counted 4 - and 3/4 are demonstrating execution context. Only 1 is irrelevant.

Also, I thought all gifs looped - or at least, it's common for them to loop.

<comment><USER4> I didn't say that they were all irrelevant, only that they are distracting when trying to read the textual content.

It's possible to do non-looping or at least pauseable either by using a video file (like most "gifs" online do these days) or using JS.

Either way, having stuff move around right next to text you want people to focus on is generally not a good idea.

</comment></comment></comment><comment><USER6> I wonder if I ran this through Google Translate a few times it would become easier to read.

</comment><comment><USER7> Can't remember the last time I cared about the execution context since I use arrow functions everywhere.</comment>


Ask HN: What's your favorite Machine Learning topic? - <AUTHOR> <comment><USER2> Hinton's "capsule networks":

[https://www.wired.com/story/googles-ai-wizard-unveils-a- new-...](https://www.wired.com/story/googles-ai-wizard-unveils-a-new-twist-on- neural-networks/)

[https://www.youtube.com/watch?v=rTawFwUvnLE](https://www.youtube.com/watch?v=rTawFwUvnLE)

[https://hackernoon.com/what-is-a-capsnet-or-capsule- network-...](https://hackernoon.com/what-is-a-capsnet-or-capsule- network-2bfbe48769cc)

They sound a bit like "grandmother neurons/cells":

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

I would very much appreciate an ELI5 of capsules and some prognostications about how capsules may affect the state of the art in neural networks and the current flood of papers and graduate students in the pipeline of ML.</comment>