Frank Carver’s musings about software and life
Pair programming can be one of the hardest things to get right when attempting Extreme Programming (XP). It’s very common to give it a try and quickly find a whole bunch of problems. Mark Needham has written a thoughtful article full of tips on making pairing work. Well wortha read even if you don’t do it (much) yourself.
We had a small discussion at work a few days ago about the difference between Scrum and Extreme Programming (XP).
My take on the distinction is that Scrum is essentially a management technique, while XP is essentially a development technique. They certainly have a lot of overlap, but the different emphasis leads to some different recommendations. There’s no “40 hour week” in Scrum, for example.
Jason Yip contends that Scrum stops where actual development work starts.
For interest, a while ago I reviewed both the original book on Scrum and a clutch of XP books for the Java Ranch “bunkhouse”.
pair programming is often one of the hardest things to “sell” when implementing XP or an XP style approach to development. Mark Needham has written a nice summary of some reasons for choosing pair programming.
At the moment, the company I work for is pressing forward on implementing an end-to-end agile approach to software production. With this in mind, I was intrigued to see an interview with someone who runs a company offering consulting and training in just this area, which they refer to as “industrial XP”. I found plenty of thought-provoking ideas in there.
A continual source of discussion is the XP/agile admonition to do “the simplest thing that could possibly work”. What is simple? How do you know it could work until it is done? What if part-way through you spot a “simpler” solution? “simpler” for who? And what does “simple” mean, anyway!!
Here’s an article which looks at this old chestnut from the point of emphasis - is it the “simplest” or the “possibly” which should carry the most weight?
Jay Fields’ Thoughts: The Simplest Thing That Could Possibly Work
Another commentary on the same article from Ian Robinson can be found at The Simplest Thing That Could Possibly Work :: iansrobinson.com
Constructing sensible and effective user stories is a vital and sometimes surprisingly tricky part of XP-style agile software development. There are plenty of ways to choose a less than optimal story breakdown.
Lasse Koskela has put together a thoughtful blog post about this topic.
The Extreme Programming practice of “40 hour week” (a.k.a “sustainable pace”) is always one to provoke argument. Here’s a summary of some discussion at infoq:
the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”
That’s just a provocative snippet, of course. The article ranges much wider than that, and contains a lot of interesting stuff from one of the giants of software engineering.
Read the whole article at InformIT: Interview with Donald Knuth