Does TDD Lower the Barrier for Dynamic Languages?

I practice TDD (Test Driven Design) – Red-Green-Refactor. In doing so, I have come to realize how certain development tools are not as important as they used to be before I started TDD.Before TDD:The compiler was very important to me. I would spend hours, maybe days, coding away (Don’t lie, when you first started developing you did the same thing). When I was finished I would compile. The compiler would tell me where in my code I made mistakes. I would then spend the next several minutes/hours trying to fix the mistakes.The debugger (println) was just as important. After fixing all the compiler errors, running the code for the first time was scary. The first run never worked. I had to use the debugger to find the “bugs”. This process could take hours/days. When I finally found them “all”, I could then start on the next task.After TDD:I write code in such small chunks that if the compiler finds a mistake, it takes on the order of seconds to find and fix the problem. No more wondering: “What does that compiler error mean?” I rely so little on the compiler, I often wonder if I really need it. As for the debugger, I am guessing that I have used it a total of 3 times in the last 2 years. I am pretty sure that I could do without it.Conclusion:What does all this mean? Do we need these tools? Can we use other languages that don’t have these tools and still be just as productive?There are a lot of people that think that dynamic/scripting languages are not for real work. They think that you cannot accomplish big things with that type of language. You need strict rules of the compiler to help you manage the complexity of a large project. What will you do if something goes wrong? A debugger will surely be needed (most dynamic/scripting languages do have a debugger, but it is not pretty).With TDD, you don’t rely as heavly on the compiler/debugger. Can TDD help lower the barrier for dynamic language acceptance? If you take a look around the user groups of some of the most popular dynamic languages, you will see a who’s who of the Agile/TDD world.I predict that as TDD becomes a more main stream development practice, we will see a dynamic language be the language of choice for Corporate America. Dynamic languages have been popular, but they have never gained acceptance in Corporate America. I think that TDD will help bring a dynamic language into main stream Corporate America.Thoughts?


One Response

  1. I realized the same thing after much time spent writing stub objects that turned out not to be necessary when I wrote in a dynamic language. Me and some of the developers I work with are looking forward to the day when the compiler’s iron grip loosens in corporate America. In fact, we figured out how to avoid the compiler using JScript inline and still test-drive in ASP .NET, It’s pretty cool. But we still work with many developers who don’t like to test-drive… and, as a result, they still like their compilers. It’s like a downard spiral or anti-pattern. It seems that the interest in dynamics follows a solid understanding of TDD. Yet, it’s hard to encourage TDD without a dynamic language… I’m beginning to think that the best thing would be to try to keep TDD and Dynamic languages together and not teach one without the other… I’m still considering…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: