TDD can not be a remedy for bad code

TDD can not be a medicine for a bad code. The only way to write a good code is to have a good problem solving team and method. And a good problem solving method requires a continuous and open communication. A clear written and spooken communication.

I truly believe that the main reason we write really bad code is because we don't understand the problem we have at hand. And when we assume we understand the problem we don't communicate it with a team. Having a good grasp of the problem at hand as a team can make a huge impact on the success or failure of your software development.

Instead, We hear a group of intelligent sounding people talking about Angular or any new shiny framework or tool. And we abandon thymeleaf (or whatever we were using) and rush to it. We didn't take the time to truly understand what was wrong with thymeleaf. We just thought that was the problem.

Now, we have a really bad Angular application. We keep on updating it to the latest version. Adopting new techniques, moving services around, etc.

Then TDD is proposed to fix the bad code. Techniques to write a really good unit test is discessed. Stuff like grouping our precondition on a describe block, etc.

Managers enforce writing unit test for every new code, with a minimum code coverage of 80%. SonarQube is set up as a gatekeeper to every PR.

Then we just hope that would solve the problem. We forget tools are tools. At the end of the day, they requires humans.

Understanding the problem

To solve any problem one must first take the time to brain storm on the problem itself.

1. Openly brain storm on all the possible causes of the problem. This is of course better with a group of equals or peers. No dominating manager in the room please.2. Then narrow down the possible culprits. Break down the problems into small pieces. List them interms of priorities and impact.

Only after those two first steps should teams propose a solution.

3. And all solutions must be listed. 

Then teams can divide and conquer in implementing the proposed solution of the identified problems. With a tiny portion of the project at a time. It is important to pick a small section of a very big project and work on that corner to validate and measure the outcome of the proposed solution. Hence our fourth step is:-

4. Validate and measure.

Finally, we don't want to stop here. We want to iterate and go back to step one.

5. Repeat.

TDD might be a solution to a problem

TDD of course is not all bad inherently. It is just the way we diagnose problems and give solutions that seems broken in most software teams.

The successful software teams I was a part of focus on the problems they actually have. Not on the problem the industry has. Then they work on those problems small pieces at a time. And if a software team goes through the above problem solving or any alternative, and find TDD to be a good solution, then fine.

But on most other teams I see TDD being proposed as a solution to complex coding problems that are caused because of complex human problems. After all, those problems arise from lack of trust, communication and technical leadership. Adding TDD on that pile of mess just makes the whole thing worse.

May be TDD might be a good solution to a corporate environment where the main competency is just to do nothing. Because at times writing a meaningless test to a meaningless code just seems that.