Hacker News new | past | comments | ask | show | jobs | submit login

I'm pretty sure I lost a $150k job opportunity for saying that TDD is a waste of time if your product hasn't been validated as a money maker. I don't regret saying it either.

Fast forward a month and I begin working on a pre-profit project that is so bloated with tests and unnecessary complexity that it took me a few days to really figure out what the hell was going on with the code. When I first started reviewing the code, I was thinking, "Wow, this guy's testing chops make me feel stupid.". Then, after really spending some time with the code, I just thought, "WTF!?".

It's clear he spent much more time writing tests than writing any features. On top of that, he had written 10 level deep abstractions for features that had features for their feature's features. In order to really understand the insanity of this you have to know that this site basically had 0 users and was going nowhere fast.

Then I was just pissed. Pissed at the thought of someone just getting paid to implement every feature under the sun without questioning if any of it was really necessary and with 0 user feedback. This is one of those instances where the developer makes thousands of dollars and the site and owner just lose thousands. This is totally unacceptable and irresponsible in my opinion.

The first thing I did was start removing features and didn't write one test for anything. I would have loved to just scrap the whole code base and start over, but there just wasn't time so I just had to rewrite as I went. You would think with all those fantastic tests, the code would be pretty solid, but I continually found incongruencies and errors. The database didn't even have foreign key constraints set up for any of the relationships. Why bother using a relational database?

I know that TDD is popular and I've seen job descriptions like "If you are just getting started with tests, don't even bother.", but I think there are a lot of developers wasting a huge amount of time and money writing tests for products that are destined to fail, partially because of all the time and money spent writing tests.




I agree wholeheartedly about preemptive TDD: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

Almost nobody in the Rails community uses foreign key constraints with ActiveRecord. I chafed against it at first, but if you're drinking their validation koolaid, it wouldn't add value in most cases, since the validations can add stronger constraints with better exceptions.


I am not familiar with the validation koolaid (can you summarize it?), but from my experience, you want great constraints in your database because there may be more than one entry point to your database. If your software layers outside the database are your only entry point, then you might be able to do away with constraints...

But also in my experience with multiple developers working on changing the schema and adding new features that result in new data, we are often very glad the database has the constraints in order to keep people honest and not screw up the data during release transitions and even during development. If the software layers below that business logic do a super great job of handling the constraints, then this is not an issue.


That is just bad design; it has nothing to do with tests.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: