Why Most Unit Testing Is Waste [pdf] - <AUTHOR> https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf <comment><USER2> The normal practice for large scale codebases in complex domains is "the code is the spec". That is, the only specification for how the system should work is how it worked yesterday. In that case, unit tests serve as a great specification. Even tests that just duplicate the business code under test and assert that it's the same (A huge waste in normal cases) is useful. Because a Unit test is much better than a word document in describing how code should behave. I very much prefer a massive, hard to maintain set of poorly written unit tests, to a large number of outdated documents describing how every bit of the system should work.

So is a big/bad test suite a burden? Sure. But is it a burden compared to maintaining specifications of other kinds? Is it a burden compared to working in a system with neither type of specification?

Further, the people writing long articles like this are (or at least were) very good developers. There is often an element of "good developers write good code, so just use good developers" in them. But writing good software with good developers was never the problem. The problem is making software that isn't terrible, with developers ranging from good to terrible, and most being mediocre.

<comment><USER3> The article addresses your first point in a big section:

1.4 The Belief that Tests are Smarter than Code Telegraphs Latent Fear or a Bad Process

Your other point about only good programmers not needing unit tests is moot as you haven't followed it through to the conclusion. Namely, if bad programmers write bad code that needs unit tests, they're also going to write bad unit tests that don't test the code correctly. So what's the point?

<comment><USER4> > Namely, if bad programmers write bad code that needs unit tests, they're > also going to write bad unit tests that don't test the code correctly. So > what's the point?

Let's assume you hire _good_ programmers, because otherwise you're doomed. But oftentimes, the "good" programmer and the "bad" programmer are the same person, six months apart:

1\. John writes some good code, with good integration tests and good unit tests. He understands the code base. When he deploys his code, he finds a couple of bugs and adds regression tests.

2\. Six months later, John needs to work on his code again to replace a low- level module. He's forgotten a lot of details. He makes some changes, but he's forgotten some corner cases. The tests fail, showing him what needs to be fixed.

3\. A year later, John is busy on another project, and Jane needs to take over John's code and make significant changes. Jane's an awesome developer, but she just got dropped into 20,000 lines of unfamiliar code. The tests will help ensure she doesn't break too much.

Also, unit tests (and specifically TDD) can offer two additional advantages:

1\. They encourage you to design your APIs before implementing them, making APIs a bit more pleasant and easier to use in isolation.

2\. The "red-green-refactor-repeat" loop is almost like the "reward loop" in a video game. By offering small goals and frequent victories, it makes it easier to keep productivity high for hours at a time.

Sometimes you can get away without tests: smaller projects, smaller teams, statically-typed languages, and minimal maintenance can all help. But when things involve multiple good developers working for years, tests can really help.

<comment><USER5> Here's the crux of your argument - and I honestly think it's a flawed premise: The failure of unit tests indicates something other than "Something Changed".

Were the failing tests due to John/Jane's correctly coded changes, regressions, or bad code changes? The tests provide no meaningful insight into that - it's still ultimately up to the programmer to make that value judgement based on the understanding of what the code is supposed to do.

What happens is that John and Jane make a change, find the failing unit tests, and they deem the test failures as reasonable given the changes they were asked to make. They then change the tests to make them pass again. Again, the unit tests are providing no actual indication that their changes were the correct changes to make.

WRT the advantages:

1\. "design your APIs before implementing them" \- this only works out if we know our requirements ahead of time. Given our acknowledgement that these requirements are usually absent via Agile methodologies, this benefit typically vanishes with the first requirement change.

2\. "makes it easier to keep productivity high for hours at a time" This tells me that we're rewarding the wrong thing: the creation of passing tests, not the creation of correct code. Those dopamine hits are pretty potent, agreed, but not useful.

<comment><USER6> >> Here's the crux of your argument - and I honestly think it's a flawed premise: The failure of unit tests indicates something other than "Something Changed".

Even if all you know is "something changed", that's valuable. Pre-existing unit tests can give you confidence that you understand the change you made. You may find an unexpected failure that alerts you to an interaction you didn't consider. Or maybe you'll see a pass where you expected failure, and have a mystery to solve. Or you may see that the tests are failing exactly how you expected they would. At least you have more information than "well, it compiled".

And if "the unit tests are providing no actual indication that their changes were the correct changes to make", even the staunchest proponents of TDD would probably advise you to delete those tests. If there's 1 thing most proponents and opponents of unit testing can agree on, it's probably that low-value tests are worse than none at all.

I have no idea if this describes you, but I've noticed a really unfortunate trend where experienced engineers decide to try out TDD, write low-value tests that become a drag on the project, and assume that their output is representative of the practice in general before they've put the time in to make it over the learning curve. People like to assume that skilled devs just inherently know how to write good unit tests, but testing is itself a skill that must be specifically cultivated.

<comment><USER7> Somebody could do the TDD movement a great big favour and write a TDD instruction for people who actually already know how to write tests.

There probably are good resources about this somewhere, but compared to the impression of "TDD promotes oceans of tiny, low-value tests" they lack visibility.

</comment></comment></comment></comment></comment></comment><comment><USER8> People seem to have not read the article properly and are conflating unit testing, with all testing. The article doesn't say to avoid all unit testing, but to restrict the test suite to that which can be validated by business logic or some formalized oracle - this would imply unit testing for critical systems like hardware drivers, banking/avionics, crypto, etc, where there are known and eternally consistent results that relate to the feature spec. But it also suggests that, in most cases, maintaining systems and integration testing are more economical usage of time, and further implies that they are more 'correct' in light of the fact that they directly relate to the feature spec.

I believe I came across this document (or something close to it) a few years ago, and it changed my life. I was able to get great velocity and low bug-per- feature count (1 or 2), using systems/integration testing combined with exploratory testing by a QA team. I was even able to find subtle bugs in the unit-tested back-end via integration tests from a mobile app. At the end of the day, if your testing isn't serving the business logic, it's wasted effort.

The most bad-ass thing I remembered was the part where if you couldn't elicit a code path using a systems test, it's a good candidate for deletion.

<comment><USER9> Agreed on all points.

These days, a large majority of the frontend tests in my codebase aren't tests that I've written myself. They're automatically generated Jest snapshot tests that capture the virtual DOM output of entire components in different states as dictated by product requirements, using the StoryShots plugin for React Storybook.

These tests prove to be extremely effective in catching bugs, because they directly reflect product requirements, and because they end up exercising a large majority of the codebase for very little cost compared to covering the same amount of code with individual unit tests.

The latter point is an important consideration too, because a lot of the code these integration-level tests exercise are code that I'd have considered too trivial to have been worth the ongoing maintenance costs in building unit tests for, when considered in isolation.

This means it'd have been easy for me to be satisfied with selectively and arbitrarily deciding which pieces of code should qualify for test coverage, and leave test coverage at some arbitrary number, as opposed to what I do now, which is to always strictly require 100% code coverage, but explicitly and deliberately exclude code that I have good reason to not test, which feels like a much more solid framework for ensuring code quality.

I still write unit tests for functionality that component snapshot tests can't reasonably cover, but usually only at a level of granularity where the tests themselves can map cleanly to product requirements as well, instead of painstakingly testing every little function in perfect isolation.

</comment></comment><comment><USER10> I'm afraid that the TDD movement went to far. The proponents became so convinced that they were right that they started comparing themselves to people who argued that washing hands was important in early surgery, and that those who questioned it would soon be unemployable in the field. Not those who didn't practice it, those who _questioned_ it.

I dealt with some of this, including a rather bullying type who tried to browbeat people into writing tests first. And while that may be a bad example, I'm afraid it really wasn't unrelated to the movement itself.

When people, a while ago, said "TDD is dead", they didn't actually argue that the technique wasn't useful. They were saying that the whole "you're wrong, I'm right, if you want to stay employed you'll do as I say and practice TDD", that is no longer defensible.

It's probably time to leave that in the past, and hope that people who promote a methodology this way have learned the mistakes of aggressively cramming things down everyone's throat. Truth is, I was actually a frequent practitioner of TDD, and I was pretty appalled with how it was getting pitched to the programming community.

Now, let's leave that in the past and take a fresh look on whether TDD is a very beneficial practice in many contexts. I certainly agree it isn't crap.

<comment><USER11> As in many areas of thought, when the pendulum swings too far in one direction, it then swings too far in the other direction. Hopefully we'll arrive at a reasonable middle ground at some point, and unit tests will be valued (and prioritized) neither too much nor too little.

