We have been working for a project for big telecommunication giant in US. I have a team which enjoys working in an Agile (so called) team however they are not aware of the methodologies and the efforts in educating them are not fruitful because they deliver quality work on time (every time). Management is happy and so are the team members.
So what’s the problem you may think, it is all in my mind (I guess)…to begin with. What’s going in my mind is the question “How bad can TDD go”, the answer is as bad as the developers working in the team.
For those who don’t know, Test-driven development (TDD) is a software development methodology (used in XP) that uses short development iterations based on pre-written test cases that define desired functionality.
The sequence of development should be:
1. Write the test cases based on required functionality.
2. Test run the test cases, they will fail.
3. Start coding the functionality enabling each test case to pass. Keep executing the test cases to verify.
4. Deliver when all test cases have passed.
How my team does it:
1. Coding the functionality.
2. Write the test cases based on the code.
3. Deliver after testing that all test cases have passed.
To my surprise, I found out that this problem is not unique and limited to my organization, there are plenty of such examples available across the globe. The problem it seems is the motivation to use TDD comes from the fact that people want to use something new and tell others about is (prospective clients). They are unable to realize the importance of the new thing (technology/tool/methodology), hence they don’t get the benefits and end up blaming the methodology/technology.
TDD was and still is a very good technique for test-first programming concept.
Posts
