Comment by hello_moto | Hacker News Reader

Comment by hello_moto | Hacker News Reader

Parent Full thread

I agree with you: if it works for someone else, good for them. Definitely.

I think the main reason why people want to burn your article to ground was because there are way more companies out there that would benefit from their people writing unit-tests.

Now when some lazy developers who think that they're smart starting to quote "the VP of Software Development from JTV sez unit-test is useless", then we have a problem there. These passionate software developers don't want to go back to the time of Wild Wild West where coders slinging code with no reasons and start throwing incomplete shitty crap to QA and call it "DONE", get the gold medals from their team lead for being able to solve things very fast.

You know that movie... Spiderman? "With Power comes great responsibility"... since you're advertising how cool your company is and you're their "VP", then there's that responsibility attached with it.

The thing is, it requires a smart person with high level of discipline, strong principal, and the ability to say "No" to crazy requirements in order to have the luxury of not writing unit-tests. Especially when there's no safety nets (I mean QA) around that person.

I hold nothing against you though.

I think the main reason why people want to burn your article to ground was because there are way more companies out there that would benefit from their people writing unit-tests.

But he's not the only bright dev who tried it an ran into issues or lack of benefit in doing it. The thing that I seem to read from the more zealous of the TDD crowd is "you don't know what you're doing -- you don't understand code/software/testing/development if TDD doesn't obviously work for you".

My concern then is if a large percentage of strong devs don't seem to "get it", does it make sense to push into an organization w/o strong devs?

And the reason I asked the other question about the "hacker gods" is that outside of Josh Bloch (now), I don't really know of outstanding devs who do TDD in a big way. And this scares, because I remember when I used to have certain devs tell me that UML was the way to do everything, and if I didn't use UML throughout the product lifecycle I was no real software engineer -- and UML was the only way that in 20 years people would still be able to understand the design and code. I pushed back on UML and don't regret it for a second. I don't feel like I'm going to regret pushing back on TDD/BDD so far.

Maybe the confusion comes from conflating unit testing with TDD. Different but related concepts. If you write a unit test after the code, that is no longer TDD.

TDD is a major change in coding style and doesn't seem to work for a lot of people, including myself. Unit testing, on the other hand, is absolutely essential and fundamental to the task of building large, complex systems.

I haven't read Coders at Work, but if the guys in there are doing their thing without some kind of automated testing, I would be very surprised, and I'd wonder why they're making it so hard on themselves.

But on the other hand unit testing isn't the same as testing. Integration tests, regression tests, stress tests, "miscellaneous automated tests" are all valid sets of tests.

Have you used a language with strong static checking? It might change your mind about the central role of testing. I'm not saying tests are never necessary in such languages, but you can expect to spend orders of magnitude less time thinking about them.

Random guesses are a poor substitute for logical certainty.

You're confusing TDD and unit-test... and unit-test is not the only safety net around.

Take a look at Dr. Hipps projects. I believe almost all of them have a suite of test automation.

Keep in mind that there was no unit-test library for C/C++ back then. Even now, the unit-test libraries for C/C++ aren't as solid/easy-to-use as those in Java, C#, Python, Ruby.

The software back in the age of Ken Thompson, Dennis Ritchie are different than what we have these days as well.

I agree with nostrademons, some of these so-called "great developers" that you follow, they don't do maintenance programming. They seed a project and let someone else maintain it. Similar to the much-debated "software architect" role; when you don't feel the pain of maintenance programmer, you don't know what's wrong with the process.

Update: UML still exist today. For certain projects, there are values for using UML especially for communicating between people across different functions. Just like anything else: when you abused it, it starts to crumble down.

Reply on news.ycombinator.com