I once consulted for a large development shop that produced billing software. They had over 10,000 developers and mixed .NET, Java, and C++ in products, subproducts, and intertwined projects. The software had existed in one form or another for over five years, and most of the developers were tasked with maintaining and building on top of existing functionality.
My job was to help several divisions (using all languages) learn TDD techniques. For about 90% of the developers I worked with, this never became a reality for several reasons, some of which were a result of legacy code:
- It was difficult to write tests against existing code.
- It was next to impossible to refactor the existing code (or there wasn’t enough time to do it).
- Some people didn’t want to change their designs.
- Tooling (or a lack of tooling) was getting in the way.
- It was difficult to determine where to begin.