Domain expertise has a great value especially in development. In fact, it can be crucial for success. It also has a downside. When development becomes so engrained in the prevailing culture, it becomes easy to continue and even encourage bad habits.
Inevitably, a certain way of doing things will evolve during a product’s lifecycle. It becomes are part of the culture, and is learned and repeated by new developers on the project. In knowing a codebase, it is far too easy to think in the same manner. The path of least resistance is sometimes the only one you see, and even when it’s not you may not feel you have the time to change. The way its been done already is too deep to change in time for your next release.
Been there. Done that. Many times.
I advocate TDD for many reasons. Clarity, maintainability, and adaptability being among those. Sometimes I see code and have to wonder what in the world was the author thinking. Not just because of style or buggy-ness, but code that literally looked like it shouldn’t work. Plenty of times, seen uncommented code which was as clear as mud.
Avoiding the rut while becoming a master of the domain isn’t easy. Unit Testing is a good way to do it. You’ll learn while coding and develop clarity in the codebase. Additionally, you will be setting the stage for better habits and maintainability in the future.
Roy Osherove has a .Net Unit Testing book, which was just published. It would be a good way to learn more about Unit Testing. It’s on my reading list.