In the podcast of test && commit || revert with Kent Beck and Scott Hanselman, they talked about this alternative workflow, which focuses on avoiding the investment of time on a false change that can later lead to cause fallacy. The idea is that everytime a test passes, you make a commit, but if there is a problem you revert to the last known green state.
What I found interesting is that they agree that is a wild idea, but because it is cheap to experiment with and works out, it is also an awesome idea. Why? because innovation and growth only come from new experiences and it isn’t likely for someone to compete with you for it.
My only experience with TDD was when I saw it as a topic in a class and practiced it with a small assignment. My interaction with TDD may have been small, but with that I learned a lot of things from it and I understood the sense of security it gives you, from the beginning until the end. The work you do that seems pointless at first, results in a lifesaver later on.
The other thing that I found interesting is that even if TDD and TCR (test && commit || revert) are based on the results of tests to move one, each one has a different incentive. While TDD assures your that your code works in each addition, if something fails it is easier to pinpoint the failure, while the same can be said for TCR, it mainly incentivates the programmer to make smaller changes in a stable way, the tought goes to the sequence of the changes rather than the test themselves. There is a greater expense to every step you take but there is a lower probability that you would do a bunch of work and have to throw it away.
You may be taking tiny steps, but you are making progress towards a state while continuing to deliver value. And this philosophy can also be carried to other programming styles, for example, when you make a change and all tests go red, as Kent sees it, it is most likely a design problem, so ask yourself why this is happening, what design would solve the problem and finally, how can I get from where I am now to that new design in small safe steps that allow to give functionality along the way? Which is better that making big messes even bigger.
And the final lesson that I got from the podcast is that learning involves emotional engaging and that everybody is responsible for their own learning, which is something that seems obvious, but is lost in the current educational system, which focuses more on the responsibility of the teacher to that learning. Each one of us has different learning styles, and different topics of interest. No one learns the same way as another person, so it is our tasks to find how to learn. In this sense I acknowledge that there is a lot for me to learn from testing, there are other workflows to try and a bunch of testing frameworks to discover.
Ubora 