Kent Beck gave a great 'story-driven' talk at RailsConf 2008 regarding Patterns, Test Driven Development, and XP/Agile/Responsible development. Go see it now at Blip.tv along with all the other big presentations from RailsConf.

Yeah, yeah. This was posted ages ago, but I just made it around to watching it tonight.

Two great quotes. First, re: TDD

Testing really isn't the point. The point here is about responsibility. When you say it's done, is it done. Can you go to sleep at night, do you know that the software you finished today . . . works. And will help. And isn't going to take anything away from people.

Second, more generally about ideas:

Smart ideas are useless. Nobody else is going to be dumb enough not to try them - or rather, Everybody's going to try them if it's a smart idea. Ideas with punch are the ones that are really ridiculous...until you try them.

Like Mole. Mole sauce. Chocolate? Chicken? Phbbblblltt! HahahaHA!

I posted a few weeks ago gathering small tips from you regarding how you get and/or stay more Agile.

The goal is a list of short, pithy, sticky aphorisms to help both newbies get Agile and us stay that way. Think Agile Andy's Almanack (or something).

I've thrown everything I got (a lot in person & email) together and categorized a bit. Please comment, add, delete, etc. As I said, I'm working on a presentation around this data and welcome your feedback.

Here goes:

Stick to Conventions

• Follow the local ground rules (indenting, naming, structure, etc.)
• Always take the next story (don't let 'fun' or 'hard' get in the way of business priority)

Use the right tools

• Keep your hand on the manual (Keep browser tabs open for your language & API doc sites)
• Make mini actionable task lists for your story (Get inspired by GTD)
• Index cards are mini whiteboards
• Hardware, hardware, hardware (Big and/or dual monitors, 2 keyboards & 2 mice is better than 1 & 1)

Pair Programming Works

• Expect to Pair
• Pair appropriately
  • When you're not sure how to implement a story, pair with someone more senior
  • When a task feels obvious, pair with someone more junior or new to the project
• Let the rookie type, give the wookie a toy (so he doesn't)
• Rotate your pairs as often as practical
• 2 pairs are better than 1 on a project
• Always pair interview

Take a test drive

• Writers' block? BEWS (Blank Editor Window Syndrome)? Write a test
• Find some untested code? Write a test.
• Find something you don't understand? Write a test.
• Keep your tests as fast as is practical, or you'll wait for CI to run them
• Write enough tests so that you can sleep at night

Code simply

• Do the simplest thing that could possibly work - no architecture astronauts
• Check-in multiple times before a story is done (try for every hour or so)
• Kill dead code, commented out code, or write tests to cover it
• Make it green, then make it clean
• Tackle code debt with extreme prejudice
• Leave the code cleaner than when you got there (think o2 canisters on Everest)

CI

• Every failing test is sacred
• Red builds are project cancer - fix first, figure out why, then blame (when appropriate)

Stay in sync

• Don't stop talking - to your pair, your team or your customer
• Go to lunch together

Comment away...

I've been passionate about Extreme Programming and Agile Software Development Practices since first hearing Kent Beck speak back in 2002. But it took five years, and finding a job where I was expected by management to be Agile every day (TDD, paring, etc.), before I was able to actually call myself an Agile Engineer.

I'm sure that there are more of you out there who want to be more Agile. And you want more Agile engineers so that you'll have reasonable people to work with and learn from.

In the past 18 months I've picked up a lot of effective small practices that you won't find in the White Book. Things like making sure you pick the next story no matter your comfort level. Or fixing a red CI build ASAP.

In order to spread the knowledge, I'm working on a presentation about the 'practices that work' to share with potential Agile Engineers at a future software conference near you.

So what day-to-day practices make you more Agile?

Interesting Things

• There was an edge version of Rails (this project has a frozen Rails at some point in the past) that had a bug where a namespaced route would send a POST that should go to MyController#create was instead going to a POST to MyController#index. The fix is to freeze to current Edge, or use alias_method.

Ask for Help

"Any way to turn off a validation in a re-opened class?"

No way to do this. Best to refactor by pulling the validation out of the class and then mixing it in, or not, at a different level.

Interesting Things

• Y!Slow + Firebug + submit a form will cause the result to be pulled from cache instead of hitting your server. The workaround is to disable Y!Slow.
• Some of our customers are requesting targeting Firefox 3, which has some rendering differences from FF2. So we're adding FF3 to the system image with a new icon and the correct trick to let it run side-by-side with FF2.
  • How to Run FF2 & FF3 side-by-side on Mac OS X
  • FF3 customer icon that is sufficiently different than Firefox's normal icon so you can tell the difference
• On a related note, rumor is that Facebook is dropping support for IE6. So is 37Signals.
• Interesting issues with the Globalize plugin & Rails 2.1:
  • The currency formatting code does not work at all anymore - it always uses a '$'
  • Their work for localizing templates, which involves injecting a fully-qualified path, breaks #assert_template. The workaround is to comment out the path injection code, but this only works if you don't have localized templates.
• EngineYard's eycap gem version 0.3.6 now has better support for deploying from SVN tags
  • Deploying from tag, since the URL was different used to do a rm -rf, which takes a long time on EY's GFS disks for large file sizes. This was causing a customer's deploy taking ~20 minutes
  • The fix was to change eycap to use svn switch; the deploy now takes ~1 minute

Ask for Help

"Anyone seen/solved an issue with random font size increase using Firebug 1.1 or later?"

The issue is that at some point a page will render with much larger fonts and the CSS exploration won't tell you why. The work around is to launch a browser with Firebug disabled and run it side by side with the same page in a window with Firebug enabled (restarting the 2nd window whenever the problem occurs.)

Seeing this with Firefox 2 and 3 and any Firebug later than 1.05 (which doesn't run on FF3). This might be an issue with IFRAMEs, but we're not sure. No data found on this via Google searches or the Firebug group. We will post there.

Interesting Things

• New Relic is presenting at our Tech Talk this week. Expect good information about using their real-time performance monitoring tool on your Rails projects.
• Pivotal Tracker, our home-grown Agile project management site, should get even more beta tonight. Users should be able to create their own projects! Check it out.

Interesting Things

• Model#update_all is your friend if you're not yet on Rails 2.1

  Like Model#update_attribute for each attribute, #update_all will save direct to the database, bypassing validation, updating only the columns you specify. In Rails 2.1, with partial model updates, you may not need this. But if you've not yet upgraded your application, then give #update_all a try.

Update: fixed per comment. Model#update_attribute does not validate. Thanks for the catch!