See, now i don't know what to put on the census form. Is my religion Apple now, or am i still a Jedi? Am i a Jedapple?

I've been working for a company which does a lot of Test Driven Development (TDD), but quite honestly, we don't develop new products all that often. We have legacy products (10 years old on average) that we work on day in and day out which in some cases are abhorrent. However, we don't try to fix the world by taking a year or two off to add comprehensive tests to the company's products, we just test anything we add or modify. Slowly but surely, you will add value to your products and the stuff you're complaining about will start to happen less often.

I would submit that you don't need to ask for permission to do this. YOU are the developer and it is YOUR mandate and responsibility to produce quality software. YOU know how best to do this, so just do it, and build it into the cost of your estimates. At first, while you get used to it, things may slow a little (not as much as you might worry about). However, once you get rolling in practice we see that things don't take any less time than they did before, and eventually some things will take less time than before. Did i just say that right? In fact I did. The difference is that the same old bugs for the same old reasons simply don't occur anymore. We just have fewer bugs coming in against our products. We KNOW that once we fix something it will stay fixed tomorrow, next release, next year, and for all of time until the spec changes (don't be deluded into thinking it won't...). We have tests that say so and will not let the build pass if at any point that feature no longer behaves as it should. In practice, whenever we add tests to legacy code that we just happen to be modifying, we aren't surprised to find out that it doesn't work the way the specifications say that it should work.

Testing isn't there to speed you up. It's there to not slow you down (among many other wonderful benefits). It's there so that you can say that you *KNOW* that your product works in certain ways. It can be hard to start writing tests, but someone above mentioned a book "Working Effectively With Legacy Code" (Michael C. Feathers), which is an excellent resource to get you started. Here are some others:

- Test Driven Development: By Example (Kent Beck)
- Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
- Refactoring: Improving the Design of Existing Code (Martin Fowler et al)

You don't *have* to adopt TDD as a daily life routine to reap the benefits. Some of these books and other reference it as an excellent tool to enable you to write better tests and better code, which i think is true. However, these books also teach you how to tackle existing code and to get it under control by writing tests for it. You're doing yourself and your products, and your employer a disservice if you don't write tests for the code you write, even if your employer cannot see the benefit. I'm sure surgeons could get stuff done a lot faster and cheaper if they took some shortcuts and didn't bother to sterilize their equipment, but they know better than to do that. You should know better as a developer than to just hack something together and run it by some visual inspection of limited "use cases" and then think that you've done your job properly. Your code may not work at all, and you won't even know it until a customer tells you so.