Fast forward a decade to 1994. The company I just started working for used exactly the same video course. The only things that had changed were that I had 10 years of experience since the last time I took the course, and the hairstyles in the videos looked even more ridiculous. When the instructor asked if there were any questions after going over the 1–10-100 rule, I raised my hand and asked “What does (the company) do do recognize and reward employees who find and fix things at the 1 or 10 level?” He seemed taken aback, and mumbled something about God and Country and the Right Thing To Do. I persisted: “Obviously, for (the company), it’s good when their employees take this to heart, but how does the company prove that they like this to the employees?” More blathering from the instructor including “Look, OBVIOUSLY you will be rewarded better if you find and fix things earlier.” to which I replied “Really? In my experience, companies recognize and reward employees who fix things at AT LEAST the 10000 level. Those are the employees whose names are known by the CEO of the company, and they get a pat on the back, and money, for putting out fires at the customer, even if they are the SOB who screwed it up in the first place.”

Since that time, I’ve spent most of my time working for chip companies. They seem to do slightly better than at least a few of the other places I have worked at the whole “nail it early” thing, partly because of the cost involved in making a mask set, and partly because of the opportunity cost of having to wait many weeks for a chip re-spin. Unfortunately, there is still an “assumed competence” that people are allowed, which is often far too generous, and lets really simple things slip through, simply because a very few developers are truly incompetent, and relying on them to do any coding, much less to unit test their own code, is a recipe for disaster. (This is a different category of people than the junior developers who just need a bit of mentoring. These are people who have managed to careen through a career with a thin veneer of being at the right place at the right time.)I wish I knew of a better answer to this than simply “document all the screwups as thoroughly as possible, and maybe one day they will fire the bastard.”

I still spike a solution to see that is is feasible and also use TDD. I think you are (as does just about everybody) missing the point of TDD. You don’t write the complete test then the code. You use the test to drive out the design. You might, say, write a test for a game that has a score and it can be zero. When you run this test it should fail. You then implement the code and the test passes. You might then write the next test saying the game can only have a maximum score of 100… and so on.

You use the test to drive out the design. The tests that you have in the end are a bonus. Also you will not suffer from YAGNI.

I don’t alway TDD (testing legacy code for example), but I have found it useful when you understand how and why it should be used.

It might just be the industry that we are in, but when buying our software, most clients do their own acceptance testing on it for their own audit processes. We actually ship a copy of the forms for doing the acceptance testing with our software (just in case anyone gets any bright ideas and does something fancy!).

Additionally, I find nothing beats long-term production use as a test tool, but this takes years.

http://jessenoller.com/2008/08/12/steve-yegge-h…

That said — I firmly believe in a strong test suite of both units and functional tests once you’ve got something that’s slightly firmer than quick sand.