Why I don't mock - <AUTHOR> http://blog.metaobject.com/2014/05/why-i-don-mock.html <comment><USER2> Mocking is the primary problem with TDD as it exists right now. "Isolated testing" (or isolated TDD) is advocated by people like Uncle Bob. Many developers listen to Uncle Bob and end up believing that unit testing without complete isolation is not "real" unit testing.

Isolated unit testing is supposed to improve your designs. But when you mock everything, you end up with tests that know everything about your implementation (white box testing). The result is that refactoring breaks your tests. Your tests no longer document how to use the system; they are merely a mirror of its implementation.

Kent Beck's central point in his book is that TDD mitigates fear, allows refactoring, and gives you immediate feedback. Extensive mocking makes developers fearful to refactor (thus hurting design) and reduces the quality of feedback. Not to mention it makes your tests hard to refactor too.

Martin Fowler explains the difference between "classical" and "mockist" testing:

[http://martinfowler.com/articles/mocksArentStubs.html#Classi...](http://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting)

<comment><USER3> I spent more time building my mocks instead of building my tests. Sometimes a file might have 90% mocks and 10% tests. Or maybe that's just my mocking framework...

<comment><USER4> The idea is that if you end up with code like this, it shows you have too many collaborators and should refactor them away.

<comment><USER5> Exactly.

An other reason could be it's a main entry point for code execution, a class that only purpose is the glue others.

In that case, having a lot of mocks is a code smell pointing that you should probably test this on the integration level rather than on the unit one (and thus, discard mocks and use "real" everything).

(but beware not to be too much self indulgent on what is a gluing class, most of the time, they are not and it's indeed a god class problem).

</comment></comment></comment></comment><comment><USER6> I found the article disappointing. Instead of giving reasonable arguments against mocking, the author offers an example where mocking was used wrong and therefore propagates that it shouldn't be used at all.

The problem is not mocking. I found it to be absolutely helpful if used right (and right often means sparsely). The problem is this "all or nothing" mentality that many programmers have. Either they mock the hell out of the codebase or they don't use it at all.

I don't use mock objects, unless it's message based business logic, often located at the topmost layer of abstraction.

</comment><comment><USER7> So I do a lot of systems programming type development.

In these cases, whether you're PXE booting a server or talking to 500 different APIs that all range between the latest database or cloud API, flashing firmware on a RAID controller (shudder), whatever, there's a point of diminishing returns. There's also most of the bugs that you won't be able to simulate, because they come from external factors.

The magic lies in automated integration tests.

QA automation is _AMAZING_ stuff. Set up real servers and real test environments when you can. Test real database upgrades.

Mock testing can have it's place, but often you find yourself making internal API contracts more rigid than you want, which can limit refactoring.

<comment><USER8> How do you test your system's response to error conditions? Do you have hooks in your integrated system to force errors (throw exceptions, violate contracts, etc.)?

<comment><USER7> In some cases, yes.

You can do things like set up scenarios you know won't work, such as connecting to machines that don't exist or sending the wrong parameters.

The main thing is if the external inputs can't be made to "violate a contract", the internals aren't the problem.

Ultimately, it depends on what you are building. Simple CRUD web applications are different from systems development type applications in many cases. Many of these classes _can_ be more easily mocked out.

Often the breaking change you'll see is an upstream API or SaaS endpoint changing in ways you didn't expect (or the difference between a Linux utility on the latest Ubuntu, an older RHEL, and Solaris), so it's often better to concentrate on testing the real thing.

And these tests are expensive, so an automated test matrix that deploys a VM fleet with lots of permutations is usually necessary.

</comment></comment></comment><comment><USER9> A big danger with mocks is just shoving the problems under the rug rather than fixing them. Mocks represent assumptions, typically untested assumptions. There is generally nothing enforcing a mock's behaviors to be in accordance with whatever it is mocking, so that leaves it as a free parameter which can easily be incorrect if someone makes an error (which obviously can and does happen).

<comment><USER10> This isn't a danger, it's a benefit: your tests of one unit (whatever you consider a "unit" to be) are isolated from the behaviour of the rest of the system. For example, if you break one part of your implementation, you get one failing unit test, not a thousand.

Checking these assumptions is what integration and acceptance tests are for.

</comment></comment><comment><USER11> As always theres a middle ground between the extremes of MOCK-ALL-TEH-THINGS or mock nothing!!

Since reading Sandi Metz's very fantastic "Practical Object-oriented design in ruby" it clear to me that mocking is great for checking that objects other the one under test receive messages sent by the methods being tested (makes tests easier to setup and write usually). If I find that I'm doing too much mocking, then its usually because the method I'm using is doing way too much. FWIW.

</comment><comment><USER12> I really want to see people's complex projects and example code. There have been way too much opinion on this topic lately without any concrete evidence to show the strengths/weaknesses of using or not using mocks.

<comment><USER13> I can only give you an anecdote as our product is closed source. Mocks went like this, in a bell curve fashion:

1\. Mocks are great, we'll use them everywhere.

2\. Mocks are preventing our tests from being refactored.

3\. Mocks are preventing our code form being refactored.

4\. Mocks are preventing progress on the platform.

5\. Code is being modified and tests and mocks are being removed to keep productivity up.

6\. There are no mocks and few tests.

7\. Tests increase again as defects are found. No mocks required.

This is over the space of 8 years and our problem was the amount of coupling they caused.

<comment><USER6> Mocks don't cause coupling. Programmers do.

<comment><USER14> Cute, but even as terse as this comment is its sentiment is incorrect.

Mocks, almost by their very nature, encourage coupling. Ask yourself the question "What tends to get mocked? " Answer: Objects which are difficult and/or heavy to instantiate, but which are outside of your direct control and cannot be changed, e.g.: database connections, network sockets, etc.

So when you want to write tests around this you are almost forced to mock them out. So you instantiate those classes (as mocks) in your test class, so that the code under test. There are now two references to that class: one in the test, and one in the code being tested.

This is coupling. QED.

<comment><USER10> > Ask yourself the question "What tends to get mocked?"

Answer: every collaborator of the object under test, so that only the tested object is actually having its implementation exercised. All other objects that it needs to talk to — database connections, network sockets, or whatever — are replaced with mocks, and the test subject's interactions with those mocks are verified, so that a) we have confidence that the tested object is interacting with its collaborators in the expected way, and b) the test itself doesn't depend at all on the actual behaviour of those collaborators' implementations, which behaviour should be explicitly exercised elsewhere.

That's the opposite of coupling. I don't understand where your answer comes from or what it means.

<comment><USER7> I view this as definitely enforcing coupling.

The issue is that you should want to make it very easy to change the API signature of internal components.

Mock objects can tend to reinforce internal coding choices when things that are not a public interface, or a service boundary, are mocked out.

If you're mocking at this level, there is a potential for refactoring of intra-class API contracts to become much harder to change.

Thus, it would be better IMHO to mock out only meaningful service boundaries, and concentrate testing at the public contracts.

You can still get very strong coverage, but you're just thinking about a different level of inputs.

</comment></comment></comment></comment></comment></comment><comment><USER15> I don't use mocks much, except with regard to the "now" method. There's some code that relies on the current time, I can use mock to mock many values of 'current time' instead of being forced to only test the case where the current time is when I run the unit test. This is especially important when dealing with code involving time zone and day light savings.

<comment><AUTHOR> My experience with time is that whenever you build a system that is time- dependent in any meaningful way, you want to have "synthetic time" that you control, which you only feed with real time in a single, controllable place.

Otherwise you get nasty effects, such as time moving on while your system is processing etc.

<comment><USER15> I'm guessing you mean like:

        def has_expired(now=None):
            #.. implementation

instead of:

        def has_expired():
            #.. implementation

But at some point you need to call that method somewhere else...

        def get_request_handler(request):
            #...code
            now = timezone.now()
            if has_expired(now=now):
               raise Error403.

And `get_request_handler` still needs to be tested, which I 'stub' the API for getting the current time in the correct timezone within the test for the request. (Taking into account the other comment), using a library called 'mock'. ([https://pypi.python.org/pypi/mock](https://pypi.python.org/pypi/mock))

</comment></comment></comment><comment><USER16> I think OOP is exposing serious flaws in how humans write software and solve problems. I'm not sure, but it seems there is an impedance mismatch in how we write code, and how we'd like to test code, but there is a reluctance or outright defiance toward the idea of writing testable code.

The FP community doesn't seem to have a problem so much with testing simply because they mostly write pure functions that are data in -> data out and that is the easiest thing in the world to test.

It occurs to me that most developers aren't writing testable OO code, and thus we have a never-ending argument about the most clever way to test (or not test) code that is not easily tested in isolation.

If we never get around to writing testable code, we aren't going to have systems that are easy to test. If we don't have easy to test systems, testing is going to suck and people won't do it.

I don't know that FP is the answer, but just asking people to write better OO systems isn't working. The problem certainly is more fundamental than simply TDD or mocking or whatever language or tool we are using.

The problem is in how we look at solving problems in code and how that relates to system maintenance over time. It's a people problem, not a tooling one.

<comment><USER17> I don't think there is enough of an FP community doing large, heavily tested systems to allow accurate generalisations like that. I can think of plenty "We used FP, and everything went better than expected!" articles, but you probably don't hear from the people who tried, but came across problems.

<comment><USER16> I agree, and I don't know that FP is the solution.

I just know that the OO design approach isn't working super well with the people who are using it, and we now have a couple decades where design hasn't progressed significantly on the average project.

So, how to we change the human behavior that is leading to less than ideal outcomes?

</comment></comment></comment><comment><USER18> While I think I get where the OP is going, this seems just too easy to claim without any real-life code. So let's try this then. The last time I used mocks: we're interfacing with motor control hardware.

In code we have interfaces for axis configuration, axis movement and so on. All implemented for different controllers. On top of that there's a layer defining specific movements. Say you want to go from point a to b while avoiding c, there's a piece of code that calculates a route (so it needs axes configurations for max velocity/range/...) and another piece that applies this route to a set of axes (so it needs axes to drive).

Apart from dragging around a bunch of motors everywhere I code, how am I supposed to properly test those two pieces without any mocks? Telling me the design is all wrong to start with is fine, but then you also have to come up with a better one of course :). Telling me that route calculation shouldn't depend directly on axis configuration but should use it's own configuration type and I should then add a conversion between the two is also no solution as it a) introduces an extra layer and b) still requires a mock to test the conversion, d'uh :)

</comment><comment><USER19> There's a time and place for various tools. Mocking isn't all good, it's not all bad. Sometimes it's a good tool for accomplishing an immediate goal. Sometimes it's a crutch that encourages poor design. Keep an open mind and make evidence-based decisions. Only Siths deal in absolutes.

<comment><USER20> "Do or do not. There is no try". Absolutely.

</comment></comment><comment><USER21> I don't understand how you can be 100% against mocking. When I want to visualize testing, I often find it useful to think about how it's applied in the real world. For example, when building a car, the parts are tested in isolation (for the most part). Individual parts are tested - size, shape, stress, etc. Groups of parts are also tested in isolation. For example, the engine is actually connected to a mock drivetrain, mock computer, mock user inputs, etc. I see that as useful, and I think the same goes for software. It can simply be too costly in terms of time, bandwidth, etc to test against real resources.

</comment><comment><USER22> Good points... but what happens when you walk into a legacy code base with few tests that wasn't designed to be tested and is tightly coupled to a component such as a database?

</comment><comment><USER23> I dislike the "that's not supposed to throw an exception" developer statement, if something is not supposed to throw an exception under normal operating you can almost guarantee that it will throw exceptions in the demo. So one of the few cases where I use lots of mock is in Exception Handling.

Some exceptions are almost impossible to generate consistently in tests, or can't be simulated easily next to test that are supposed to pass when that exception state doesn't occur - think API failures, databases being yanked mid-query, etc.

</comment><comment><USER24> I had a random idea the other day to create a program that monitors/logs system level calls and lets you replay them for a program. This would effectively let you use your program as normal, log any actual pieces that use external resources, and then automatically use the saved results as part of your test framework by overriding those system calls at the appropriate time.

Is anyone aware of a solution like this? I certainly don't have time to create it but I would definitely find it useful.

<comment><USER25> We have something like this at the company I work for. We have a "simulation layer" which wraps ALL third party code. This lets us simulate the failure of file system calls, network drivers... And we use it to write our tests.

</comment></comment><comment><USER26> TFA says "For example, when building SportStats v2 at the BBC we thought we needed a database for persistence. But we didn't build it in until we needed it, and we didn't mock it out either. We waited until the code told us that we now needed a database. It never did"

So they seem to be saying "if you write code upfront before you need it, you might not need it, therefor mocking is bad"

IMHO, that is not a valid conclusion to draw.

<comment><USER27> I agree with you, that seems to be what the author is saying, and his conclusion doesn't follow. Also, I'm not sure if he really means mocking or any kind of test doubles.

I thought everyone agreed that writing code upfront before you need it is always a bad idea, _especially_ specific implementations like a database.

</comment></comment><comment><USER28> So, a lot of ideas are thrown here without any real use cases.People say "mocks are bad,whitebox testing is bad".But how can I unit test anything without mocks?

let's take javascript.I cant generate mocks from my code,i have to write them.I have this data access object that takes a connnection.

        var dao=new Dao(connection);
        dao.getById(1,function(err,res){ console.log(res) });

Tell me how do I unit test getById in isolation without mocking connection,without doing whitebox testing,without knowing what actually happens in my getById.

the obvious thing here is to spy on a hypothetic connection.query, fake a db call and return a predictable result.I cant do anything without a mock.

</comment><comment><USER29> Mocks shouldn't be the first resort; they're there as a way to allow you to test code that you can't improve right now. I wouldn't want to use them on new code, but as a stepping-stone for testing and improving a large existing codebase they have their place.

<comment><USER10> That's not what they're for! Mocks allow you to design the interface of a new object by implementing that object's collaborators before you implement the object itself. This is a very high-fidelity source of information about what the interface should look like; anything else is just (educated?) guessing.

<comment><USER19> That may not be what they're "for" (wtf does that even mean?) but they're a damn good use of mocks. You can't fix everything right now.

<comment><USER10> > That may not be what they're "for" (wtf does that even mean?)

It means that "[mocks are] a way to allow you to test code that you can't improve right now" and "[mocks are] a stepping-stone for testing and improving a large existing codebase" is a mischaracterisation of the role and benefits of mocks.

If using them like that is useful for you then that's great, but it's misleading to say that that's why "they're there".

Steve Freeman & Nat Pryce's book [0], for example, is an excellent illustration of what mocks are for.

[0] [http://www.growing-object-oriented-software.com/](http://www.growing- object-oriented-software.com/)

</comment></comment></comment></comment><comment><USER30> I'm new to mocking (to serious unit testing, really), is mocking functions of 3rd-party libraries and/or web API's recommended? It sounds like a good idea, especially for functions that need to hit the network for a web API, but maybe I'm missing something?

<comment><USER31> I would say it's generally a bad idea to mock 3rd party libraries. It's code that's not under your control and testing with a mock which may not match the actual behaviour could cause you trouble. In the case of network requests, something like VCR[1] helps a lot.

[1] [https://github.com/vcr/vcr](https://github.com/vcr/vcr)

<comment><USER26> I would disagree. If you want to unit-test your code that depends on those 3rd party libraries, then your choices are to:

1) Use the real thing. This can be slower and a lot less reliable.

2) Capture some typical output of the 3rd party api, and make a mock that emits it.

Which technique is useful? Both are. But the second one gives you fast-running fine-grained repeatable unit tests so therefore is your first line of testing.

So you discover in an integration test (#1) that the live api has a behaviour that the mock doesn't, maybe an occasional malformed response due to an error at the other end. Great, capture it and add it to the mock. Now you can reproduce it at will and write fast tests on how you handle it.

<comment><USER32> 3) Define a Gateway interface (e.g. DataStoreGateway) that presents exactly the API you want to consume; write one implementation of it that speaks to your third-party API (e.g. ODBCDataStoreGateway), and another that doesn't do much (e.g. MemoryDataStoreGateway).

Note that a trivial gateway-implementation, like MemoryDataStoreGateway, isn't a mock! It's a fully-functional component that works perfectly well from its consumers' perspectives. But, unlike the version that consumes a third-party component, it doesn't have nearly any failure modes that would confuse your tests. It just does what it does, simply, and lets your tests test what you're trying to test.

And note that when you stop mocking, and limit yourself to switching out fully-fledged gateway implementations, "dependency injection" stops being this huge pain with Factories and heavily-parameterized initializers. Instead, you can just make your objects discover their collaborators through a service registry. Your unit tests just register the trivial implementations in the service registry on setup().

\---

† Don't get a bad taste in your mouth thinking about Spring here. A simpler, healthier example is Erlang's "global" module ([http://erlang.org/doc/man/global.html](http://erlang.org/doc/man/global.html)).

<comment><USER26> > But, unlike the version that consumes a third-party component, it doesn't > have nearly any failure modes that would confuse your tests.

That's all fine until you need to test handling the third-party component's failure modes.

> Note that a trivial gateway-implementation, like MemoryDataStoreGateway, > isn't a mock!

Probably not. Though it depends at which point you insert the "trivial" components. If you're using a trivial component to unit test a collaborating class that isn't at the edges of the system, then that's a mock and it's helpful. It's not the _only_ helpful technique or even the usual one, but "mocks are never helpful, always avoid them" is silly thing to say.

A mock store for one unit test is far more lightweight than a MemoryDataStoreGateway, and allows an easy way to simulate server errors, so sometimes it is a better thing to code.

> This is what "dependency injection" is really about, actually: not inserting > mock-objects ... but rather allowing you to plug in ... versions of your > collaborators.

It can be about both. They are not exclusive.

> Instead, you can just make your objects discover their collaborators through > a service registry

You may be happy with every object reaching out to a global singleton. But I'm going to stay well away. Thanks but no thanks.

<comment><USER32> When you're testing the third-party component's failure modes, the tests you're writing are _functional tests_ belonging to the nontrivial gateway implementation (e.g. ODBCDataStoreGateway).

The important thing about the gateway _interface_ is that it's an _error boundary_ : you don't need to think about "server errors" when dealing with a DataStoreGateway; DataStoreGateways don't _have_ server errors. The ODBC object the ODBCDataStoreGateway holds might hand it a server error, but it won't _propagate_ that back to you. It'll just put out a plain† DataStoreGateway::InsertError or somesuch.

† The exception should probably hold a copy of the implementation-exception that triggered it, but this is just for the sake of debugging the implementation. The client should never unwrap the internal exception.

<comment><USER26> > you don't need to think about "server errors" when dealing with a > DataStoreGateway; DataStoreGateways don't have server errors.

I'm not sure why you even make that distinction. More than once I've dealt with servers that occasionally time out and fail; (say once a week or so). I wish to test what I show on my UI under those conditions, and what part of the text and status codes returned from the remote server that _represent_ (or whatever) its failure I will choose to display.

Doing so without using a mock seems pointlessly obtuse and roundabout when I can make a mock to insert whatever error response I want at any interesting point in my code.

<comment><USER32> Split that problem into two problems:

1\. Your collaborator cannot be reached.

2\. Your client has a network connectivity problem.

I've never seen a client who needs to know #1. All they care about is that there was a DataStoreGateway::TransientInsertError, and that TransientInsertErrors mean retrying and notifying the UI that their work hasn't been committed yet.

#2 isn't a problem the DataStoreGateway should be responsible for, because it will affect almost everything in the system in one way or another, and you don't want to have to write that code repeatedly. It's more likely a kind of Alarm--the kind of thing that gets pushed out from wherever it is to a global alarm handler, which then does something like putting the UI into a different root view-controller state, e.g. darkening it and covering it with a modal saying "lost connection."

<comment><USER26> Actually no, it was not either of those cases, it was what I said. The APIS that I'm working with aren't that much like a DataStoreGateway.

Your design points may be valid, but they don't really talk about mocks; why bend over backwards to avoid testing using a mock?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> Was hoping to read an admonition against excessive snark and bullying in Hacker News comments. Ah well.

</comment><comment><USER34> Mocking helps with feature isolation. If a test failed you can be sure it was because of the use case of the test.

Mocking helps when you are calling into code that you can't control. E.g, when calling into an API that is broken and sometimes returns incorrect results.

I don't write very many tests anymore. I haven't mocked an object in years. I also have a lot of bugs in my code.

<comment><AUTHOR> _Mocking helps with feature isolation._

By enabling isolation in the test, mocking reduces the pressure to design more isolated code.

 _Mocking helps when you are calling into code that you can 't control._

Pervasive mocking helps isolate you from the pressure to remove (deep) dependencies on code that you can't control. Redesign your code so it only interacts with such code at the edges. At those places, create APIs that are independent of the code you can't control, and adapt that code to fit your APIs.

<comment><USER22> "Redesign your code so it only interacts with such code at the edges."

yeah, and what if you don't have time to do this? sometimes mocks are appropriate because of schedules and other priorities. Much better to mock than to not write tests because mocking is not pure.

<comment><USER35> Quit? Before it makes you quit?

If your schedules and other priorities are against fixing broken code, I'd be leery of your organization's long-term health. If you're in for the long haul --and at my current gig I certainly am--then eliminating bad code (and any code as tightly coupled as what you describe) is the only sane option. Because it'll kill you eventually.</comment></comment></comment></comment>


Show HN: A curated list of awesome lists - <AUTHOR> https://github.com/sindresorhus/awesome

<comment><USER2> Why are you not curating a curated list of curated curating-lists?

<comment><USER3> This is what you're looking for: [https://github.com/sindresorhus/awesome- awesome-awesome-awes...](https://github.com/sindresorhus/awesome-awesome- awesome-awesome)

<comment><USER4> Wow, that escalated quickly.

</comment></comment></comment><comment><USER5> this is like Yahoo when it was on the buffalo server</comment>


Snowden-haters are on the wrong side of history - <AUTHOR> http://reprog.wordpress.com/2014/01/20/snowden-haters-are-on-the-wrong-side-of-history/ <comment><USER2> I don't understand this article. Unless its author can predict the future, or knows a lot of things that nobody else in the public knows, they can't possibly draw conclusions about exactly what Snowden did.

Snowden himself has made it clear that he took documents from NSA _en masse_ , far more documents than have ever been disclosed in the media.

How many of those documents have been released to the press? We don't know. But what we do know is, of the documents he gave to the press, only a subset have been released. In Greenwald's case, that's because it was decided that a titrating drip of stories would keep the narrative alive in the media and, not coincidentally, better serve the interests of the publications releasing the stories. In other cases it's because journalists have resisted full disclosure out of concern for its propriety.

What's been done with the zero to a billion documents that haven't been provided to the press? Who knows? Have they been encrypted and stuck on the Internet as an insurance policy? Have they been provided to Russian intelligence? Were they stolen from Snowden in an embassy in China? Are they vouchsafed with his acquaintances? Does Wikileaks have them? Nobody knows. Including the author of this blog post.

There are places those documents can go that will alter history's judgement on Snowden. For instance, if he offered wholesale access to US intelligence secrets to Russia, a country which painstakingly and overtly spies on its own citizens and routinely kills journalists (Barton Gellman is not in hiding in the US, for what it's worth), there aren't going to be any adoring spreads about him my grandkid's history book.

You can tell by the questions that jump to my mind what I generally think of Snowden. But nobody who (a) is skeptical of Snowden and (b) posts on Internet message boards could possibly be unaware of how out-on-a-limb that impression must be, because Snowden skepticism invariably whips up a frothy swell of criticism. Unfortunately, the author of this blog post doesn't seem to have the benefit of a critical readership; it's clear that he hasn't actually thought through what's happened.

<comment><USER3> Where I have a hard time with the "Snowden as hero" storyline is my nagging suspicion that he make very clear and deliberate attempts to place himself in a position to have access to these materials for the express purpose of stealing them.

He was essentially fired from the employ of the CIA only to find another position at NSA. Apparently the CIA got wise to his attempts and shut him off. The NSA wasn't so lucky.

None of this detracts from the disclosures of NSA overreach. But we would be foolish to discount the possibility that all of this is a huge smokescreen for a concerted and consistent attempt to weaken or expose US intelligence operations. The fact that an impingement of our sources and methods helps our adversaries cannot be understated.

<comment><USER4> >He was essentially fired from the employ of the CIA

No, he was not:

"The C.I.A did not file any report on Snowden indicating that it suspected he was trying to break into classified computer files to which he did not have authorized access while he was employed at the C.I.A., nor was he returned home from an overseas assignment because of such concerns," Todd Ebitz, an agency spokesman, said in the statement.

[http://www.nytimes.com/2013/10/12/us/cia-disputes-early- susp...](http://www.nytimes.com/2013/10/12/us/cia-disputes-early-suspicions- on-snowden.html)

<comment><USER3> Did you read that article? I did when it was first published.

Are we really at the point where we take the word of an "agency spokesman" and not the sourcing of the journalists who quoted two unnamed sources to verify the story?

<comment><USER4> Yes, I did read the article. Here is Snowden's account:

>Mr. Snowden said that in 2008 and 2009, he was working in Geneva as a telecommunications information systems officer [...] He began pushing for a promotion, but got into what he termed a "petty e-mail spat" in which he questioned a senior manager's judgment.

>Several months later, he was writing his annual self-evaluation when he discovered flaws in the software of the C.I.A.'s personnel Web applications. He warned his supervisor, but his boss advised him to drop the matter. After a technical team also brushed him off, his boss finally agreed to allow him to test the system to prove that it was flawed.

>He did so by adding some code and text "in a nonmalicious manner" to his evaluation document that showed that the vulnerability existed, he said. His immediate supervisor signed off on it and sent it through the system, but a more senior manager — the man Mr. Snowden had challenged earlier — was furious and filed a critical comment in Mr. Snowden's personnel file.

[http://www.nytimes.com/2013/10/18/world/snowden-says-he- took...](http://www.nytimes.com/2013/10/18/world/snowden-says-he-took-no- secret-files-to-russia.html?pagewanted=2)

<comment><USER3> Riiiiight.

So the local IT guy goes looking for vulnerabilities, finds them, SAYS he tried to alert people, then runs an EXPLOIT, and he's mad because he got a ding in his personnel file?

He did know that he was working for an intelligence agency, right? In what world is it acceptable to run an exploit on your company machines if it's not your job to find those exploits? A little Occams's Razor goes a long way.

<comment><USER4> I'm not going to get into a discussion about whether he should've rocked the boat or not.

My only point was that your assertions earlier in the thread were shaky, at best, especially considering Snowden's corroboration.

Or is there any other evidence besides the two unnamed sources who contradict the official CIA account?

<comment><USER3> And my point is that you can't take Snowden's assertions at face value. His behavior doesn't comport with someone who was a patriot and found himself facing a difficult decision to disclose.

It's far closer to that of a "mole".

<comment><USER4> >And my point is that you can't take Snowden's assertions at face value.

Good thing we aren't taking them at face value, seeing as the CIA spokesman lightly corroborates his account rather than your assertion that he was fired for attempting to access and steal classified materials at the CIA.

And while we're on the subject of "moles," neither the internal NSA investigation nor the FBI investigation has found anything supporting your conspiracy theory to date.

<comment><USER3> What conspiracy theory? Do you really think that if there was real evidence that a foreign power was involved that the administration would be up-front with that information? What if the whole purpose of the action is to make them guess if the Russians and/or Chinese have copies of the documents?

Not knowing for sure what the exposure is fuels the nightmares of the whole NSA. What if the Russians and Chinese know EVERYTHING?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> So I'll put forward a controversial, but hopefully _true_ point: If you believe in the Rule of Law, then Snowden should be tried, and probably will be found guilty, for a fairly clear breach of the law. The US President is bound by the constitution to use every means available to go after him.

Presidential pardons, although they are part of the US consitution and therefore strictly speaking part of the Rule of Law, are very capricious tools and not really in the spirit of it.

Of course this is why we shouldn't have secret laws or secret parts of government, and national parliaments weren't doing their job to get us into this situation in the first place. And we weren't doing _our_ job either, by not holding politicians to account and being apathetic about voting.

<comment><USER6> Come now, Citizen! "Rule of Law"? How old-fashioned of you!

Snark aside, what I don't understand is this: If it means so damned much to Snowden that he should expose all these supposedly horrible supposed abuses, then why isn't he willing to suffer the consequences of his treasonous actions?

The original article is so hot to compare Snowden with Dr. King, but what everyone seems to ignore is that _Dr. King did not seek to escape the consequences of his actions._ Indeed, he turned those consequences into a cornerstone of his arguments, and they were in large part what drove his movement to eventual victory.

Dr. King and his confederates in the Civil Rights movement, put simply, possessed the courage of their convictions. Edward Snowden, by comparison, has shown nothing but cowardice; having stolen the secret documents on which Glenn Greenwald is turning such a tidy reputational profit, Snowden fled like the thief he is and begged asylum from nations which, while not belligerent enemies of the United States, certainly have no reason to wish us well.

In short, the man is no lion, but a weasel; no hero, but an arrant coward. Have we, in a few short decades, become so debased, so degraded, that no one can any longer tell the difference?

<comment><USER7> Wow, how hateful of you. Do you not see the obviously glaring difference between the two?

I don't believe that Dr. King had the likelihood of being tortured and executed by his own government for pointing out the mistreatment, illegal or otherwise, of his people by that very government.

I do believe that Snowden is under a direct threat of possible execution and potentially being tortured, depending on the current definition of torture I suppose, by his own government for pointing out the illegal activities of said government aimed at its citizens.

You complain the post is hot to compare the two, maybe you should refrain from doing the same.

Snowden has shown the government to be corrupt in his eyes and now you expect him to directly face that very government on their grounds and on their terms? That seems to be a foolish thing to do. You may label the man however you like, I'll wait to see how history plays out a bit and see more of the evidence before making a judgement.

</comment></comment></comment><comment><USER8> _> An actual spy would have quietly disappeared with the damaging intel, and no-one in America would ever have known anything about it._

And chances are one probably did. It's one of the risks of amassing that much private information in a single place. You become a juicy target.

<comment><USER9> I'm pretty sure CIA is protecting him very carefully, preventing him from having conversation with any non-US intelligence agencies, and preventing him from getting killed (which might trigger some "insurance" mechanism that would release the documents).

<comment><USER10> > preventing him from having conversation with any non-US intelligence > agencies,

How would they do this?

<comment><USER9> I guess by being near him. If my theory is correct, Snowden want's them near him, protecting him against non-US spies, who would like to kill him (and thus cause the release of the remainder of the documents).

<comment><USER10> Can the CIA operate overtly in Russia like this? The Russians don't mind?

</comment></comment></comment></comment></comment><comment><USER11> I don't think this is a valid argument. It seems to be "I'm right because I believe people in the future will agree with me". Maybe so but the author can't know that until the future comes.

<comment><USER12> That isn't the argument at all. The author is not saying "in the future Snowden will be a hero, therefore let's make him a hero in the present to align ourselves with history". That is not a good argument because history is not moral, and just because things happen it doesn't make them right.

What he is saying is that society is currently evolving in a direction of openness and transparency, and of holding those in power to account. This trend is visible right now; it's not a prediction.

<comment><USER13> What are the visible signs that "society is currently evolving in a direction of openness and transparency, and of holding those in power to account"? Sure seems like the public at large is ambivalent at best to my eyes, but love to hear otherwise.

<comment><USER12> That's how I read the author's argument. Doesn't mean I agree with him; I would agree with you that the signs are ambivalent at best.

</comment></comment></comment></comment><comment><USER14> _The only thing necessary for the triumph of evil is for good men to do nothing._ ~Edmund Burke

As someone who wholeheartedly agrees with Snowden being one day vindicated as a hero, it's tempting to nod my head silently and move on to the next article.

The problem is the critics. They will be vocal. They will openly condemn Snowden. Many have never done anything courageous in their life or stood up on moral grounds. Morality is just an antiquated concept to them. Just another word to dilute and distort.

So I'll speak up and say that Snowden is a hero, and I'll take one hero over a pack of cowards any day.

</comment><comment><USER15> Commenting on the comments, not the original post. Seems to me there's some confusing of issues going on. MLK vs Snowden is not a reasonable comparison -- one was a lifelong activist and the other is a first-time whistleblower. Their roles and goals dictate different actions, including whether to stay put or run, among other things. Secondly, the issue of the legality of NSA actions versus their constitutionality is quite different. Laws can be found unconstitutional. So while the NSA was ostensibly following the law, Snowden claims they were violating the constitution. One does not invalidate the other.

</comment><comment><USER16> Regardless of my own beliefs about the matter, which I'll leave out of here, I couldn't get past the massive logical fallacy that this article seems to rest on: The goverment doesn't like Snowden. The government didn't like MLK and MLK was a good guy, therefore Snowden must be a good guy as well.

</comment><comment><USER17> I am surprised if I see people trained in critical thinking not supporting the humanity hero Snowden.

Just think of the immediate economic impact of US tech and US tech services not able to export. He is trying to fix that. And long term, if people don't have free will they won't work as hard.

And worst, the information will be used for political reasons, not state reasons. The political party in power stays in power. (that is why _THEY_ like it, the 10% approval ratting corrupt congress)

</comment><comment><USER18> Snowden is in no way equivalent to King.

Never in a long run. King stood up to his foes, Snowden ran.

<comment><USER19> In a world where your "foes" have shown a willingness to torture, kill, and use every sneaky, subversive tactic in the book (c.f. pvt. Manning) across all borders to annihilate those it's decided, wrongfully or not, are enemies, what good do you think would come of Snowden returning to the USA?

Does it take someone being tortured to sate your moral compass?!

Further, him "standing up" as you and so many others seem to want him to do would undermine the whole reason he leaked the NSA stuff and took off in the first place. He'll disappear into some military (or worse) prison somewhere and never be heard from again.

<comment><USER2> It is pretty offensive to the memory of MLK to suggest that the treatment that awaited Snowden at the hands of the DOJ was in any way comparable to what faced the Montgomery Improvement Association. MIA activists were beaten, raped, lynched, and tortured in public with clubs, dogs, and firehoses.

<comment><USER19> So we've ostensibly replaced physical torture with mental. The effect on the person isn't any less detrimental.

<comment><USER2> You think the Montgomery activists weren't tortured mentally as well? Their children were being threatened.

<comment><USER19> Who said they weren't?! If you put the unaccountable "enhanced interrogation" users at the NSA above threatening children if they think that will get them what they want, you've got a much higher view of these people than most. The point that you seem to be dancing around recognizing is that all torture is bad, regardless of degree.

<comment><USER2> NSA has no interrogation capability at all. I no longer understand what you're talking about. Regardless, I feel pretty confident that what MLK and his associates faced is far worse than anything Snowden faces, at least from the US. Who knows where things will go in Russia.

<comment><USER19> If you believe in the concept of "degrees" of torture, at least. It's all wrong on every conceivable level. You don't need to ever lay a finger on someone to break their mind and leave them permanently damaged.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> The wrong side of a progressive history, maybe. If Martin Luther King is the benchmark for someone on the right side of history, I'd advise finding an online article about him, published on a major newspaper site, and reading the comments.

He is still universally despised by the children of John Birch.

</comment><comment><USER21> It is really a question of which group is most naive. Is the threat from terrorism larger than the threat of un-patched vulnerabilities in vital software. At the moment the response to these "issues" is mutually exclusive. Only time will tell.

<comment><USER2> The NSA doesn't create vulnerabilities in software. (If you think they do, you can argue equally persuasively for the NSA's role in hiding aliens at Area 51).

The strongest argument you can make about NSA's malign role in software security is that, by buying vulnerabilities from people who would otherwise sell them to vendors, NSA is retarding third-party security research and slowing the mean time to discovery for new vulnerabilities.

I'm disquieted by that notion too (it's been a little while since I found the kind of vulnerability that sells for real money --- those are very particular kinds of flaws, contrary to popular opinion --- but I've had a "no selling vulnerabilities" rule for a long time). But I'm not naive. Most of the people who would sell vulnerabilities to NSA probably weren't in a hurry to share them with vendors anyways. And part of the reason for that is, vendors feel entitled to security research about their products, even though they refuse to pay for it. They were outbid even before NSA came along.

<comment><USER22> >The NSA doesn't create vulnerabilities in software.

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

<comment><USER2> Not the kind of vulnerability I inferred the parent commenter to be referring to, or the kind considered by the reaction to the President's NSA committee and new NSA guidelines. I agree, BULLRUN is one of the very significant and important disclosures; probably the most important.

</comment></comment></comment></comment><comment><USER23> What I think needs to exist is a similar protection government has, national interest. I think there should be, in all democracies, a defence of national interest. The law should never be allowed to obstruct the truth.

<comment><USER24> Where's the national interest in revealing how the US and its allies' intelligence services target adversaries like China and Russia, international drug cartels and terrorist networks?

<comment><USER7> From what I've seen a great deal of the materials released so far show how the US spies on everyone but the examples you cite, including these allies you speak of.

Have there been examples in the Snowden materials of how the US spies on "adversaries" such as Russia and China? I didn't even realize that those were adversaries in the traditional sense that justifies such intrusions in everyone's lives.

<comment><USER24> [http://www.nytimes.com/2014/01/15/us/nsa-effort-pries- open-c...](http://www.nytimes.com/2014/01/15/us/nsa-effort-pries-open- computers-not-connected-to-internet.html)

[http://www.independent.co.uk/news/uk/politics/exclusive- uks-...](http://www.independent.co.uk/news/uk/politics/exclusive-uks-secret- mideast-internet-surveillance-base-is-revealed-in-edward-snowden- leaks-8781082.html)

<comment><USER7> I can't read the first article as it is behind a paywall. It starts with the NSA installing software in nearly 100,000 computers worldwide to conduct surveillance. I suppose it explains somewhere after the paywall of how they use that to spy on adversaries such as China and Russia?

The second one seems to be more about the British spying on the Middle East of which they share information with the NSA. I admit I skimmed it but does it accuse the NSA of spying on adversaries such as China and Russia?

So far, they just seem to spy on everyone.

</comment></comment></comment></comment></comment><comment> sTevo-In-VA He should be buried with honors.

</comment><comment><USER25> Great read, thanks

</comment><comment><USER26> Best part of this article, the phrase "For the hard of thinking"

</comment><comment><USER27> What's all the fuss about? I for one welcome our skynet overlords. Privacy is obsolete. All knowing omniscient corporations are the future!</comment>