I picked up a term that I have not used in all my years of programming, and I love it: “Drift”. As in “Specificaiton Drift”: you write the spec at time T, implement at T+1, learn something new about the problem domain in the process and adjust your implementation (you know, normal programming) at T+2, then at T+3 the spec doesn’t reflect the reality of the code base anymore.

Continue reading …

Why change perfectly servicable code today when there are problems to solve? “I’d be changing it again next week. So where’s the value? Might as well keep it as-is.” When you are inclined to change code without defects, this could indicate a new understanding that needs expressing. Changing existing code to reflect a new understanding is all we have. This is how we pay off debt in our design.

Continue reading …