In the previous post I started talking about The Joel Test: 12 Steps to Better Code, which gives you a quick measure of software development organizations.  The Big Swinging Developer Test is similar, but instead of sizing up organizations, it’s used to get a quick read on a developer.  Now, on to step 2.

The Joel Test:
2. Can you make a build in one step?

The Big Swinging Developer Test:
2. Can you create a one step build from scratch?

At first glance, this seems to be one of the easiest development tasks ever.  Build in one step?  Sure, just click the green triangle in Visual Studio (or the equivalent step in Eclipse, Sun Studio, etc.)  That’s not one step since you’d have to open the project in one of those tools to begin with.  In addition, what about getting the latest code from version control?  Not to mention the likelihood that the program you’re working on will be spread across multiple projects.

Like all things Big Swinging Developer, creating a one step build is less about technology and more about process.  This one in particular requires a large dose of empathy because "it builds on my box" just doesn’t cut it when you’re working in a team, especially if you’re getting a monster bill rate to do so.  There are three audiences for a one step build and if you can meet the needs of all three then your life will be easier on just about any project you join.

Audience 1: The New Guy
Have you ever joined a project and spent the first couple of days just trying to get your development system set up?  One of the most frustrating parts of the on-boarding process for any developer is getting to the point where you can start debugging, writing, and testing code.  A successful one step build for The New Guy is a single command from a logical place (like the root folder of version control) that requires either zero parameters, or gives him the list of parameters when none are passed in.  There should be no need to train him to build other than, "Run this command from this directory.  Catch you later."

Audience 2: The Team
The second audience is the rest of your team, or the teams that you work with in the case of a large project.  Since team members have different needs, this is where options, parameters, and structure come into play.  Maybe team members don’t want to build the whole system, so you break the build into sub-builds that can be run independently which are then all aggregated into the top-level master build.  Maybe the team wants to run some tests, but not others.  I was on a project once where there were more than 250 .NET assemblies built as part of the system.  Compile time was about 7 minutes.  Test time was nearly 3 hours.  Even though I was paid hourly, I didn’t need to run all the tests all the time.

Audience 3: The Build/Release Team
The final audience may or may not exist on your project.  Sometimes you have dedicated release managers and sometimes you just have someone appointed to produce release builds.  Either way, this audience has their own special needs.  In particular, the ability to do things like build in Release/Optimized mode, the ability to synchronize version numbers across files, the ability to deploy to new directories, and more.  A one step build that compiles, tests, packages, deploys to a timestamped directory, and emails everyone who cares is a thing of beauty.

NOTE: The less code you write, the more valuable it is.
You may be thinking, "No, problem.  Some Perl here, some DOS batch files there, throw in that hand rolled FTP client I wrote awhile back and I can build everything listed."  Not so fast.  A good build system is built on technologies that folks can understand, use quickly, and Google for help.  Think Ant, NAnt, MSBuild, CruiseControl, WiX, even Make.  Remember: Build something that people can use and improve even when you’re not around and you’re on your way to becoming a Big Swinging Developer.