On a side note, unfortunately I think the software industry tends to be particularly bad about this pendulum swinging back and forth between extremes thing. There is so much emphasis on innovation that people are biased toward making radical changes and believing they are going to revolutionize everything. And the culture is such that the more you go out on a limb and push something radical, the more you are respected, because we often value guts more than good judgement.

<comment><USER12> > the pendulum swings too far in one direction, it then swings too far in the > other direction

> Hopefully we'll arrive at a reasonable middle ground at some point, and unit > tests will be valued (and prioritized) neither too much nor too little.

My coding style has very much gone through a similar evolution. When I first learned about TDD, I went in whole hog - test everything, ui tests, request tests, unit tests - tests for everything.

Then I started to notice that the development costs associated with extreme coverage did not, in fact, pay off.

The number of bugs found was vastly outnumbered by the time wasted dealing with the peculiarities of various ui testing frameworks, let alone the amount of time wasted waiting for those tests to run.

My metric is now that I've written enough tests to feel confident that the code works. It's an extraordinarily qualitative metric, and I cannot find a way to objectively quantify it, yet it very much works for me.

Really, it all comes down to visibility. Is there somewhere that is up to date, that will tell you what the code is supposed to do? Do you have tooling in production that will alert you when it's not doing what it's supposed to do? Do you feel confident that the code works?

