[latchkey]

> I just turned 50 in October

I'm turning 50 this month and a professional developer since I was about 21-22.

> I think the lack of TDD being as widely adopted

Hilariously, I just got -4'd (and a whole thread) for asking why someone didn't just write tests, instead of building some half baked tool to debug their websocket app. The responses were all sorts of absurd excuses. I'll happily take the negative karma, cause I know it brings some awareness.

(Now I'm getting downvoted again. Oh hn, you crack me up.)

[jasonlotito]

I dislike meta posts generally, but I'll give it a go so maybe you learn.

> Now I'm getting downvoted again. Oh hn, you crack me up.

Because you were whining about down votes.

Generally, when I see someone whining about voting, I'll vote down without a second thought, regardless of the content of the post. Why?

From the guidelines: "Please don't comment about the voting on comments. It never does any good, and it makes boring reading."

I know a good number of other people react this way as well.

Instead of whining about getting voted up or down, instead, use this as an opportunity to improve your messaging.

> I'll happily take the negative karma, cause I know it brings some awareness.

Up-voted comments bring more awareness. If you truly cared about bringing awareness to something, you'd want to communicate effectively, and effective communication is critical in our field.

Anyways, I generally hate meta comments like this one, but hopefully you have a better understanding of why people are most likely down voting this comment.

[latchkey]

Great response!

That said, my intention wasn't to whine. I truly don't care about the act of getting downvoted.

What I was trying to point out is that I was getting downvoted in my original post, because "kids these days" are against the general concept of TDD. That's in response to this OP's comment that I quoted.

Why were they against TDD? One person said it was because their CTO made them do 100% test coverage and that caused the startup to fail. Is that the failure of TDD or the failure of the CTO? ;-)

Now you're getting downvoted? LOL! For the record, I upvoted you.

[drewcoo]

The first rule of fight club is we don't talk openly about the meta-rules of fight club.

[bastardoperator]

I'm all about testing especially at the unit level but I've never personally seen TDD implemented successfully. I won't lie, I'll write my code, write my tests, refactor based on new learnings, check coverage stats, and PR for feedback. I'm also 40+ too.

[twic]

I have seen TDD done successfully, at a few companies. I think it's one of those things where you really have to learn it by doing it with people who already know it. I can well believe that there are people who read a blog post, started doing it, and got terrible results.

It also requires quite a bit of discipline, or commitment, or conscientiousness. It's worth it, but you have to be on the ball. It helps a lot if everyone on the team is experienced in TDD and positive about it, because you can all support each other.

It requires constant occasional investment, in building test infrastructure, updating older tests, etc. Often not a lot, and you can do it as you go. But sometimes, particularly for integration tests, you have to sit down and bash out some sort of framework to make testing tractable at all.

And it's possible it doesn't work everywhere. In my current job, i write a lot of applied maths code, and i haven't worked out how to test-drive that, because i generally don't know what the result should be before i start (i wouldn't need to write it if i did!). Sometimes i can make relative assertions ("the antimatter consumption at warp six should be eight times the antimatter consumption at warp three"), and sometimes i can calculate rough bounds by hand ("the antimatter consumption at warp one should be within 20% of the inverse relativistic mass"). But mostly, i implement something, then run it on a lot of data, plot the output, and decide if it looks roughly right.

[latchkey]

You're right, I didn't 'get it' until I worked at a place that was all TDD and I was surrounded by people who took it seriously. It wasn't about 100% coverage or any forced mechanics. It was simply a group of people who were all on the exact same page working on the same exact methodology. Almost a 'cult' of programmers.

> i haven't worked out how to test-drive that

That's exactly it. I don't always see tests as being necessary for greenfield code. You don't have to test drive it. But, you should write tests. Once you figure it out and have things in a place where you're comfortable, write a test so that when you go back and make a change later... you know that the code will break tests and you can be confident of 'change over time'.

[MoreQARespect]

I've seen it done properly with unit tests on algorithmic or decision making code (parsers, calculators, complex, deterministic thinking code).

I've seen it done properly with integration tests on integration code (CRUD, messaging, websites, etc.).

However, people do insist on writing unit tests on integration code and when they do it, it all goes horribly wrong.

[twic]

I was in the middle of writing a reply to the comment you replied to, when i had to stop because my app was crashing in staging, because i had written a unit test for integration code.

[latchkey]

I built an app that ran on 30k+ servers across multiple data centers and it had an auto update mechanism because the app needed to be routinely updated with new features.

I had an integration test that ensured that the app would start up correctly and that the self-update mechanism worked. Without those tests, any failure to start would cause me to have to "talk" to 30k+ servers to get it to install a new version of the app. (ssh into each server and re-install the app).

Automating that communication across that many servers (many of which could be rebooting at any time) and ensuring that they all had a running version of the app, was difficult to say the least. How do you even track that the app is running? (You end up having to have a ping mechanism too!)

Of course, I didn't start off with those tests and had to do things the hard way more than a few times. The thing is that once I added the tests, I never once had to do things the hard way again.

So, you can certainly do things the hard way, or you can just write tests and be done with it and work on features instead.

[stcroixx]

You're old enough then to have used message boards before they turned into a popularity contest with voting. It's easy enough to just ignore those features entirely.

[layer8]

I was about to upvote your comment but then noticed the contradiction in doing so. :)