Quick Rex about 100% code coverage
read comments here
TLDR; maintaining 100% coverage brings many benefits, you need to try it.
A few years ago I blogged about aiming for 100% code coverage for your tests. This post made some noise and the feedback was essentially negative. I was even called out as a troll a few times…
Being stubborn and dedicated, I understood I needed to put my money where my mouth was, and start to practice what I preached. I did and this post is about what I learned by reaching 100% code coverage for my tests.
Continue reading “100% code coverage is good”
My previous post, XP revival, dealt with the positive trend around XP as a project methodology. I explicitly stated that adding Craftsmanship practices on top of Scrum does not mean that you’re doing XP. In this post I am going to answer the explicit request to elaborate more on that topic. It is a well-known fact that Scrum prescribes no engineering practice, leaving teams choosing the ones they see fit. A strategy that led more often than not to what Martin Fowler coined as flaccidscrum, projects which velocity drops to a halt. This situation also contributed to the birth of the Software Craftsmanship movement, which aims at raising the bar for code engineering practices. It also stresses out that a coder must make those practices his own responsibility.
Continue reading “Scrum + Craftsmanship != XP”