skysight-inc/HackerNews huggingface dataset:
>You are writing code to test something that doesn't even exist yet. I am not rightly able to apprehend the kind of confusion of ideas that could provoke such a method.

Yeah, the fact that you can't comprehend why people do this is very clear; if you could, you wouldn't have written this terrible rant. It feels like the author is criticizing this before coming anywhere close to understanding why people do it.

I really wanted some kind of point to find to disprove, bu there aren't any in this post. The strongest proof the author offers to his point is using one word tautological sentences to repeat what he just said: "Tests don't work because they just. don't. work."

The more I read, the more I realized this post isn't about testing, it's about the author letting the world know how fucking awesome and smart they are. They build huge software suites (from the sound of it, completely alone) with no tests, and everything works out fine, even better than fine, spectacular. It seems like the author deleted this line from the post in response to ridicule in the comments:

> "As it happens, I do write code others depend on--as it happens, a lot of it--and, my code has never, even once, failed in production: a record I am extremely proud of."

I don't even particularly ascribe to TDD, but the arrogance and dismissiveness and contempt of this guy made want to see him proved completely and utterly wrong.
Which is why testing behaviour not implementation is so important. Admittedly this sounds easier than it is in practice. Personally I've found that in-memory coarse-grained tests more akin to integration tests, that test from the outside in are helpful and easier to maintain because they tend to be less concerned with the how. I can then choose to write finer-grained unit tests where appropraite
/r/spacex discussion:

https://www.reddit.com/r/spacex/comments/3u2gwm/apparently_b...
>If you're doing TDD (or software development) like this, you're doing it wrong.

What do you think is the right way to do it, then?
Bah, if we want to start work, say, an hour after sunrise we can just do that now. We can trivially make an alarm clock that calculates sum position at a particular location. There is no technical reason that we need to argue over changing local time some even number of hours when we can do it exactly.
It was written by a professional comedian, so I wasn't excatly expecting incisive social commentary.
There is no such thing as bug-free app, and I do not agree for 100% code coverage (rather write test for what's important to you, i.e. prioritise). However, tests gives you a higher level of confidence when you perform refactoring.

PS. Regression is far worse than momentum against change, when your app is `broken` you can't deliver it.
I'd love to hear both sides of this story from experienced people (and not the ones who speak loudly one way or another).

We'll probably find experience on both side of "good" and "bad". I'm curious about the "bad" and how that comes about!
SpaceX rocket simulator
Yes, but the difference is less drastic.
When I read these kind of articles I'm always curious to see the professional background of the author. Not to criticize, but to see if he/she's talking about something he/she saw in scale or not.
Because if you're working with a very small code base then I may even understand sentences like "I am against unit tests in general". I've never met people who work (or worked) in very large companies being against, at least, unit test.
Where hundred/thousands of people touch the same code .. not having unit tests, in the long term, is a suicide.
Arborists Calgary – commercial tree services Calgary – calgarytreeexperts.ca
Calgary Tree Experts Inc provides Variety of commercial & residential Tree services such as removal, pruning, diseases & pest treatment in Calgary Alberta.
> "Trying to improve software quality by increasing the amount of testing is like try[ing] to lose weight by weighing yourself more often."

I realize this is probably here to provoke a reaction, but it's still retarded and it's obviously wrong for the obvious reasons.

> You are writing code to test something that doesn't even exist yet. I am not rightly able to apprehend the kind of confusion of ideas that could provoke such a method.

I agree TDD can be taken too far and be enforced too strict (although I've yet to encounter that in practice).

That said: It's not stupid to write tests before the code which you are supposed to test. The order of these things are here for a reason: If you don't write your tests before you have working code, how do you know your tests will detect a failure mode, and thus can be used to prove that your code is now working?

Just the other day I thought I had fixed a bug, and then proceeded to write a unit-test for it. The unit-test went green and I was happy.

But then I decided to comment out my fix and re-run the test. I assumed it probably wasn't needed. I was confident and knew after all that I had "fixed the bug".

But that way I could at least say I had followed the TDD mantra, which claims to be there for a reason: 1. write test to reproduce bug, 2. write fix, 3. rerun test and if green 4. commit.

Upon commenting out my fix and "needlessly" rerunning the tests, lo and behold: The test was still green.

My test failed to detect the error-condition. Which meant that my patch had probably not fixed the reported bug. Quality had not improved.

I rewrote the tests and managed to make them go red, that is, detecting the failure mode. Uncommenting my fix and rebuilding, my test was still red. My fix was indeed invalid!

Another round of investigation showed that I had misinterpreted the error condition and produced a "fix" which didn't solve the real problem.

And the "stupid" principles of TDD helped me detect a invalid fix, find the real issue and verify a real fix for it. TDD helped me increase quality.

Stupid indeed, eh?
How Data Lakes Open New Possibilities for Your Organization
Elon's reaction (quoted from Twitter):

"Congrats to Jeff Bezos and the BO team for achieving VTOL on their booster

It is, however, important to clear up the difference between "space" and "orbit", as described well by https://what-if.xkcd.com/58/

Getting to space needs ~Mach 3, but GTO orbit requires ~Mach 30. The energy needed is the square, i.e. 9 units for space and 900 for orbit."
Find Any Free Stream – Video Link Search Engine – Alluc
I work somewhere without any unit tests at all, and he still lost me at that sentence.

If he thinks test driven development can produce horrible implementations then he's right, they can. But he's horribly wrong that the solution is to abandon unit testing.

Without unit tests developers begin to live in fear of parts of the code, and refuse to clean it up "in case it breaks something", and there's no way to verify those fears aren't founded.

Any refactoring job starts with annoying a lot of people by breaking things that previous worked and questions start to appear from people that "it used to work before" when some of those breakages slip through to the customer.

Refactoring becomes something to fear because "we'll have to retest everything" which is a large expense that cannot be afforded.
Attach a volume to a container while it is running
The really interesting part is the discussion of optimizations:

> Consider this example raised by Linus: the compiler might look at how the kernel accesses page table entries and notice that no code ever sets the "page dirty" bit. It might then conclude that any tests against that bit could simply be optimized out. But that bit can change; it's just that the hardware makes the change, not the kernel code. So any optimizations made based on the notion that the compiler can "prove" that bit will never be set will lead to bad things. Linus concluded: "Any optimization that tries to prove anything from more than local state is by definition broken, because it assumes that everything is described by the program."

Programmers tend to assume that optimization is transparent--code will work the same regardless. But that's not really true, and as Linus's example demonstrates, compiler writers and compiler users may have different ideas of what the compiler is allowed to assume. And there isn't an obvious line to be drawn regarding safe and unsafe assumptions either.
Looks pretty nice, good job. I think survival analysis is a very underrated tool. I'm working in UX now and there's a lot of test setups were survival analysis makes a lot of sense but isn't used (mothly because people don't know it).
What you described having tests, not doing TDD. That is, it's important to have those test cases verifying that your APIs still work, but that doesn't mean you have to design the APIs by writing tests, as opposed to designing by thinking about what you actually want to achieve.
NY Times – Hollywood Women
Actually, I was talking about developers. In my experience working on projects that needed FDA part 11 compliance, it can be incredibly helpful to have developers that know how to write software that meets to compliance rules from process, validation, and auditability standpoints. I presume the same is true for SOX or HIPPA.
Building critical mass will be hard without Google Waze's promotion budget, but remember where Openstreetmap stood at its birth !
You should do your own research rather than believing their nonsense claims. Start by diffing their code against various Firefox releases.
Wow. This is the most unique setups I've heard. I did hear once about a person who got an internship at Facebook (if I recall correctly) over online in-game chat.
The "problem" with TDD is that it can only tell you that your expectations have been met. It can't tell you if you are doing the right thing. Only that the things you guessed at are working in the way you decided they should work.

If, on the other hand, your problem is not very well defined, then your tests have a good chance of eventually becoming a liability. If you ever discover that your domain model, interfaces, or even selection of algorithms are insufficient (or just plain wrong), it's more likely that your pre-existing test code will be unusable, rather than the sort of guide for refactoring that they're touted to be. If you had guessed at the interface or algorithms correctly, but merely implemented them incorrectly, yes, the tests will guide you back to correctness, but I think that tends to be a big "if". Given that you don't understand the problem, the likelihood that you've made mistakes in the design are high.

Of course, this isn't the fault of TDD, that's exactly what it's meant to be. The problem is in people thinking that is equivalent to verification.

TDD is ultimately a design tool, one that is useful in cases where we have a very good idea of constraints and requirements of a problem, on where the problem is very, very well defined.

And that's why I say it's a code-smell. The problems that are well-defined are often that way because several people have created several implementations of it already. If I'm TDDing something, it usually means I'm rewriting code that already exists somewhere.

Now, I might have good reason to do that. Perhaps I have constraints that nobody else has ever considered. I generally hate the phrase "don't reinvent the wheel". I can think of at least 3 times off the top of my head that the wheel was successfully and usefully reinvented in the 20th century alone. But it's very important that you understand that is what you're doing. If you are aware you're reimplementing a known solution, you can now choose to study your forebears and get an even better understanding of the problem.

Personally, I think saved REPL sessions are better than TDD for problems that are not very well understood or well defined. If I were to try to build an MPEG encoder in JavaScript (for whatever reason), I'd certainly use TDD, because MPEG encoders have specifically well-known inputs and outputs. But if I am trying to invent a completely new UI paradigm for virtual reality, then TDD is just not an applicable tool.

Also, it's a lot easier to tell myself to just discard a saved REPL session that ceases to be valuable after a major rethink in how the problem works than it is to discard tests. Plus, I find them to be a little more informative in terms of demonstrating behavior to other developers than test code.
"I am against writing unit tests in general..."

After this sentence I abandoned the article.

What kind of serious software don't need automated tests? Maybe the kind of no one uses.
My point is: If TDD leads you to bad design you're doing it wrong. You are probably not listening to your tests and you are probably not taking care to refactor towards a better design. Maybe you are even writing bad unit tests [1].

BTW, if any technique in software development leads you to bad design, and you don't stop and try to improve something, you're doing software development wrong. If a technique does not help you, you have two possibilities: Trying to do it better (maybe with outside help), or trying something different.

[1] http://www.makinggoodsoftware.com/2012/01/27/the-evil-unit-t...
Please, correct me if I am wrong, but the process he described is completely against TDD and no wonder it did not work (they wrote the function first, and added tests later, lot of tests, in TDD you would have rather more shorter functions with a few tests for each):

- Function A is 147 lines long. It is the simple core of the program.

- Function A is committed to the repository on June 26th, 2002. Function A has four test cases. Nevertheless, a bug is found in Function A on the 28th and a patch is uploaded on July 6th. It contains two new test cases.

- This continues a bit. However, by August 2002, function A is mostly stable and has no fewer than thirteen test cases--mainly for fencepost errors and other idiotic things anyone can find with a stack trace. Except for a blip in early 2003, function A, now 152 lines long, is unchanged until mid-2006.
Well, SpaceX landed their Grasshopped rocket after going up a kilometer. Then Blue Origin landed the New Shephard after going to space but not into orbit. And soon SpaceX might land their first stage after it goes to space and also pushes the second stage halfway to orbit. But in a sense SpaceShipOne had already done the same thing the New Shepard is doing and in another the Space Shuttle went all the way to orbit and back.
This is the Mel Conway of "Conway's Law" named by Fred Brooks in The Mythical Man Month. Don't skip it just because it seems to be about the F-35; it isn't. It's about complexity, concurrency (the risk thereof) and---at the very end---about abstractions for fitting huge systems into your head.
I don't recognise most this criticism. TDD is designing up front. But your designing only a little bit up front. You implement the design, if it doesn't fit, you scrap it and try again. That doesn't matter since its only a little bit.
A deal between standards groups could help make home IoT easier
What is "more often" ? Weighing yourself daily is useless, since the weight fluctuates too much. Not to mention that "weight" is useless as well, while you're actually trying to loose FAT. Fat percentage and resulting lean body mass (body weight minus body fat) are the metrics to measure. But still a waste of time doing it daily, twice per week to gain insight on the delta and where it's trending is enough.
That should be a choice up to each person with a sensible default. You could let users define home/work zones where no data would be shared. You could add a bit of delay to the data transfer to be able to say "don't send anything from the first and last X minutes of moving".

OSM is full of GPS traces volunteered from thousands or people. The NYC taxi data set is not that different and includes exactly the data you describe.

I very much find the taxi data a inconsiderate breach of people's privacy as I doubt they were aware that this data might become available. But I consider volunteered detailed trace data perfectly fine and actually necessary for a open platform as you cannot reproduce results otherwise.
The video was really exciting to watch. It does appear they come back much more rapidly than Space X but this might be due to video editing. I also did not notice visible attitude thrusters, was it all done via that main motor gimbal?
Fair enough. The information about this case, as opposed to the original story, didn't pop up in any other source I usually track, which provides an interesting example of another phenomenon - controversial stories get spread widely, but their retractions don't.
AMA with Man Who Went from Drug Runner to Founding Accounting Software Company
I think they might have beat SpaceX with their video production at least... great job! Also: the landing gear on this rocket is 10x more scifi than SpaceX's, so bonus points there.

I didn't know Blue Origin's goal was 4 minute suborbital floaty experiences for rich people though. Has that been common knowledge? Are they even interested in going orbital with non-human payloads?
There is a way out that he has not found (yet). To design with complete testability as a design goal. TDD with no supporting design can indeed lead to disaster. Hope he can paddle past the rant pond.
But that's because IBM has a strong presence in the SQL standard committee and can nudge it to standarise (post-factum) things they already implemented in DB2.
> Usually when I'm coding from scratch I write a very, very, VERY coarse-grained test that "tests something", and when I reach the point of passing it (which may involved creating and designing multiple classes) I probably have a working design and I may begin creating other, smaller unit tests for individual components.

That is exactly how I start coding something from scratch, except I don't have that initial test. I don't think such a vague starting test adds anything real.
The US Dollar is positively correlated with the price of things the US exports. And negatively correlated with oil prices because the US is still a net importer, though importing only about a third as much as it did a decade ago.

So you will see the dollar go up when world markets are robust for American products like software, jumbo jets, cereals, Wall Street scams, and Hollywood.
>I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development

The essay doesn't have the high quality of content I'd expect from PhD candidate in computer science. I'd expect less outbursts of passion and more discussion of pros/cons/tradeoffs.

First, without getting into "TDD" itself, let's just isolate whether "tests" are valuable. I think the examples of SQLite's rock solid reliability (extensive Tcl regression tests[1]) and NASA's disciplined software verification prove that tests help discover bugs and increase code quality.

Tests are valuable -- but they also have a "cost" to write. Let's cover the cost issue at the end.

When to write the tests. If the sequence is: write the code first and then the tests, you might call them regression tests. If you write the tests first and then the code (e.g. iterations to turn red FAILED into green PASSED), you can call it "TDD". And those TDD tests can still function later as regression tests.

To me, TDD acts as a "design" step or "outline" 10,000 foot view. Before any plumbing code is written, what do you want the REST API or group of functions to "look like". Is there unity and coherence to the collection of fucntions modeling the abstraction? The subsequent of fleshing out TDD with "expects()" and "asserts()" is just mechanical work to glue the edit+compile cycles to a verification target but it's not the most interesting aspect philosophically.

However, even though tests have a benefit, there is a cost. The cost-benefit works in some cases but not others:

In my experience, I'm completely sold on TDD (or regression tests) for foundational library type of code. If you're writing a core string library that 100 developers at the company (or open source community) will link into their projects, I prefer seeing extensive regression tests covering all edge cases that proves that it actually works the way the developer intended. It's not strange at all if the code for regression tests outnumber the actual code 10-to-1.

On the other hand, TDD that is mostly UI verification is extremely brittle. If you have TDD that simluates mouse clicks and has "expects()" on reading webpage UI elements to check if things like sales tax calc is correct, you could easily get overwhelmed by all the extra work that synchronizing the actual code and the TDD scenarios generates. (E.g. a UX designer moves an icon 2 pixels or adds a row to table and ends up breaking the entire TDD validation suite for developers.) I could see where TDD at that level would be counterproductive.

[1]https://www.sqlite.org/testing.html

[2]http://www.fastcompany.com/28121/they-write-right-stuff
just a sorry rant about how OP tried and failed TDD, and then he points to some project from 2004 that to me seems to be missing code ownership (ppl afraid of changing code they dont fully understand), but to OP seems to be doing TDD wrong.

it's a waste of time to read, as it don't bring anything new to the table. i wish the OP would at least attempt to reflect on what TDD is, what it's not and why oh why, so many devs seems to like it.
I'm sure SpaceX will land their Falcon 9 sooner or later but I think this goes to show that being able to hover makes things a lot easier. Real rockets can't be set to any throttle like in Kerbal Space Program, most can't throttle at all. The Merlin's ability to throttle down to 70% is impressive, and the BE-3's ability to throttle down to 25% is very impressive.
This is "required reading" for anyone interested in space program development. Not only Soviet space program but overall understanding on space related technological and thinking process evolution over 50 years.

In addition to this insights into Soviet leadership behaviour and thinking.
>You are writing code to test something that doesn't even exist yet.

To piggyback on this... sure, the code doesn't exist yet, but the project specs do. And unit tests can help by making the required specification explicit.