Years ago, my manager refused to let us use Test-Driven Development. His reasoning? “You have to write twice as much code, so it’ll take twice as long.”
That’s a false equivalence—assuming all code takes equal time and adds equal value.
For me, TDD is a thinking tool. It gives fast feedback, clarifies the need, and leads to better, cleaner solutions with fewer defects. The small investment in tests saves time by reducing rework, miscommunication, and debugging. It also lowers my cognitive load by making the work simpler and easier to manage.
“More code” in TDD doesn’t double the work—it often halves the friction.