Mike is currently… getting whipped at Halo |
||||||||||||||||||||||||||||||||||||||||||||
[ subversion book ] obligatory book plug [ syndicate ] rss 2.0 feed for boy meets world [ contact ] drop me a line [ about ] this is mike mason's weblog [ eskimoman.net ] original web pages |
Thu, 25 Mar 2004This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts. Extreme Programming Re-RefactoredThere’s a lot of hype surrounding XP and Agile, and a lot of people trying it out based on that hype, and now there’s a bit of a backlash going on. Extreme Programming Refactored makes the case against XP, and as a proponent of agile methods I’d like to make a response. A sample chapter is available on the website, and there’s more info in a review on Slashdot. The sample chapter deals with pair programming, and not having read the rest of the book (judging by the sample chapter it’s not something I want to spend money on) I’m confining my comments to this aspect of XP. Every example the authors give, claiming to show why XP fails, is actually more an example of XP done wrong. They talk about a team where the coach doesn’t pair — that’s not XP. Alan Francis has a very good description of an XP coach — that’s XP. They talk about programmers hunched over machines having difficulty with ergonomics — that’s not XP. Cheap desks with expensive chairs. Powerful machines for pairing in the middle of the room, cubby holes for private tasks around the outside. That’s XP. The authors site an example where task cards would be signed off as completed by a single programmer, even though two worked on the card, and so the goal was to maximise the number of cards with your name on. Surely that’s an obviously bogus method of tracking? Not spotted by the XP Refactored authors, apparently. The only section in the chapter that’s not based on examples of “XP done wrong” is its assertion that solo programming heroics are better than having a pair complete a solution together. Ron Jeffries is quoted as saying: I think maybe concentration is the enemy. Seriously. If you’re working on something that is so complex you actually need to concentrate, there’s too much chance that it’s too hard. The XP Refactored response totally misses his point: Jeffries’ comment reveals a lot about the Extremo mind-set: A roomful of noisy people working on bite-sized chunks of code is preferable to an environment that is more conducive to hard thinking and elegant designs that take all the project’s requirements into account. In XP, it appears that everyone on the team must conform to this form of organisation. There is no flexibility. The authors are simply asserting that programming requires hard thinking, and that hard thinking creates elegant designs that provide a solution to “all the project’s requirements”. First off, the real world tells me that it’s impossible to know all of a project’s requirements, and so designing something elegant because you think you know where you’re going to end up is a waste of time — in fact you’re hampering yourself with features you think you need but probably won’t. Second, what programming problem is so difficult that working on it with a colleague won’t help you? Seriously. In a year at ThoughtWorks, there’s been nothing that hard. If a problem looked that hard, we were usually going about things the wrong way and needed to take a step back. What problem is so complicated that you can’t explain it to a colleague and figure out a solution together? I can’t think of one. A lot of this comes down to the XP Refactored authors’ deep-seated belief that all programmers are socially inept nerds who want to escape the real world by hiding in their computers. Well, I’m not that kind of programmer. Neither are the rest of my colleagues. When I do meet someone who’s a little shy, I do my best to buddy with them and get them talking a little more. Human beings are social animals, it’s not hard to be nice to someone and do the right things. XP Refactored seems to be based on anecdotes from people doing all the wrong things. XP and Agile work for me. Your mileage may vary. Posted 05:04, 25 Mar 2004. [ permalink ] Thu, 11 Mar 2004This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts. SCM Best PracticesThe people behind Perforce, pretty much my favourite version control system, have come up with a set of Software Configuation Management Best Practices. It’s an interesting paper, written by two Perforce employees with considerable experience helping their clients implement and support SCM. The advice is simple, but often overlooked. Here’s a rundown of the points they make: Don’t share workspaces, stay in sync with the codeline, check in often. Give each codeline a policy and an owner, and have a mainline (trunk). Branch only when you have to, don’t copy when you should branch, and branch late. Get the right person to do merges. Use common build tools, build often, and keep build logs and output (use CruiseControl). Give everything an owner, and use living documents. Interestingly the latter half of what they describe, which might be referred to as “build engineering”, is already advocated by XP. Proper SCM can make a tremendous difference to a project, and it’s worth thinking about upfront before things like deadlines rear up and scupper your efforts. Posted 13:24, 11 Mar 2004. [ permalink ] Mon, 08 Mar 2004This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts. What’s All The Fuss About?I’ve written a short Subversion advocacy article, aimed at CVS users. The nice people at OSDir.com were kind enough to publish it. Subversion for CVS Users provides an introduction to new features in Subversion, and why they might be important to you. Update: It seems my article got mentioned on Slashdot, which is pretty cool. Not sure how I feel about being described as a “versioning admin” however… Posted 13:49, 08 Mar 2004. [ permalink ] |
[ tim bacon ] musings of an xp coach [ ian bourke ] enhancing core competencies since 1976 [ martin fowler ] a cross between a blog and a wiki [ alan francis ] agile != good [ paul hammant ] part of the problem… [ darren hobbs ] the blog formerly known as pushing the envelope [ mike roberts ] on life and technology [ chris stevenson ] skizz-biz [ joe walnes ] joe's new jelly [ rob baillie ] oracle |
||||||||||||||||||||||||||||||||||||||||||
Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1) |