If you ask your fellow team members to explain what they understand by ‘Test Driven Development’, today you are likely to find very few common thought lines.
The reason behind this is not vague understanding, it is different application knowledge.
If the only tool one knows is a hammer, everything looks like a nail.
Similarly when somebody begins doing ‘Test Driven Development’, the initial learning curve to accept the way of writing software is pretty steep. There are no standards. One tendency is to copy and not think. Because there is no reference, One can either be happy with the frog-in-a-well living or completely insecure with the efforts. Whatever the case, getting things right in the first place is hard learn in the initial stages.
With continuous efforts and trial and errors, one can eventually discover the best practices by experience or by referencing the experts in the industry.
As a software architect, when a system design is completed, there is effort needed to bring all the developers on the same page.
I am trying to think on lines of documenting my experience and information sharing to get everybody to generate the common minimum standard output expected as a developer.
That is another problem to be solved.
