Quality, Timing, and a Clash of Values 2
I came across a quote in something I was reading, and I can’t recall if it was a blog, a cartoon, a book, or what. A young woman was talking to a politician and asked if he had to make a lot of compromises. When he admitted that he had to compromise a few times, she shut him down by saying “you can only compromise your values once, and after that you don’t have any.”
I had a talk the other day with a fellow mentor, and brought up line only to have it returned to me (with top spin!) when we were talking about when would be the right time to turn on an older suite of tests in CI.
I finally had a chance to examine the decision point. Of course, it’s always the right time to turn on more tests. When do you not want to know if your code stinks? On the other hand, I knew:- these forgotten tests were not used by developers, and so are of dubious quality
- the team in the middle of a big stabilization crunch
- the team is in their final coding week before release.
While they need to know their code and test quality soonest (preferably before release) there was emotional foot-dragging on my part. I knew that they didn’t have the headroom to even triage the old tests to see if they should pass.
The problem was not of compromising my principles so much as choosing which of my principles would have sway. On one hand, the quality driver knows that we need more tests sooner. On the other hand, I knew how close the team was to being overwhelmed to the point of shutting down. My nurturing, coaching “spider-sense” kicked in when I wanted to turn on the tests, and my XP quality-driving “spider-sense” kicked in when I thought about not turning them on.
I decided to wait only a week, and then get the tests turned on. Was it the right decision? I can’t tell. I am truly ambivalent; both drawn and repulsed by the decision. Sometimes the good is the enemy of the best and it’s hard to see which is which.
I chose to be the kind of guy who would err on the side of compassion. It’s the more personal and superior of the two values. Having decided, I move on.
But now it’s time to get those tests running, and sooner is better.
I think you made the right decision, because the name of the game is feedback. Sounds like turning on these old tests would introduce more confusion initially than good feedback. Untrusted failing tests don’t provide good feedback. So, you’re options sounded like (a) a week of uncertainty not knowing if those tests would provide good feedback and (b) a week of uncertainty not knowing if those tests were providing good feedback.
Tim, the woman in your anecdote, as written, seems to me an “idealist”. If compromising any of your values implies that you no longer have any values would also mean that all of your values are equally weighted and absolute. One can continue the metaphor and point out that the politician may have compromised, but may have also accomplished tasks that never would have come to pass had he/she not been willing to compromise.
So when you look at the real world and the fact of competing values in development, I also agree you made the right “compromise”. Sure, it’s always the right time to add tests that improve your quality. But in this case, the sudden addition of tests of dubious quality distract the team and could lead to a short-term reduction of quality. I believe the right call was made because you kept a “blocker” from stopping the team’s forward progress.
Consider: if the tests were turned on and were broken, and a developer had to spend 2-4 hours fixing them, ultimately to determine the tests simply needed “clean up” and brought up to date and did NOT identify any actual bugs, then… Should this 2-4 hour period go up on the ‘waste snake’?