Tacking toward agility

By Larry O'Brien

May 1, 2008 —

If you put a newcomer into a sailboat, give them the tiller and the mainsheet, and tell them to sail upwind, the most likely outcome is that they’ll sail backward. Sailors never tire of talking about making boats go faster and the million different variables that contribute to boat speed. However, you don’t need to know anything about rigging tension and sail shape in order to get moving. You just need to know some basic constraints and rules about positioning the boat and the sail relative to the wind. You might not win races, but you’ll be sailing.

Similarly, for all of the columns we write about fine-tuning approaches to design and architecture, tool choice and process improvement, there are really only a few crucial things that you must take care of in order to start moving forward in software development. Sure, there are teams that seem to do everything right: daily stand-up meetings held as they do 40 minutes of cardiovascular exercise, pair programming while sitting with perfect posture, flossing after every code check-in, and so forth. Most of us, though, struggle with less-than-perfect teams, hoping that the things we are skimping on aren’t the critical ones. These things define our culture and determine the type of programmers who are likely to end up working with us over the long term.

Professional development begins with source control. It’s astonishing to me, but I not infrequently encounter teams that use FTP and e-mail to move development files around. This is simply unacceptable and will immediately “flip the bozo bit” in any kind of skeptic.

In the past few years, the OSS Subversion software has become very common, but I’ve recently become skeptical that it’s a good match for newcomers to version control. While I’ve never lost any data in Subversion, it seems to get into faulty states (“wedged”) fairly often, especially when manipulating large numbers of files, which is done often when introducing a team to source control. While it’s generally easy for an experienced user to fix a Subversion error state, to a newcomer it can be off-putting. There are many choices, but I would suggest SourceGear Vault, Perforce and Visual Studio Team System as alternatives.

VSTS also has integrated task tracking, and I’ve come to see software-based task tracking as another vital tool, at least for teams that are not wholly “extreme” (the full Extreme Programming regimen is communal to a point where software would simply get in the way). In a team with good tools, there is no such thing as a routine feature—“boilerplate” code is factored into frameworks, libraries and components.

Programmers should be spending their time on challenging features. Challenging features invariably have subtleties—areas where the programmer can be flexible and areas that demand they toe the line. This conclusion that fine-grained task management is almost universally required is one that I’ve come to over the years only with great hesitance, because individual programmers can so often succeed in developing small utilities with a fraction of the guidance. Unfortunately, one of the most common mistakes I’ve seen in process improvement is “letting up” on fine-grained task management too soon.

Task tracking cannot be done with Excel, that favorite of casual managers. Not only must dependencies between tasks be tracked, but also most importantly, tasks must progress through a defined life cycle, even if one as simple as “open/in-progress/resolved/closed” (“open” and “closed” being states defined by managers and “in-progress” and “resolved” being states defined by the developer). I like VSTS’ task tracking, which integrates with Outlook, but also commonly choose Atlassian’s JIRA.

Realizing that I have space for only one more topic, I am gravely tempted to write about modularization, which I find to be an almost perfect gauge of productivity. But modularity can be difficult for managers to judge, so instead I think I’ll speak of the relatively modern practice of continuous integration.

Continuous Integration, or CI, can be summarized as “daily contributions that never break the build”—a system that avoids the common “two-steps forward, one-step back” chaos of teams that work on their features in isolation, only to find that integrating them is as much (or more) work as building them. I somewhat surprised myself by choosing CI over unit testing, but CI invariably leads to unit testing, since manually validating the build gets old very quickly.

There are many CI servers, both commercial and open source. I tend to use CruiseControl and its derivations (CruiseControl.NET, CruiseControl.rb), but that’s more from familiarity than any objective evaluation of the alternatives.

Version control tells you who contributed what and when, task management should tell you the “why” of contributions, and CI confirms that you’re not moving backwards. You might not win races, but you’ll be developing.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.

Related Search Term(s): Agile

Share this link: http://www.sdtimes.com/link/32021

Guest View: The half-agile path leads nowhere While businesses are taking on agile and adopting its practices, an incomplete implementation does more harm than good

From the Editors: Agile isn't an all-or-nothing choice The editors say that shops should go their own way re: agile, and that mobile development gains from two main competitors

How agile are you? The more agile is adopted, the more debate there is on what it means to be truly agile, and whether pure beats pragmatic

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST