I think the majority of the points here (which are good!) can be summed up with the "You are not a special snowflake" heading.
This particular form of arrogance (let's call it what it is) permeates throughout most sub-communities of CS programming. Ruby is just one tribe. Lispers are another. Game studios, web app developers, a different product team inside the same company, [insert pretty much any other here]... they all believe/rationalize that they are different to Java, and thus have nothing to learn from all those enterprise projects. Even HN has a particular anti-unit testing tribe that will turn up as soon as any article appears that says "Hey, Test Driven-Development is pretty good, huh?" who will complain that testing hurts velocity (it doesn't, see Etsy for a great example).
It's an arrogance that inevitably leads to the issues brought up in the article, taking out a huge technical debt that some other chump has to pay off. I'm not sure how this will ever change. I guess the conclusion is just to try and make sure you're not the chump.
Which side of the example is Etsy supposed to be for that, exactly? They make a lot of changes, and supposedly do a lot of testing, but if you're actually paying attention to what's going on there (and the overlap between Etsy fanatics and people who know what TDD is are pretty small) they have constant stream of small problems. Many people I know who are serious Etsy users complain that the site changes too frequently, has tons of glitches and is confusing - most serious ones were overwhelmed years ago. Just thought I'd let you know since you're using them as an example of something.
No it doesn't. Well, I mean, sure, it does in the context of physics, but in regular English speed and velocity are pretty much the same thing.
On the other hand, velocity has a specific and well-understood meaning within agile software development, and that's what the antecedent post was referring to.
Of course, if you were just being snarky and implying that Etsy are completing plenty of nominal work without it resulting in any actual progress, then carry on :-)
OT, but you remind me of a joke a math professor made in a Calculus III class: A vector has both magnitude and direction, not to be confused with our university newsletter (The Vector), which has neither.
I know you were being intentionally facetious here, but this does nicely encapsulate "How Project Managers and Developers Fuck Agile".
Use of velocity outside of calculating capacity and extra demands being placed on the team is broken; yet I've seen Project Managers terrorize their charges by using it as some kind of fucked-up productivity measurement. For a developer, if your estimates don't include time taken to properly test and develop the user stories, you are lying. You're lying to the business, you're lying to the team, and you're hiding technical debt. As a developer, you get final sign-off on how many points you assign to a story - don't fuck up this 'simple' task :-)
We're not anti-testing. We just think that certain classes of error are better caught at compile time by the type system than at runtime by unit tests, which can even be more lines of code than what they're testing and still miss an edge case.
Testing is good, but it hurts the ability to churn code quickly. You get stuck with a bad design, because it's too expensive to re-write all the tests.
Now, I think it's good to do a few high-level smoke tests first, to help nut out the interface. (It's much cheaper than having lots of meetings with the boss drawing boxes on a whiteboard, or worse, writing specs). But good test coverage is something that can often wait until fighting bugs becomes a pain point.
This particular form of arrogance (let's call it what it is) permeates throughout most sub-communities of CS programming. Ruby is just one tribe. Lispers are another. Game studios, web app developers, a different product team inside the same company, [insert pretty much any other here]... they all believe/rationalize that they are different to Java, and thus have nothing to learn from all those enterprise projects. Even HN has a particular anti-unit testing tribe that will turn up as soon as any article appears that says "Hey, Test Driven-Development is pretty good, huh?" who will complain that testing hurts velocity (it doesn't, see Etsy for a great example).
It's an arrogance that inevitably leads to the issues brought up in the article, taking out a huge technical debt that some other chump has to pay off. I'm not sure how this will ever change. I guess the conclusion is just to try and make sure you're not the chump.