Wed, 26 Oct 2005 00:00:00 UT

read/write
Gaal has a great blog post today: There must be a moral to this story of continual re-discovery; perhaps someone along the line should have learned to read. Or someone else learn to write. -- Roger Hindley
I sent in my first patch for JHC early this morning before sleeping. I've been reading Urban Boquist's GRIN thesis, it's cool.
Excellent post from Ron Jeffries today on the Pragmatic Programmer's list:
This sounds very familiar... My experience too is that if my customer feels he's getting value for money, he'll be happy. Furthermore I think if I were to ask him if one of his requirements is due to a bug or a feature, he'd be less happy. As Randall said, he could feel I'm somehow putting the blame on him; and it really doesn't matter who is right or wrong.

I'd like to suggest that it does matter whether it's a defect or a feature, though I prefer not to go to "right or wrong".

The reason that it matters is that there is learning to be had with either kind of change, but the people who will benefit from the learning are different.

In the case of a defect, the developers have an opportunity to learn how they misinterpreted the need (which I think is less often the problem) or how they managed to build something other than what they intended. In short: how did we get this bug in there, what can we do to make it less likely in the future?

In the case of a change, there isn't much for the developers to learn. But the customer has an opportunity to learn, and should do, because there is additional cost to changing to the new idea. That cost, ideally, would be avoided, or justified:
Is the change due to the customer not fully understanding the original need?

Would more talking with end users have helped?

Was the customer aware s/he was guessing a bit about the feature?

Has the need actually changed? Was that foreseeable?

Were there things the customer knew that, on reflection, should have suggested deferring implementation, possibly saving the extra cost.

Or ... was doing the feature "as an experiment" actually a good thing to do, so as to learn more about the real need.

There will be benefit from reflecting on those things. Perhaps more forethought would have been of value. Perhaps just waiting would have been best. Perhaps the experiment was of value, and a more skeletal approach might have saved more time and money.

Thus I conclude that there is value for the team to know the difference between a defect and a change, because the locus of learning differs.

Ron Jeffries www.XProgramming.com

« previous see more nibbly bits! next »