Thinking of problems that don’t exist, and fixing them #agile #scrum #xp
Currently I’m developing something which has a learning curve, not so much because it is difficult to understand it, more because there are portions of it which seem illogical. I could delve into the issues I have, and this may become a more technical article, and that’s not what I want to discuss here.
The current project I’m working on has a reasonably complex business logic which it implements, adding to that a untried and unknown technology and it’s a receipt for a difficult sprint – meaning it’s difficult to correctly estimate the complexity of tasks within the User Stories. This makes it ideal for applying Test Driven Development. The advantage of TDD in this case is that an assumption is made when writing code, expressing this assumption in a test before writing the code makes it easier to verify this assumption.
Programmers, including me, are very good at “thinking of problems that don’t exist, and fixing them.” Test Driven Development gives me the advantage that I can express my expectations in a test, and assert the requirements which need to be met for a test to pass or fail. In this way I can postpone the fixing of this fictitious problem until the time that an issue occurs.
An added advantage is when issues occur. Programmers – like me – are often focused on the details of the implementation, which means that we will see potential issues and blame side-effects of the current code rather than focussing on the issue which is occurring. Creating incremental tests as evidence that the code is working correctly can help bolster your position and support your argument that the error is outside your code, it also has the advantage that other developers will immediately see that their changes are causing side effects. This is far more effective than creating a one-time proof.
Image source: Jerry Wong