</comment></comment></comment><comment><USER13> I disagree: [https://henrikwarne.com/2014/09/04/a-response-to-why-most- un...](https://henrikwarne.com/2014/09/04/a-response-to-why-most-unit-testing- is-waste/)

<comment><USER14> "In my experience, unit tests are most valuable when you use them for algorithmic logic. They are not particularly useful for code that is more coordinating in its nature."

I agree in principle, but IME:

* This kind of algorithmic code often makes up a fairly small proportion (~5%) of code written for most business driven applications - it's usually _mostly_ coordination. Some domains may be different (and for them, unit testing will appear to be much more effective), but I think this is the norm.

* Integration tests can test algorithmic acceptably well, but unit tests do _not_ test integration code in an acceptable fashion.

* Where you have algorithmic and integration code smushed together (this type of technical debt is, sadly, the norm 'in the wild'), again, integration tests work acceptably well whereas unit tests require a mess of mocks.

* Integration tests do not have to be high level or slow.

"Refactoring breaks tests. Sometimes when you refactor code, you break tests. But my experience is that this is not a big problem. For example, a method signature changes, so you have to go through and add an extra parameter in all tests where it is called. This can often be done very quickly, and it doesn't happen very often. This sounds like a big problem in theory, but in practice it isn't."

This is a _big_ problem in practice when you are working on large scale code bases in which the developers have not been super strict about decoupling everything.

<comment><USER15> > Integration tests can test algorithmic acceptably well, but unit tests do > not test integration code in an acceptable fashion.

True, but you can have both types of tests, which lets you test algorithms (unit tests) and higher level combinations (integration tests) both in the best way. The right tool for the right job.

> Where you have algorithmic and integration code smushed together (this type > of technical debt is, sadly, the norm 'in the wild'), again, integration > tests work acceptably well whereas unit tests require a mess of mocks.

In many cases, you'd be better off separating the logic, which would let you have both types of tests, each for a different part of the logic.

> Integration tests do not have to be high level or slow.

No, but they are a different tool.

<comment><USER14> >True, but you can have both types of tests

You can, but if your code is 95% coordination and 5% algorithmic, at _most_ you'd want 5% unit tests.

>In many cases, you'd be better off separating the logic

Which is refactoring and if you're refactoring you need to have your code surrounded with tests to do it safely.

And, once you've done that, if you've already written integration tests for that logic and they perform acceptably well, there may be no point in rewriting the integration test as a unit test.

</comment></comment></comment></comment><comment><USER16> This has already been discussed to death, on 3 occasions:

[https://news.ycombinator.com/item?id=7353767](https://news.ycombinator.com/item?id=7353767) (268 comments)

[https://news.ycombinator.com/item?id=11799272](https://news.ycombinator.com/item?id=11799272) (280 comments)

[https://news.ycombinator.com/item?id=13815779](https://news.ycombinator.com/item?id=13815779) ("only" 24 comments)

<comment><USER16> Also, there's a followup by Coplien which _has not_ been discussed: [https://rbcs-us.com/documents/Segue.pdf](https://rbcs- us.com/documents/Segue.pdf)

So maybe this document should be the focus of the discussion now.

<comment><USER17> I'd love to submit this document to HN, so it has a chance to get a wider audience than provided by this sub thread.

However, the title "Seque" is completely unspecific and hence totally useless. Given that title, I don't see how to submit this to HN in a way that it attracts readers.

This is really a pity.

<comment><USER18> The guidelines on titles allow for writing your own title as long as accurate and more informative than the original title.

The bigger problem, I think, is the velocity of articles appearing and disappearing from the front page makes follow-up articles have an inherently smaller starting audience.

<comment><USER19> > The guidelines on titles allow for writing your own title as long as > accurate and more informative than the original title.

Mods appear really clear about this. They want you to use the original title unless it's clickbait, or inflammatory, or misleading. Only then can you change it, and they say an informative sentence from the article might do.

This means that articles with terrible, unclear, titles get posted to HN all the time.

See eg this thread: [https://news.ycombinator.com/item?id=15540388](https://news.ycombinator.com/item?id=15540388)

(Of course, I'm not a mod, so maybe I'm wrong.)

<comment><USER20> Certainly mods actively edit useful titles, explanatory titles to replace them with the terrible, unclear original title (Steven Hawking's PhD thesis is a good recent example).

</comment></comment></comment></comment></comment></comment><comment><USER21> _Don't underestimate the intelligence of your people, but don't underestimate the collective stupidity of many people working together in a complex domain._

Sometimes I find that unit testing is an attempt to spend as much time as possible experiencing the first reality (you are a smart, competent programmer) as a relief from the pain of the second reality (you have a gnawing fear that your understanding of the context is fatally flawed.) Can't figure out if the work you're doing is constructive? Anxious about the lack of requirements? Go soothe yourself writing unit tests. Kick back and watch the integration tests run. You're doing your job, and the rest will take care of itself, right?

</comment><comment><USER22> This is such a great document. I have referred to it quite a lot in my last job as we were restructuring our test. We mainly had unit tests that we'd just try to make green every time after changing code. It didn't stick well with me that we'd just rewrite the code in a different syntax (Rspec DSL). You don't really test anything in that way.

Just be prepared for a lot of shocked reactions when you say 'Most Unit Testing Is Waste' to people who have not been softened a bit to this concept.

I really like this way of thinking. The next chapter of getting into this subject are the live discussions (5 videos) between Kent Beck, David Heinemeier Hansson and Martin Fowler talking about TDD (which relies a lot on unit tests): [https://martinfowler.com/articles/is-tdd- dead/](https://martinfowler.com/articles/is-tdd-dead/) I enjoyed these a lot too and the combination of these sources has really improved my testing.

</comment><comment><USER23> This article is an anti-resume, and I recommend not reading it. I'll take a look at two claims.

 _Unit tests are unlikely to test more than one trillionth of the functionality of any given method in a reasonable testing cycle. ... Trillion is not used rhetorically here, but is based on the different possible states given that the average object size is four words, and the conservative estimate that you are using 16-bit words)_

An int may contain "four billion states", but for the requirements, its highly likely that we can classify the integer into three states: less than zero, zero, greater than zero. As a bank, I might not care how much money you have, only that you have more than zero. In a transaction, I don't care how much money changes hands, as long as no money is lost.

Pointing at memory-as-bits, as if we're still using punch cards, and then hand waving "I can't possibly test this", ignores sixty years of progress. The refusal to imagine a class with range checking is a damning statement about the author's own ability as an engineer.

 _Programmers have a tacit belief that they can think more clearly (or guess better) when writing tests [than] when writing code, or that somehow there is more information in a test than in code._

Consider writing a sorting algorithm vs testing a sorting algorithm. Would you feel more confident writing the _test_ for a sorting algorithm than writing the algorithm itself? The test is simple: is every item in the list less than the next item? The code is far more complex. We're in the same realm as NP problems. I can write a test to verify that a graph is correctly 3 colored, but the code might be a _bit_ harder.

Perhaps, then, the author's experience of other developers believing they can "think more clearly" is actually his observation that the developers are _solving simpler problems_ , and are thus more confident. And that is the point of tests: it is easier to verify than solve.

In short, every conclusion in this article begs the question, "Might there be another explanation?"

</comment><comment><USER24> The best workflow I've found is to define an empty function, add a breakpoint, and code the function in a repl. At this point I'm pretty confident the code works for at least a 'happy path' input so I copy the code to the editor and add tests to call it with a variety of other inputs.

Being able to inspect the state of the program in real time is invaluable and gives me a lot of confidence that I understand how the code works. For some reason most programmers I see don't even run their code locally and just use log statements to guess at state when it invariably doesn't work as expected.

Another big problem is test data. I see way too much naive mocking. You really need to exercise your code with data that is as close to real-life input as possible, ideally it's a sanitized version of production data. Other tests are great too (i.e large lists of 'naughty strings') but if you're manually specifying your test data you are a) spending a lot of time doing something that should be automated and b) are only exercising your code with what you _think_ it might see which is usually not good enough.

<comment><USER25> Log data is how unit testing started I think, people would log all the output and compare the sheet of actual log output to the sheet of expected log output.

Working in an GUI debugger / REPL is great for visualizing code I often code that way myself, but let's not fool ourselves, it still requires manually setting breakpoints, and pressing keys to step through code. You can't do this for every method after every change, whereas unit testing has that advantage. I do agree with most things mentioned in the article though. A lot people end up writing tests that hit databases and are too slow or fail randomly due to chained state, or are over specified & end up just getting in the way. What it comes down to is you can have good tests or bad tests, and its still entirely subjective just like whether the code itself is good or bad. I recommend the book xUnit test patterns, its basically a bunch of "rules of thumb"

</comment></comment><comment><USER26> _" my team told me the tests are more complex than the actual code. (This team is not the original team that wrote the code and unit tests. Therefore some unit tests take them by surprise. This current team is more senior and disciplined.)"_

Despite the inflammatory title, the point the PDF is making I believe is that unit tests should be kept short and simple, and convey the _intent_ of your code.

Intent is akin to the 'why' \- written code explains the 'how' and 'what' extremely well, but without the 'why' it loses all meaning. Writing tests to convey intent is essential because no computer or programming language can do this for us currently, so it's left up to us.

<comment><USER27> Yes, I agree. Unit tests should test the smallest unit of work and build like LEGO bricks.

What the Article describes are _tests_ but I would not call them _unit_ tests.

</comment></comment><comment><USER28> I pretty much agree with all of this.

Unit tests are great when you have a large code base with dozens of apps and need to modify a core library to remove side effects. How do you know you didn't break one of the apps?

But if we go deeper, why does the core library have side effects? Because it was a crummy, poorly designed piece of crap to begin with. If it was originally written with high quality it wouldn't need the refactor now. The author noticed this. He wrote good code to begin with so it didn't need a lot of testing.

When you have a large team of mediocre engineers you need unit tests to guard against more bad code from getting in. They might even be brilliant engineers, stuck in a horrible process of churning out features to unrealistic deadlines.

If you have a great team, a great process, and a great budget with realistic goals, you can crank out amazingly good software without the need for a lot of unit tests. But that's not the real world. In the real world we have lots of unit tests. They are a band-aid over the other problems without addressing them specifically.

<comment><USER29> > I pretty much agree with all of this.

It's easy to disagree with someone who portrays an enemy which doesn't exist.

I disagree with this piece everywhere it manages to land somewhere concrete, where its claims can be verified and assessed.

> But if we go deeper, why does the core library have side effects

Let's not get ahead of ourselves in theoretical, non-applied functional programming.

As even Haskellers recognize, all computing would be meaningless if there ultimately was no side effects. In fact, we use computers for their "side- effects".

Sometimes you need side-effects. And sometimes you unit-tests are great way of automatically verifying that you have the _right_ side-effects.

<comment><USER20> Side effects are by definition outside the thing itself, so they're not really amenable to unit testing; you have to use integration tests.

<comment><USER30>
        class AccessCountedInteger {
            private final int value;
            private int accessCount = 0;

            AccessCountedInteger(int value) {
                this.value = value;
            }

            public int getValue() {
                accessCount++;
                return value;
            }

            public int getAccessCount() {
                return accessCount;
            }
        }

This unit has side effects on the method getValue() that impact what is returned by getAccessCount(). While it is contrived, if you are making something following the builder pattern, you will in general have a lot of side effects from all of the methods called on the final build() method. This is quite amenable to unit testing.

<comment><USER20> That is not the kind of side effect that Haskellers would acknowledge as necessary (and I'd see it as a bad idea). We can call it a "side effect" but I think there's a qualitative difference between that and something like file I/O or async.

</comment></comment></comment></comment></comment><comment><USER31> "Unit tests are pointless" \-- this is often said by developers who suffer Dunning-Kruger syndrome. Except the devs who are actually working on something more exotic that cannot be tested well automatically.

<comment><USER32> You can have automated integration tests.

<comment><USER31> Yes, but devs who don't write unit tests are probably not going to write integration or acceptance tests either.

Maybe except of a one guy who I talked to a while ago. He does not write unit tests, because static type checking in C++ takes care of everything that unit tests do (according to him), but I actually have seen his code that contained few system tests, so there are exceptions.

<comment><USER32> Except that the featured article isn't saying not to worry about testing at all, it's about how to actually get value out of your testing.

<comment><USER31> I think it advocates wrong attitude towards software development and I think most points made in the article are just plain wrong and stupid.

I guess the main reason for my condescending sentiment is due that the author gives 0 examples of code that requires tests vs code that does not so it is actually not.

</comment></comment></comment></comment></comment><comment><USER33> > In most businesses, the only tests that have business value are those that > are derived from business requirements.

This is, imo, the most important takeaway and it is, or should be, obvious, but it often isn't (maybe because "common sense is the least common of senses" or something like that). It's also what I strive for, with one caveat[1].

> One is to use it as a learning tool: to learn more about the program and how > it works.

Another great takeaway. _Good_ tests should work as documentation, imo. I consider this another test quality metric, even: If looking at the tests only confuses me further, those tests need to be changed (and the code they're testing too, most likely).

[1]: Striving for this can turn code coverage into an useful metric. Not of correctness, of course, but on how much code we're writing that doesn't solve a business requirement. That code should be refactored away to separate libraries or replaced with third party libraries that already do that. I'm firmly in the "avoid NIH" camp.

</comment><comment><USER34> > 1.4 The Belief that Tests are Smarter than Code Telegraphs Latent Fear or a > Bad Process

That's not why you write unit tests. They are, in a roundabout way, programming's way of double-entry bookkeeping. Tests and code both are there to double check the other one. Neither one is "smarter" than the other.

</comment><comment><USER35> It'll be fun to refactor a codebase without unit tests </sarcasm>

<comment><USER32> Refactoring code usually means you have to refractor unit tests as well, since they are so closely tied to the structure of the code.

Integration tests, however, should not have to change, since they are typically run against the external interface to the software, which shouldn't change if you're just doing a refactoring.

<comment><USER35> Funny thing. Unit tests force you to think about good code design. Integration tests don't. If you only have integration tests in your system, you'll most likely end up with a big ball of mud. I've seen this so many times in so many real world projects that it hurts.

<comment><USER36> > Funny thing. Unit tests force you to think about good code design. > Integration tests don't.

They absolutely do, but at higher levels of abstraction, in terms of interfaces, interactions, constraints, obligations and responsibilities. In fact, unit and integration tests make you think about design in essentially the same way.

<comment><USER35> Whatever floats your boat. My experience in large enterprise products is exactly the opposite, but I'm glad it works for you.

</comment></comment></comment></comment></comment><comment><USER37> The SQLite project seems to have an alternative view: [https://www.sqlite.org/testing.html](https://www.sqlite.org/testing.html)

A lot of us would consider SQLite to be high quality and relatively bug-free. The extensive test suite they've built up that exercises each release is a huge reason for it.

Of test code _quantity_ , Coplien writes:

 _> If your coders have more lines of unit tests than of code, it probably means one of several things. They may be paranoid about correctness; paranoia drives out the clear thinking and innovation that bode for high quality._

 _> \- Keep regression tests around for up to a year_

 _> \- Throw away tests that haven't failed in a year._

SQLite appears to keep their tests. Somebody files a bug; SQLite writes a test that reproduces that bug; the test code remains long after the bug is fixed. This prevents the bug from _reappearing_. (Isn't that the main purpose of "regression" in the phrase "regression test"?)

I also think it's better to keep relevant regression tests for _years_. E.g. Consider that there's piece of code that's been working correctly for 5 years with 5 years of passing regression tests . Imagine a new programmer wants to rewrite the code to optimize it for speed and reduced memory usage. I think we'd feel much more confidient if the new code passes those same regression tests that were accumulated over 5 years.

As for test code size ratio... A lot of good comprehensive tests will have LOC outnumbering the actual code being tested. This is especially true for library code that's used in many places up the stack. I wrote string parsing routines and a reverse Boyer-Moore search routine where the test code (test edge cases, test nulls, test string sizes at 2^32 boundaries, etc) was 10 times larger than the actual code.

Of testing's _utility_ , Coplien writes:

      - Testing can't replace good development
      - [...] Tests don't improve quality: developers do

... which looks like a strawman and a false dichotomy. Can anyone cite a credible development philosophy that believes testing can _replace_ bad developers or bad process?

We could say that about <ANYTECHNOLOGY> such that <ANYTECHNOLOGY> can't replace quality developers. Garbage Collection doesn't improve quality, developers do. Array boundary checking doesn't improve quality, developers do. And so on.

Or maybe there's a difference in terminology? I wonder if Coplien considers SQLite testing "system test" or a "unit test"? Does he consider SQLite "white box testing" or "black box testing"?

<comment><USER38> Is there a reason why someone would throw away unit tests? I've never understood this. Time was taken to write it, test it, upheave the bug, and now we want to remove the safeguards that we spent time/money on? Leaving the possibility for the bug to infest again?

Scrapping unit tests is scrapping time.

<comment><USER39> If you are testing at the wrong layer of abstraction (Your test is tightly coupled to the implementation of your class, as opposed to its observable behavior), then refactoring your code will require refactoring the test.

The correct solution to this is to not throw passing tests out, but to stop doing white-box testing.

(Not to mention that a test that may pass in your CI environment may fail - frequently - in your local workspace.)

</comment></comment></comment><comment><USER40> Management keeps asking when we will write unit tests, and I tell them I'm too busy fixing bugs, because each time I fix a bug I

1) examine the entire code base to find any similar problems 2) implement full parameter validation in that code to try to ensure it can't happen again and 3) add exception logging code so that we will get an immediate error reported directly on the line it occurred if it does.

If I have any extra time left over, I refactor to eliminate code duplication, update/verify/add more parameter and input data validation, and increase code encapsulation.

Then I point out our crash rate has dropped by 70% in the 6 months I've been working on the project.

<comment><USER41> I'm curious what you consider examining the entire code base to find similar problems. If this is more than a 5-10 minute search then I would feel like it's a significant waste of time. And if it is more than that amount of time and you are continuing to find bugs then I would ask what is the problem that allows the same bug to surface in multiple places where it is easy to identify but hard to search for?

<comment><USER40> Here's an example. We got a crash report that had a stack trace that pinpointed the location in our code. The people who wrote the code used a design pattern called VIPER that uses 5 classes instead of the classic 3 from MVC. Our code base is in Swift, which uses optional values to protect against nil values. The protection is unwrapping with an if statement, if the value exists the if can execute.

The cause was that one of the VIPER classes forced unwrapped an optional reference to its view. Force unwrapping is without the if, just assume it's always valid and crash if it's not.

The problem was they made this assumption because the view is never nil except for one uncommon edge case, if a network operation completed after the view was disposed. So the fix was easy, remove the force unwrap (you should never force unwrap in Swift, it's terribly bad).

But what about our other VIPER views? It took me a couple minutes to review all 20, and Trey all had the same identical flaw. Fixing them took seconds, but individually testing the fixes took a few hours.

Should I have left those other 20 views alone so our app could mysteriously crash for some of our hundreds of thousands of users?

A more recent bug I found on my own was a memory leak caused by our main views network closures holding strong references to the ViewController. This caused code to fail that was still in old dead copies. So I fixed the closures and we no longer have old copies of the VC handing around forever. I didn't have time to do a search at that moment, but I took notes in my dev log so I can review every view controller (50 or 60) for similar problems. Why wouldn't I? How many known bugs and random unduplicated problems would go away if we got our Viewcontrollers memory Managemnt right? im betting at least a few, and that I'll eliminate some future problems before they can even be found.

Software engineering is usually 80% fixing bugs. Developing rigorous standards to prevent their formation can give you much more time to build new and improved features.

</comment></comment></comment><comment><USER39> I strongly agree, and disagree with many parts of this.

One part I strongly disagree with, is this passage:

> Most programmers want to "hear" the "information" that their program > component works. So when they wrote their first function for this project > three years ago they wrote a unit test for it. The test has never failed. > The question is: How much information is in that test? That is, if "1" is > the passing of a test and "0" is the failing of a test, how much information > is in this string of test results:

> 11111111111111111111111111111111

> There are several possible answers depending on which formalism you apply, > but most of the answers are wrong. The naive answer is 32, but that is the > bits of data, not of information.

Just because a test has passed in your Continuous Integration environment 100% of the time, doesn't mean that test is worthless. I have checked in many tests that have never failed in CI - but _have_ failed when I was working on my code. However, since there's no shiny team-visible metrics with bar charts about how often a test failed in a local workspace, people can wrongly assume that a unit test is worthless.

> Now, how many bits of information in this string of test runs?

> 1011011000110101101000110101101

> The answer is... a lot more. Probably 32.

If I see that in our CI environment, the answer is 'this test is nearly- worthless.' The long answer is 'If it's a unit test, there's a race condition, if it's an integration test, there's a race condition, or it's flaking for reasons outside our control.'

> Another client of mine also had too many unit tests. I pointed out to them > that this would decrease their velocity, because every change to a function > should require a coordinated change to the test. They informed me that they > had written their tests in such a way that they didn't have to change the > tests when the functionality changed. That of course means that the tests > weren't testing the functionality, so whatever they were testing was of > little value.

... That's the whole point of blackbox testing. If observed behaviour is not expected to change, neither should the test. If a refactoring forces you to update the test, then, yes, you are testing at the wrong level of abstraction.

This piece could have saved a dozen pages if it just told us to stop testing private methods, and write more integration tests.

</comment><comment><USER42> Why the concern that the volume of tests is greater than the volume of code? Why should that be a constraint, other than some vague sense of wasted time spent typing them out?

</comment><comment><USER38> One of the best uses for Unit Tests and Integration Tests, in my experience, is for testing things that would be incredibly difficult to test through QA, or the UI.

</comment><comment><USER29> This is clearly an opinion-piece and as such I guess it's not _terrible_ , but it certainly has enough points to disagree with.

From quickly reading through it, for instance I found the following things directly objectionable:

> "Unit testing was a staple of the FORTRAN days".

Such an attempt at discrediting something can be applied to anything, and it comes off as disingenuous, dishonest.

> "Unit tests are unlikely to test more than one trillionth of the > functionality of any given method in a reasonable testing cycle. Get over > it." ... Trillion is not used rhetorically here, but is based on the > different possible states given that the average object size

Who says you have to test the method? Who says you're not allowed to test functions which operate on a known, closed subset of data?

False dichotomy and plain bad math.

> If you find your testers splitting up functions to support the testing > process, you're destroying your system architecture and code comprehension > along with it.

That may be right. Or it may be possibly completely backwards. It's quite impossible to tell really, without asking _why_ they are splitting up those functions.

If people do this for gaming some sort of system about "at least 80% coverage" or whatever, then clearly you should ask why people feel the need to game the system. Gaming the system, no matter what aspect, leads to bad choices.

Me however, I'm not splitting up my functions to game the system. I'm splitting up my system to separate data-retrieval from data-processing (so I can directly test processing without depending on whatever retrieval depends on).

I'm splitting up my functions to give them name and intents, this makes the code speak much clearer about what it is doing and why. The function name should be "what". The contents should be "how".

Basically I'm splitting up my function for good reasons.

If a function is long enough to contain enough actions, intermediate variables, loops and conditionals so that you need to stop thinking about and wonder what they do, and what their role is inside that function... That functions should be split up, because you do not have a clear "what" and "how" delimiter.

And guess what? That also assists testability. You can test that the "how" correctly assesses the "what".

This is not destroying your system.

Some of the functions you end up with may even turn out to be reusable across the class/system, meaning you increases consistency and correctness as a result too.

Again: This is not destroying your system. Quite the opposite.

I could go on, but I'm just at the 4th page of 21, and my comment is already the biggest in the thread, and I'm not planning on making a blog-post length response.

Just saying this document is severely biased, contains factual errors and is not a good thing to rely on to present an argument.

</comment><comment><USER43> The author is correct, in the sense that over the lifetime of a software project 90% of the value from unit testing will come from 10% of the tests. The problem is that you won't know in advance which 10% that's going to be, so you have to write and maintain all of them.

</comment><comment><USER44> Somebody should tell them about [https://en.wikipedia.org/wiki/Code_coverage#Other_coverage_c...](https://en.wikipedia.org/wiki/Code_coverage#Other_coverage_criteria) and mutation testing.

</comment><comment><USER45> While some points here are worthy of discussion, this blames the arrow instead of the archer.

Write good tests, automate what you can, and make sure you're using your chosen implementation correctly and appropriately.

</comment><comment><USER46> As usual, "it depends"...

I worked on projects that tested every getter and setter. Many of these getters and setters existed only for other tests! Complete waste of time testing those...

</comment><comment><USER47> The host of this pdf is a testing consultancy which seems to have posted the same article about 10x already to hacker news. It's just spam

<comment><AUTHOR> I posted, I have no connection to the consultancy. I thought there were some good arguments in the PDF which I agree with after > 10 years dev experience.

</comment></comment><comment> xyz-x The article mentions object orientation several times as a hindrance to unit testing. Perhaps that should be its biggest take-away?

Having written an accounting system, including web/user interface and asynchronous/deferred coordination (such is HTTP/browser programming), for the last three years, I can say that functional programming is increasingly helping my team stay sane.

We do TDD always; sometimes in the form of unit tests; sometimes in the form of integration tests and we tend to write as many of our tests as random/generative tests to avoid having to write large code-bases. I've spent the last two days making a piece of our domain monoidal, having defined the three laws as property/generative tests; the rest of the time is an interactive play with the generator, to see if it can come up with counter- examples, to the code I just wrote.

I normally go about coding by writing a very high-level integration test (at the top-most layer that I still have code in the service/frontend); then I write a huge chunk of the code until I think it's correct and looks pristine and easy to maintain. Now I run the test. If it fails and the test is correct — it tests the right thing and is easy to read — then I start at the top (highest level) of the stack, and write down the assumptions I have thought about while designing the code — as unit tests. Until one passes (at some level n); at the higher level n+1, an assumption/unit test is now broken and I can divide-and-conquer until I find the line of code that doesn't work.

This, together with purification; the methodological extraction of pure functions (things that only have one output ever, for a particular input), makes it possible to avoid testing any side-effects/async things (they simply flow non-async data between pure functions).

This, together with first-level-values for control flow, aka. not using exceptions, and generative/random testing, makes it so that ALL of the input has valid output, makes it so that all functions are total functions. And this in turn makes the code uncrashable and bugfree (for the domains of bugs the above methodology removes).

The domains of bugs that the above doesn't eradicate, are primarily cross- browser bugs on the GUI-side, or UX bugs, where a feature is hard to use/understand. On the server-side we sometimes crash when our logging storage in ElasticSearch goes down and never comes up, the intermediate buffer (Logstash) fills up, and then the app buffer fills up and then the app livelocks, waiting for the logging to drain. (=> operations). The second most frequent reason we have any exceptions/errors/bugs is DNS not working.

The first year of writing the software, we still invoked libraries that threw exceptions, but now we've rewritten them all to do control flow with first- class values, so that is not an issue any longer.

I just wanted to share how we do stuff at qvitoo :), in case it helps anybody.

</comment><comment><USER48> not only is it often waste but it can tremendously add to code bloat and 'dept'. I saw a dev spending 80% of his time 'fixing test setup' instead of fixing code.

<comment><USER49> To me that would be a red flag. If it's difficult to setup within your tests then it's difficult within your code and/or too much magic is happening.

</comment></comment><comment><USER27> Most unit testing is wasteful because most unit tests... are not unit tests. Or bad unit tests at least.

I can count on one hand the number of well written project test suites I've seen - even on code bases with 100% coverage.

We, as a group, do not seem to be good at writing them. I'm not sure why, and would love a discussion about it...

</comment><comment><USER50> nit tests are not a silver bullet, but if you request passing tests and coverage to put in prod, you basically request a minimal & always up to date documentation.

</comment><comment><USER51> This is truly the dumbest thing I've read all year about software development. It isn't just dumb though, it's harmful. Now moron developers everywhere will hold it up as an excuse why their code is so good it doesn't need testing. Now, especially after Equifax, is a bad time to have this attitude. There are already journalists calling for developer licensure.

[https://www.nytimes.com/2017/09/11/opinion/equifax- accountab...](https://www.nytimes.com/2017/09/11/opinion/equifax- accountability-security.html)

<comment><USER21> This is a critique of popular testing practices by an experienced engineer who is trying to improve the practice of testing and increase software quality. This is a big part of how engineering practices improve. A culture where we call something "dumb" without reading it because we only care what "moron developers" will make of it (presumably also without reading it) isn't going to increase software quality or protect against the next Equifax. It's easy to have a knee-jerk reaction to a title and rationalize the desire to respond on that basis. Surely nobody else will read the article, and therefore _I have already determined its true significance_ by having a knee-jerk response to the title or a few haphazardly skimmed sections. If that reasoning prevailed, though, people should just write headlines and never anything more thoughtful, and we should be stuck forever with "UNIT TESTING GOOD" and "UNIT TESTING BAD" as the two competing pinnacles of software testing wisdom.

In case anyone was fooled by this comment into thinking the article takes a lazy approach to testing, it argues for keeping a certain class of unit tests; for another class, preferring system tests instead; and for third class, turning them into assertions that ship with production code where possible. That's not lazy. Depending on how you currently test your code, it may actually be a harder standard to meet. It's possible you personally have nothing to learn from it, but I would wager there's something in it that will make you see your tests in a different way.

</comment></comment><comment><USER52> In my experience the usefulness of Unit Tests is very dependent on the quality of the team and its grasp on the business requirements. Some programmers can write high quality code that doesn't need unit/integration testing at all, some can't.

<comment><USER26> Legacy code = code without tests. You might write HQ code today, but without tests it'll become technical debt within a month or even a week down the line. Programmers come and go, unit tests are omnipresent.

<comment><USER53> All code is legacy code as soon as you type the semi-colon. It is wishful thinking that a suite of unit tests will prevent a refactor or small change from producing technical debt.

<comment><USER54> In a sense you are right. That state where you have the complete program as a mental model goes away when you stop for that session. But if you pick it up the morning after that mental model could be reconstructed in < 1hr and you can finish the feature and deliver it as value to a user. If you created good tests (unit/integration/regression) that captures the gist of what the code should do, two-year-older-you or another developer have a good chance of getting a similar mental model in order to change the code with confidence. So i consider "legacy code" as a scale where you on one end go "The reqs have changed, better rewrite it all!" to "The reqs has changed, but I can confidently add this functionality and keep some of the unchanged behavior!"</comment></comment></comment></comment>


Show HN: A Fortran web framework - <AUTHOR> https://github.com/mapmeld/fortran-machine <comment><USER2> I would love it if these projects were accompanied by a little blog post stating who the person is, why they decided to do it etc. for projects where it is obviously a labor of love.

Especially because of the effort it would take to get this working on a "dead" language. Like who are you? How did you decide to work on this for the pure joy of it? Why not Cobol? Why a web framework?

<comment><USER3> Fortran is actually still in major widespread use, particularly in the scientific and engineering fields. This is partly because it has unparalleled speed in some domains, better even than C or C++.

<comment><USER4> Fortran is ubiquitous in ocean and atmospheric modeling. I believe this is the case for all earth sciences.

<comment><USER5> I have a buddy at US Fish and Wildlife where they do river flow modeling with Fortran routines from the seventies formerly compiled on Windows machines. He was finding it increasingly difficult to get his all-powerful shadowy IT division to install a compliant MS Fortran compiler, and linux (somehow deemed governmentally untenable?) was out of the question. So i helped him get his ~2000 Fortran lines into C/C++. _woowee..._ but did i see some hairy spaghetti code. A favorite maneuver was to jump out of a loop, change the loop counter on a subroutine branch, and jump back into the _middle_ of the loop.

<comment><USER6> Change the loop counter? That's supposed to be impossible in Fortran, isn't it? Maybe that's a language extension?

<comment><USER5> This was from code originally from about 1978ish, which compiled on a Microsoft Fortran compiler from the 2000s. It looked something like (without indents):

        DO I=1,10000
          ...
          IF (QQQ .LT. RIX70) THEN
             CALL IXNARF( I, J, R1, R7, XL23 )
             GOTO 23
             ...
          END IF
          111 CONTINUE
        ...
        END

IXNARF could change 'I' (because Fortran 77 passed arguments by reference not value) and sometime after line (er... "card") 23 it might jump back into the loop at 111.

oh and there was like three comments in the whole several thousand lines, including my favorite at the top of one of the main loops:

        C  CHUGGA CHUGGA CHUGGA

<comment><USER7> I remember you could change the value of 3 in Fortran 77.

Then there was the proposal for a Fortran COME FROM statement.

[http://www.fortran.com/fortran/come_from.html](http://www.fortran.com/fortran/come_from.html)

<comment> semi-extrinsic I believe Intercal implements the COME FROM statement.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Also relevant: [https://github.com/azac/cobol-on- wheelchair](https://github.com/azac/cobol-on-wheelchair)

<comment><USER9> The views are a little disappointing, using just plain mustache style. Shouldn't a cobol web view have something like

        HEAD DIVISION
        META-TAGS SECTION.

        BODY DIVISION.

<comment><USER10> DIV DIVISION?!

<comment><USER9> HR DEPARTMENT.

</comment></comment></comment></comment><comment><USER11> Seeing this gave me a subtle but definite frisson of nostalgia for Fortran (first language, learned in late 60's).

</comment><comment><USER12> Hello,

I wrote the 'fortran+fastcgi+nginx' thingy. It has evolved into [https://github.com/rlcarino/heeds](https://github.com/rlcarino/heeds). Production live runs (and a little blog post about it) may be found at [http://heeds.csu.edu.ph](http://heeds.csu.edu.ph). Some students from a university connect to the runs with their Android phones without cell data cost via Facebook's Free Basics which is available in that part of the world. Usage instructions for students are in the FAQ of [https://www.facebook.com/groups/csuheeds/](https://www.facebook.com/groups/csuheeds/).

Why do it? It is a consulting gig.

Ric Carino

</comment><comment><USER13> For those wondering why it's used, here's a write-up I found on Eric Raymond's blog comparing Fortran and C:

[http://www.ibiblio.org/pub/languages/fortran/ch1-2.html](http://www.ibiblio.org/pub/languages/fortran/ch1-2.html)

Some comparisons are dated. However, I think the older variants still have advantages in readability, more clear semantics, semantics closer to algorithm itself (esp mathematical functions), less guessing by compiler for optimizations, and maybe a few others. Those I listed seem to still be advantages over C in general or as it's commonly used.

<comment><USER14> Also of note is that the implicit typing system of Fortran is held up as an advantage (although a bit reluctantly)

</comment></comment><comment><USER15> This reminds me of the time I actually found myself charged with integrating a chunk of Fortran code compiled into a Windows DLL with an Excel sheet via VBA. The VBA side was straightforward if a little icky, but handling strings in Fortran was really giving me headaches. Documentation on Fortran, even down to basic syntax, seemed inconsistent and hard to find online. I think I got the project mostly working before I left that company for unrelated reasons.

</comment><comment><USER16> I'm mostly used to Fortran 77 and that was ages ago, that actually looks quite readable...

</comment><comment><USER17> Reminds me of: [https://github.com/azac/cobol-on- wheelchair](https://github.com/azac/cobol-on-wheelchair)

</comment><comment><USER18> Nice work! That home page, while admittedly simple, renders incredibly fast. Have you done any benchmarks / performance comparisons to other web frameworks?

<comment><AUTHOR> No, not yet. It ought to be comparable to C++ in most cases. The difficult part is extending Fortran to do something that you want / hasn't been shared yet on the web.

</comment></comment><comment><USER19> Just because you can?

<comment><USER20> For some reason I've been seeing more and more Fortran lately. Maybe it's the trendy thing to do.

<comment><USER21> Honestly, High Performance Fortran has really nice support for parallel arrays. For computational programming I see a lot of value.

<comment><USER22> The issue is what you give up. Yes the FORTRAN compiler/runtime is fast but concurrent primitives weren't added until FORTRAN03, and recursion wasn't fully supported until FORTRAN90 [1]. It hides almost all the implementation details from the programmer.

Fortran is a really good language for number crunching. Academics who don't know how to code can build very fast number crunching tools without really any CS or hardware knowledge. This the target use case and target audience.

If you want to do low level system things with it, it'll be painful.

[1] Some fortran70 compilers had limited support for recursion it wasn't added to the official language standard until 20 years later tho.

<comment><USER23> >The issue is what you give up.

This is the feature, not a bug. The purpose of fortran and why it is a fast efficient tool for scientists to write software is is exactly that it hides implementation details and is a bad systems language.

It allows you to define the important math parts of your program and hides the implementation part exactly so the compiler has a lot more power to optimize.

</comment></comment></comment></comment></comment><comment><USER24> Given Ruby on Rails, COBOL on COGS, silly naming pattern, I'm a bit disappointed this isn't called something like Fortran on Flumes.

</comment><comment><USER25> I am definitely going to try this! Would love to see a bit more about the creator!

<comment><AUTHOR> Thanks! You can find my name on GitHub and Google around to find more info / e-mail address

</comment></comment><comment><USER26> Finally!

</comment><comment><USER27> An accomplishment, certainly, but...

[http://i.imgur.com/TnQRX6v.gif](http://i.imgur.com/TnQRX6v.gif)</comment>


Pitfalls and Lessons Learned when switching from SVN to GIT - <AUTHOR> http://united-coders.com/nico-heid/pitfalls-and-lessons-learned-when-switching-from-svn-to-git

<comment><USER2> This is a bit pedantic, but Git isn't an acronym (or all-caps).

<comment><USER3> thanks, i fixed that ;)

</comment></comment><comment><USER4> I remember when SVN came out that it was designed to fix CVS not as a big improvement over CVS. CVS had some terrible flaws. SVN fixed them. Git was designed to make source code control better. Git is a huge improvement over SVN or CVS. Since it is an improvement you have to do some learning. It is worth it!

</comment><comment><USER5> I was hit up by several of these gotchas when learning -- I certain wish this article had been available then.</comment>


The Winter of Our Discontent - <AUTHOR> http://www.codersnotes.com/notes/the-winter-of-our-discontent

<comment><USER2> _You are not your customer. Your advertisers and affiliates are not your customer. Your advertisers are there to fund the customer's needs. For every decision you make you have to stop and ask yourself: Is This Best For The Customer?_

This part I disagree with--in how many business models is it true that advertisers _aren 't_ the true customers? There are many businesses that are predicated on delivering actual value to actual individual customers, but it seems as though most content-farming sites are giving away value specifically to serve their true customers, the advertisers.

<comment><USER3> I think it's meant more as an exhortation than a description. Is your disagreement an observation that some business models work that way, or is your disagreement that a business with an advertising based model should work with the advertiser's needs foremost, rather than the non-paying end-use (aka "customer" for purposes of this essay)?

If the former, then I don't think there's an actual disagreement.</comment></comment>


Millions in China Were Barred from Transportation for Low Social Credit - <AUTHOR> https://jalopnik.com/millions-of-people-in-china-were-barred-from-transporta-1833012115 <comment><USER2> Reminds me of Airbnb and Uber review systems in some way. And those systems always keep me on my best behavior. If the government does not abuse the social credit system for petty things, it could become a force for the good.

<comment><USER3> After visiting and getting cut in line enough times I was basically ready for anything to get people to be nicer to strangers.

Another sort of weird system came about because restaurants always lied on their tax returns, so now there are lottery tickets built into receipts: [http://engineerinshenzhen.com/chinas-receipt- lottery/](http://engineerinshenzhen.com/chinas-receipt-lottery/)

<comment><USER4> Have seen that being done in a long time here. I don't think they've done this or the last 4 years.

</comment></comment></comment><comment><USER5> Citizen of the United States of America gets job offer revoked due to poor credit. We aren't any better.

[https://www.reddit.com/r/personalfinance/comments/awmvre/50k...](https://www.reddit.com/r/personalfinance/comments/awmvre/50k_in_debt_accepted_an_offer_at_a_higher_paying/)

<comment><USER6> This is absolutely a different story. This is the government not allowing you to travel around a country because they don't like you.

This person can still get a job somewhere else. He can still go visit his family wherever they are. The government isn't stopping him from living his life just because of some "social score".

<comment><USER7> > This person can still get a job somewhere else.

You don't know more about the person's situation than the person himself.

> He can still go visit his family wherever they are.

As long as "wherever they are" means "somewhere he can go by foot".

> The government isn't stopping him from living his life just because of some > "social score".

No, the invisible hand of the market is stopping him from living his life because of his negative "money score".

<comment><USER6> > You don't know more about the person's situation than the person himself.

Considering he had a job somewhere else, obviously he is employable.

> As long as "wherever they are" means "somewhere he can go by foot".

Or people can come pick him up. Family can buy him a bus ticket. Friends can give him a ride.

> No, the invisible hand of the market is stopping him from living his life > because of his negative "money score".

Nonsense. It might be limiting his ability to live his life in a way that is comfortable/convenient, but it is not prohibiting him in a way that actually limits his personal freedom.

<comment><USER7> > Considering he had a job somewhere else, obviously he is employable.

I'm sure there are ways for them to improve their situation, but I'm also sure there are ways to improve your social credit. It would make for a bad incentive if not.

> Or people can come pick him up. Family can buy him a bus ticket. Friends can > give him a ride.

Restrictions exerted by the market are easier to bypass than China's social score system, but nevertheless they exist.

> Nonsense. It might be limiting his ability to live his life in a way that is > comfortable/convenient, but it is not prohibiting him in a way that actually > limits his personal freedom.

Limiting someone's ability to live their life in the way they desire is what limiting their personal freedom is.

<comment><USER6> > Restrictions exerted by the market are easier to bypass than China's social > score system, but nevertheless they exist.

You're still talking about a massive difference. People in China can be expressly forbidden from, say, staying in a Hotel in any particular town, simply because they are on some "list" somewhere that they don't control. And the government then exerts pressure on others to not be associated with those people. Again, we're talking about something categorically different than "market restrictions."

> Limiting someone's ability to live their life in the way they desire is what > limiting their personal freedom is.

I believe this is fundamentally a worldview issue, but the truth is that we as humans aren't completely autonomous. We are restricted in numerous different ways. We can't go too deep in the ocean. We can't go more than say, 15k feet above sea level without assistance. We can't buy top-of-the-line Teslas unless we can afford it.

Being unable to travel, buy, or move around the way someone wants to isn't a limitation of personal freedom. It's a restriction on their environment. Now, if you had the money to do those things but someone forbade you, then I'd be in agreement. If we define "personal freedom" simply by what one can buy or experience, then we are in a situation in which people will never be able to find true freedom.</comment></comment></comment></comment></comment></comment>


Linus as one of the top 14% most vulgar users on GitHub - <AUTHOR> http://osrc.dfm.io/torvalds <comment><USER2> > I hate to say it but Linus does seem—as one of the top 14% most vulgar users > on GitHub—to be a tad foul-mouthed (with a particular affinity for filthy > words like 'mick').

Is mick a filthy word? Linus probably often refers to a kernel developer named Mick, which then earned him this spot in the top 14%.

<comment><USER3> It's a racial slur against the irish. Somehow I doubt that's how linus is using it though.

<comment><USER4> _It's a racial slur against the irish._ \- Only in the US. If you were to call an Irish person a mick anywhere outside of the US you'd be met with a confused look and them re-introducing themselves with their actual name.

<comment><USER5> EDIT: I was wrong! See Peroni's reply below. I leave my incorrect reply here.

{{It's a slur in England.

I guess it's probably dangerous to call people micks in Ireland and Northern Ireland.}}

<comment><USER4> It really isn't. I'm Irish born & raised and have lived in London now for the last 4 years and not only have I never, ever heard the term used in a derogatory manor, I can't imagine any context where a fellow Irishman would take offence.

<comment><USER6> TBH I'd say Paddy was more common in the UK as a term for the Irish, but neither are as common as Jock (Scottish) or Taff (Welsh).

I'd say even Septic beats it (Septic Tank = Yank).

<comment><USER4> Paddy is definitely a lot more common but a bit weak on the scale of racial slurs.

<comment><USER6> Not Irish, but as an Englishman I'd say it's maybe on a par with being called a Pom or a Limey (which offends me not at all).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Guys, you have to remember that Linus Torvalds is from Finland where the communication culture is a bit different. For example, the Finnish language does not have an equivalent for the word "please" so it's sometimes really hard to be courteous and polite for a finn.

Linus' native language is actually Swedish with a Finnish dialect, he's from a bilingual family. But in any case, the tone of his verbal output is definitely Finnish :)

Yes he sometime pisses someone off because of his blunt way of saying things but that kind of things happen when communicating across cultural and language barriers.

<comment><USER8> Hmm, so you can't ask for something politely in Finnish? How do you distinguish?

<comment><USER7> You can ask for things politely in Finnish but you can't translate that into English.

Instead of adding superfluous words like "please" to the end of the sentence, in Finnish you conjugate the verb of the sentence to a "polite form" to indicate the intent. There's a dozen different forms to use, e.g. "imperative" to indicate that something must be done or "potential" to indicate that something might probably happen.

<comment><USER8> That makes sense, thanks.

</comment></comment></comment></comment><comment><USER9> Equating ordinary swearing to "vulgar" is an American thing.

I find it rather uncomfortable to repeatedly see threads in which Americans judge others (and each other) based on utterly irrelevant puritanical values rather than their contributions hitting the front-page of HN.

Especially the utter irrelevance bothers me, this is not about stuff like government regulation or privacy or women in tech, where there are valid ideological differences to discuss.

This is just about shaming people because they have different values. It's pathetic. We might as well be engaging in celebrity gossip.

<comment><USER10> A European and multi-lingual version of facebook that doesn't enforce American puritanism rules on porn etc and torrents, would be more popular, like tumblr.

</comment></comment><comment><USER11> I love it. Top comment is defending his swearing, with a ton of attached discussion over whether or not it's really defensible. Second-ranked comment is pointing out that the statistic is completely bogus. Amusing to see what gets more attention and upvotes.

<comment><USER12> Me too.I'm absolutely excited by the service itself and really puzzled how people stick on the some irrelevant and well-known details.

Guys - anyone TRIED at least other user handles? Its fun!

<comment><USER11> The site was down when I tried it initially, but I just tried it on myself now, and you're right, it is pretty cool.

</comment></comment></comment><comment><USER13> Hah - what a fun tool! I'm surprised to find out I'm in the top 38% most vulgar users on Github. I'd always told my teams never to swear in code so I'm probably in the top 10% most hypocritical user pool...

<http://osrc.dfm.io/philjackson>

</comment><comment><USER8> So 14% of users are _more_ vulgar than Linux? Who are these people?

</comment><comment><USER14> A page full of stats and relationships regarding the commit behaviour of one of the most important figures in computer science of all time, and the only one people care about is "how much he swears". Fuck that shit.

</comment><comment><USER15> Seems the site does't cache results. And just hit the rate limit.

</comment><comment><USER16> I think you're muddling up vulgarity with swearing. Personally, I find Linus' writing clear and concise with a good grasp of common English idiom.

<comment><USER16> Just checked a USAian dictionary - as usual you chaps are using well defined words with a clear etymology in as barbarous a manner as possible.

My statement still stands. People who are scared of words need to be shocked into engaging their brain.

<comment><USER17> I'm confused. What word did you look up? And I'm not seeing the original statement that you are now defending here.

<comment><USER18> The world "vulgar" of course.

</comment></comment></comment></comment><comment><USER10> Swearing in a language other than your first counts a lot less. As if were to throw "merde" or "fick" around. In Sweden, while speaking Swedish, they will casually say fuck instead of "fan!" or "helvete!"

</comment><comment><USER19> _only_ the top 14% !

Well, Fuck me.

</comment><comment><USER20> Haha, I saw this yesterday, I thought it was funny. No need to read more into it. Also I suspect it's someone name, not the actual slur.

</comment><comment><USER21> "torvalds seems to speak only one programming language: C. Maybe it's about time to branch out a bit."

Epic.

<comment><USER12> Indeed - an pure sci-fi, too

</comment></comment><comment><USER22> Anyone else getting this?

\---

Sorry guys… It looks like something went wrong! We've probably exceeded GitHub's API limits.

How about you read about how this work and then come back later?

Sorry!

\---

<comment><USER23> Works fine for me. Maybe your data wasn't cached before their API limit got exceeded?

<comment><USER22> I was earlier getting this for the original link for Torvalds, but now it is working again.

</comment></comment></comment><comment><USER24> To bad we already managed to overload the site.

<comment><USER25> Anybody has a cut&paste ready copy of this top-10 in their browser?

It's overloaded now.

<comment><USER26> Surprised the result wasn't cached.

<comment><USER25> Cache: <http://svay.com/projects/FullHackerNews/#article-11>

</comment></comment></comment></comment><comment><USER27> It seems his vulgarity surpasses his C skill!</comment>


Good developer hygeine - <AUTHOR> http://belucid.tumblr.com/post/646510572/good-developer-hygeine-2 I've met numerous developers that give me a blank look when I ask them which clipboard manager they use. <comment><USER2> Or use EMACS and its kill ring and multi-level undo (although stock GNU EMACS doesn't put single character deletes into the kill ring).

</comment><comment><USER3> This could use a better title. Getting from "hygiene" to "clipboard manager" is a stretch.

That said, I use a clipboard manager and find it very convenient. It helps to lessen context changes: I can copy a bunch of stuff onto the cm and then pull it off at the destination. I can copy/cut stuff onto it that I may need at some indefinite point in the future. I don't have to spend time deliberating whether to keep a record of it; if I need it, it's there. I can copy a subsequent item without worrying about losing the current clipboard contents. And I can keep items I occasionally need to reference available in the cm history.

All this works so well because the cm I use has a very quick to use and quick to respond search including limited wildcarding that progressively refines results with each keystroke of the search pattern.</comment>


Anchorage, Alaska, to Install 16,000 LED Streetlights. Will Save $360,000 per Year. - <AUTHOR> http://www.treehugger.com/files/2008/07/led-streetlights-anchorage-alaska-16000.php

<comment><USER2> Forgive me, I must vent here (treehugger does not approve such comments there)...

Treehugger is a disservice to environmental news. They are consistently technically uninformed and making no progress as the years go one. You will routinely see articles like this one where there is a story but they get it wrong. If they are going to fill the space, they should do it adequately.

Consider this article:

       Bigger Benefits Up North
         Because Anchorage has 85 days a year with less than 8
         hours of daylight, any benefit over the tradition [sic]
         lighting architecture are compounded.

That is their first big benefit of the lights in the article. And during winter it is true, but what about summer when the sun barely sets? Doesn't that make streetlights less useful? Doesn't this all come out in the wash? Is the 50% reduction in power use enough?

Shoddy journalism, mountains of ads (69 items loaded for this article), and suppression of source articles (this one is just a summarization of a press release published elsewhere , but good luck finding the link. The first couple that look likely are just links back into treehugger) should not be tolerated at "One of the most influential tastemakers".

<comment><USER3> I agree with you, that is a very shoddy piece of journalism. The LEDs are almost certainly less efficient than the sodium lamps they replace.

<http://en.wikipedia.org/wiki/Luminous_efficacy#Examples_2>

Prototype LEDs are reaching 130 lumens/watt, low pressure sodium regularly get 150 lumens/watt in production. The efficiency of the LEDs used is probably around 80-90 lumens/watt.

The money saving is probably coming from the lower maintenance costs whilst there is an increase in energy use.</comment></comment>


Default news subreddits currently embroiled in censorship over Orlando shooting - tuna-piano It seems the default www.reddit.com/r/news subreddit, which  has 9M subscribers, has been censoring, removing, and locking threads related to the shooting in Orlando.
It will be interesting to see how Reddit deals with this.  One of the worst mass shootings in US history, and the main subreddit to discuss the situation is heavily censoring the coverage.
No mention of the shooting on the front page of Reddit currently (9 hours after it started): https://www.reddit.com/ (Screenshot: http://i.imgur.com/mMCx5bU.jpg)
Censored megathread (See how many comments have been deleted)- https://www.reddit.com/r/news/comments/4nql8f/orlando_nightclub_shooting_megathread/ <comment><AUTHOR> The only discussion is a censored megathread, and megathreads dont show up on the main feed.

</comment><comment><USER2> most of the comments has been removed by mods</comment>


Forget the resume, kill on the cover letter - <AUTHOR> http://37signals.com/svn/posts/1748-forget-the-resume-kill-on-the-cover-letter?utm_medium=email&utm_campaign=Incoming+Transmission+05&utm_content=Incoming+Transmission+05+CID_e7b6da8de6bb025883e1361bd654f03e&utm_source=Newsletter&utm_term=Forget%20the%20resume%20kill%20on%20the%20cover%20letter%20by%20DHH <comment><USER2> Hmmm I dunno about this... "Don't wear a suit if everyone else is wearing jeans". I mean I understand the value of building a culture, but I just don't think the essence of culture lies in people's sense of style or what kind of clothes make them feel comfortable (ESPECIALLY during a job interview).

To me this is equal to a company whose culture places importance on the kind of shoes you wear to an interview. It's just not important... if you want to rise above the "big shop with an HR department" then don't follow the same rules.

I get that if someone doesn't conform to the "cool" trends set by the majority of the employees, and they don't have a closet full of sarcastic and/or slobby t-shirts that person will initially be judged and will have a hard time fitting in.. but if their personality and input rise above all that surface nonsense, then your "culture" is safe and that person is going to be a valuable member of the team.</comment>


Math is Crazy hard to define - <AUTHOR> https://mathwithbaddrawings.com/2016/04/20/math-is-crazy-hard-to-define/#more-4506 <comment><USER2> Loved it, covers arithmetic, algebra, geometry, combinatorics. Just wanted to add math is also the study of change - and that covers analysis.</comment>


Ask HN: Devs who were let go, how did you spend your notice period? - <AUTHOR> I was today given a termination of contract as the company is cutting costs all around.
I was the only developer in the company who had three other developers working as freelancers remotely from two countries. It made more sense for my company to let me go and outsource the tech to the freelancers.
The hr even offered to set up a meeting with a COO of another startup she knew who is already interested in hiring me. I think it was nice from the HR but it also shows how fast the company wants to get rid of me from their books.
After thinking a lot, I personally feel I need time to take a step back and slowly rediscover my lost passion for writing code just for fun. I worked 5 years very hard and the last year I moved to another (non-English speaking) country to work as a backend developer. I now feel that in trying to fulfill my dreams of moving to another country I ended up burning out really hard and it's time to take a step back and think about everything.
I start with slowly learning / practicing some of the concepts that I wanted to learn for a long time. I'm a backend dev who can write code in python and use frameworks like django/drf or flask to bootstrap SaaS products from scratch. I know how to use docker for local development and setup k8s for production. I know the value of CI/CD to get constant feedback from product owners and stakeholders. I can also fix small bugs in front end stack written in VueJS/Nuxt or vanilla JS.
I don't have any immediate family or any loans. Savings are zero but the next three months salary is good enough to keep me going for 6 months.
My question to fellow devs here. How would you spend your three months of notice period and what skills would you focus on next ? I'm thinking to build some fun projects on the side and strengthen my database and software design skills. But most importantly I'm also going to sleep well, exercise daily and take it easy for a couple of months now. <comment><USER2> 2 points:

1) the company might not 'wants to get rid of me from their books', they might actually be doing the right thing. The fact that they gave you three months notice is very impressive. I have been let go twice, the first gave me a month notice. The second showed me the door immediately. Guess which one I felt better about?

2) Get a new job! You are never worth more than while you have a job. If you wait, you will be lucky to lose only 10%, although from what I have seen it often costs you 20 to 30%. But then again the economy is strong now.

When people ask why you are leaving, you tell them is it obvious to you the company has issues and you need to move on.

When the first company let me go, I worked hard at making sure I left good turn over information. I regret not looking for a job, but I struggled with the resume. If you struggle, get professional help, its worth it. You have 3 months to leverage a raise Tick Tick Tick....

</comment><comment><USER3> Hi neo1691. I'm sorry it happened to you, I was in your shoes about 4 years ago. I spent a lot of my time learning React&ReactNative since I was already good with backend coding using PHP.

</comment><comment><USER4> Dont burn bridges, keep the lights on but dont dig into anything new, document that might effect continuity, reevaluate finances if you dont have anything lined up.</comment>