YARB

I wrote this a while back and had it archived on a Backpack page.

Since I’ve never done anything with it, thought I might as well post it here.

The ideas are very similar to Getting Real by 37 Signals, though I don’t nearly flush them out as well.

Note: I wrote this after being frustrated at a few companies; I’ve since worked for some pretty cool teams that have actually adopted many of these ideas, under different names / etc (agile, XP, Getting Real, etc).

How Webapp Developers Can Get More Done: GTD++

GTD++ is a collection of applied technologies and frameworks for agile, sustainable application development.

Systems

• Version Control
• Bug, Task & Feature Request Tracking
• One-step Builds
• Unit Testing
• Wiki / Knowledge Management
• Automatic Documentation Extraction
• Continuous Integration
• Automated Application Testing (Web, GUI, etc)

Laws of GTD++

• Any ongoing process which relies upon the physical proximity of team members is inherently broken.

• Any system that routinely relies upon verbal or message-based (non-captured) knowledge transfer for critical development work is inherently flawed.

• Any process that can be automated in a functionally equivalent manner—should be automated.

• Stakeholders should always be made aware of the implications of their requests (functionality-wise, schedule-wise, etc)

• Stakeholder Corollary: Stakeholders will not always know what they truly want without developer feedback.

Development / Production Stages

• Experimentation
• Incubation
• Rapid-growth (agile development)
• Quality-assurance
• Maturation
• Sustainable++

Absolute Bare Minimum a Developer Needs to Get Started

• A version control login and URL
• How to Checkout the Source
• How to Setup the Development Environment
• How to Setup the Build Environment

Absolute Bare Minimum Deployment Documentation

• How to Setup the Deployment Environment
• How to Deploy the Application

GTD++ Tools

Cross-platform

• Subversion
• Trac

Java

• Ant
• JUnit
• Javadoc

.NET

• NAnt
• NUnit
• NDoc

Ruby

• Rake
• Test::Unit
• RDoc
• WATIR

Python

• SCons
• PyUnit
• pydoc

Git has been getting a lot of coverage these days.

The technology behind git sounds nothing less than spectacular. But how does git improve day-to-day productivity in this kind of environment?

Time it takes to perform/think about “version control” (in this case, Subversion) in parenthesis.

• Do some hacking for maybe 2 hours. Make a checkin. (15 seconds)
• Svn update on server. (15 seconds)
• Oops, wasn’t 100% right or need to make a quick fix. Check that in. (10 seconds)
• Update production. (10 seconds)

...

Git sounds wonderful if you need to do a lot of intricate braching.

For my development style, that just isn’t the case. I’m also not ashamed to admit that I find Capistrano highly overrated when it comes to managing deployments.

Don’t get me wrong—it’s an excellent tool if you want to add that much overhead to your deployment process, ability to rollback, etc, etc.

Here’s where it failed me:

• in one intricate app, while deploying, there were always several ancillary processes going on in the background. Capistrano would always hang for 5-10 minutes while trying to stop these.
• checkout of the core code takes 5+ minutes (slow remote svn repo or biiig rails apps)—who wants to sit around for 5 minutes when an incremental ‘svn up’ takes 15 seconds?

So—yes, that’s how I “deploy” my Rails applications, and have never had a problem yet. Here is the simple 30 second workflow:

cd /u/apps/foo/current
svn up .
mongrel_rails cluster::stop
# manually make sure all mongrels have stopped, and possibly: rm -rf log/*
mongrel_rails cluster::start

And PZZaaaaaaaam—I’m deployed.

So adding things like git and capistrano would simply slow me down. If you’re deployment cycle takes 1-2 days (for full UI testing, etc—ugh) then by all means, use capistrano, git, whatever. But for the “ultra agile” style, these fancy techniques are overkill, IMHO.