Skip to main content

Deals You Can't Miss

1 Year Subscription

What is so wrong with TDD?

This question was posted recently in Quora. I read other’s answers first and felt an itch to share my thoughts on it. Thereafter, I published it as a post in Hackernoon which caught a zillion eye-balls and heck a lot of readers time. 

This post is a re-production of that after a good couple of years now, for I think this is still relevant.

I hate TDD (aka Test Driven Development) and think there are a lot of things wrong with it. Only some of them off my mind are below.
copyright: codonomics

In a team practicing TDD for quite a long time:
  1. the after-hours time of spending time in office, fixing bugs that keep propping every now and then is now gone.
  2. the opportunity for lonely bachelors to compete with family-oriented colleagues by working sleep-less in office is gone.
  3. the opportunity to intelligent code rather that readable/maintainable code is largely reduced.
  4. the easy opportunity to look hard-working is gone. I now have to really work hard to look smarter with this TDD, CI and stuff that forces discipline in what I do. I hate it like hell.
  5. the team’s dependency on me to understand code and its functionality is reduced big-time because the tests act as spec or documentation that talks for itself.
  6. the easy opportunity cost of amassing a ton of money from my clients for code-refactoring or feature change requests is minimized in a big way.
  7. the cost of manual testing in terms of time and money is greatly reduced. This practice killed so many QA jobs.
  8. the easy chance of developer blaming the QA for the bugs is a bygone era.
  9. evolutionary design and architecture is made possible, making me code everyday. Earlier I used to brag myself as Architect that doesn’t code.
  10. product go-live anxiousness is nowhere to be seen. Every release used to be a big event earlier.
  11. and on and on…

Teams that has refrained from TDD has the following points by their side:
  1. TDD is for the average Joe. My team has no place for him.
  2. TDD is so damn un-intuitive and really weird.
  3. TDD is for those junior developers who are not adept in up-front code design.
  4. My teams has just seasoned developers and domain experts who have been coding this product right from its inception. They are solid hackers. They don’t need TDD.
  5. TDD hurts our productivity.
  6. TDD is for those large process oriented enterprises. We don’t have the luxury of time.
  7. TDD is for those chaotic start-ups that has no processes in place.
  8. TDD is like buying all the lottery tickets to win the lottery money.
  9. TDD is no science. We don’t believe in things that not scientific.
  10. TDD is not magic. Bad test code is worse than bad regular code.
  11. TDD is so broken. I have not seen 2 TDD specialists solving a problem the same way and using same tool-set.
  12. and on and on..

Let us work together to stop the practice of TDD and bring the old world of chaos and uncertainty.
Devil: “Let us work together to stop the practice of TDD and bring the old world of chaos and uncertainty. Game?”

NOTE: This answer is a parody of the devil inside a developer. You’re expected to have a loud laughter reading this, instead of embracing it. You sure will do good to think about these points instead of dismissing it right away. May “peace to all” be our driving factor. Cheers!

Hoping you would care to show your love for this written work of mine by.., I am sure, you know what to do. 

You may also up-vote this answer of mine in Quora. Thank you in advance for your encouragements :)

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t