XP Installed- Chapter 16-18

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson


Summary
Today's XP reading covers "Do's and Don't's", "Experience Improves Estimates", and "Resources, Scope, Quality, Time". 


"Do's and Don't's" is a bulleted list of "do this", "don't do this", with some minor justification for each item. It's kind of a summarization of the important points of the previous chapters- do things that have immediate effect, don't do things that are useless. 


"Experience Improves Estimates" retreads a previous chapter in that it basically says "the more you estimate things, the broader an experience set you have by which to compare and estimate new tasks". It's nothing new. However, I was glad to see that they brought up "not all tasks can be compared- a database fix and a javascript issue may both come out to 4 hours, but that doesn't mean that by doing the JS issue you can estimate a different DB change, which I was going to pounce on and tear them apart for on reading the first paragraph of the chapter.


"Resources, Scope, Quality, Time" is a chapter that basically talks about "How do I present what I'm doing to the employer", making it one of the worst named chapters yet. The chapter gives a large number of example graphs and when you'd use them (use this towards the end of a project, this can be informative mid way), and ends with the advice "don't get too deep into metrics- while interesting, they don't contribute to the bottom line."


Discussion

1. Why is this paper interesting or significant?

16+17+18-(19-10) = 42, a significant result. It also has that last bit of advice on "Don't get too deep into metrics... we know you're a computer sciencey guy that likes numbers, but, really, you'll get lost". That seems interesting and useful.

2. What are the faults of this work?

I disagree with their statements on "Don't build for tomorrow". While they do have a point, there's a point where you cross from reasonable future-fore-thought to YAGNI violation- before that point you're decreasing future work, and after that point you're spinning you're spinning your wheels in the mud. But, the statements "It's almost always easier to add in later" is just... painfully, wrong. There are a few times where in it doesn't matter, but in general I've found that 'nice simple design' doesn't meld well with 'simple design for complex app'. Logic ends up in the wrong place, or in the wrong conceptual map, such that work is increased. Not to mention, failure to look forward also introduces compatibility issues. In my line of work, we're continuously releasing control software, but we don't make breaking changes to certain things for fear of losing reverse compatibility, meaning at design time we needed to ask "What do we expect to see". 

3. What is the possible future work extending from this work?

I shall makes charts about how well received our progress charts are received by the customer.