Monday, October 25

Delegate Now

I'm working on a large code base, and I'm really starting to dislike inheritance as a way to combat code duplication.

Every time I see an "extends" keyword, I think, gee, this would be much nicer if it was using delegation. It would be more explicit. It would be easier to test. It would be easier to re-use the delegated code elsewhere.

But why dont we all use delegation all the time if it is so much nicer?

One theory is that creating new classes is too costly. While this might not be true, I suspect that we could easily feel this way: "What do I call the new class?" "Where do I put it?" "Do I have to test it?". All these questions probably add up to make it less attractive than "Extract Superclass".

But don't be fooled. Delegate Now, not later. Call the class "FooService" if you cant think of a name immediatley. Put it in the current package. Move or implement the test methods later.

Furthur reading:

Friday, October 22

The pen is mightier than the spreadsheet

Brian has just blogged about a burn down chart, he says:
"My chart differs from Kelly's in that I removed some extrapolated lines he uses. I like to get away with as few predictions as possible. To emphasize that, I hand-drew the one prediction. That makes the line seem less authoritative and believable than one Excel draws, which is appropriate."
When your sponsors are making financial decisions based on your reports, you want to make it clear that the predicted end-date is just a guess, not a calculation.
This concept has some similarity to the idea of fuzzy vs hard analysis and lo-fi prototyping, and is probably even more important for project reporting than requirements gathering.
Incidently, this is why I dont like function points and other calculated estimates, I prefer a hand written number on an index card: it is clear this is just a gut feel. It makes it much harder to leap to the wrong conclusion (that reality will somehow match up to the plan).