The podcast test && commit || revert with Kent Beck shows a really good perspective about testing and let us look a little bit of Ken Beck’s mindset. It’s really interesting that Scott Hanselman proposes a way of looking at a software project as something to be feared and that coding should be around avoiding failures, but Kent Beck has another mentality, he thinks that DevOps and testing is about reducing fear and generating confidence. I like that he was able to look at the positive side of this huge problem programmers have, that is avoiding making changes to the code because of fear of breaking it. It’s really important for programmers to have confidence in making changes, writing new code or adding new features because it’s what makes us feel productive. Of course, seeing it all break and not being able to find the problem sucks, but the point of testing is to avoid these things from happening while allowing people to make changes.

Another common topic they discussed is TCR or test && commit || revert, a methodology that consists on reverting all of the commit if the tests fails, only allowing green code to pass the commit. This is a problem for a lot of software engineers because we are used to commit code that represents a complete function or feature, this methodology suggest that we only upload code that works and that forces the programmer to do very little changes that should work, otherwise it will be dumped and nobody wants to risk hours of their work. Thats why with TCR is better to commit changes every minute or so. The whole point of this is to keep the tests on green and increase confidence in the team. I like that he figured this way of working by trying stuff that he did not like, it sounds unintuitive at first but after trying it in a small project he learned the benefits of TCR. Some people correlate TDD(Test Driven Development) with TCR, and I see the point, both are methodologies that forces the programmer to create tests first and then run the tests several times while modifying the code until all tests passes. However, TCR is a more drastic approach that pushes and encourages more than anything else that the code is always working and test is always green. This is of course still an experiment, perhaps it’s really hard to implement this methodology in a larger team or bigger projects because people need a complete change of mentality and habits. We still have to find out if it is really worth it to change the way we work with code, but for that we need to try it by ourselves. TCR sounds painful, but after some repetition, we might form ourselves the habit of committing small pieces or redoing our work if it resulted as a failure. I think that we all should be like Kent Beck in the sense of experimenting new stuff for the sake of learning how to do something better, even-though this seems counter productive.