JavaWorld has an interesting forum discussion entitled “Heinz Kabutz on Bad Code, Unit Testing, and More” in which the following thoughts are posed as a series of questions:

Kabutz also gives Java developers a hard time for not unit testing. He argues that it’s a major problem and that few Java developers do it. I’m curious: Has anyone gotten into big trouble for not unit testing? Is it a major source of bugs in your experience?

The discussion then centers around the merits of unit testing and code coverage (much like the excellent discussions from Stelligent’s TDD Horror stories evening!)– for instance, one reader states:

Striving for 100% unit test coverage is nice for libraries, but overkill for the avarage bussiness application that is written by most development teams.

What are your thoughts? Is TDD worth the effort or not?

There are myriad code metrics available to measure attributes of code, such as complexity, coupling, and length, but few are arguably useful. In fact, as I’ve stated before, Cyclomatic complexity is the most applicable metric out there for accurately determining risk.

Recently, a few smart individuals married Cyclomatic complexity with code coverage yielding an impressively helpful metric. They’ve dubbed the metric C.R.A.P and while you may shudder at its name, its accuracy will bring goose-bumps.

If you want to learn more, have a listen to JavaWorld’s podcast entitled “Alberto Savoia talks shop about C.R.A.P.“– plus, the guy asking Mr. Savoia all the questions (and chortling a lot) is me!

If you haven’t already registered for our un-boo-lievable TDD horror stories event, you better RSVP today before it’s too late!

From fangtastic wine, cheese, and other positively defrightful treats; to conversation around TDD haunts, this ghoulish gathering is sure to be a scream! We’ll also be giving away a terror-ific iPod shuffle.

When: Tuesday, October 30th from 5:30 PM to 7 PM
Where: Stelligent’s haunted headquarters (map)
Who: Ghosts, goblins, witches, and anyone who is screaming to use TDD

I had the pleasure of attending the Agile Project Leadership Network (APLN) Fall Leadership Summit in Richmond, VA yesterday. This was a great event and I would encourage anyone to attend future APLN sponsored events. I collected some quotes I overheard yesterday and have provided some explanation as to why I found them interesting. Some of the longer quotes are paraphrases; please forgive any inaccuracies.

10. “It seems like all of this Agile stuff is just common business sense.”
This late question during the Lunch Panel was from one of the few attendees who has not yet experienced effective Agile practices. Of course, Agile is based in the common-sense business practices of increased communication, eliminating bureaucratic barriers, empowering the individual and collaborative management. These may be common sense, but I am not sure how common they are in practice.

9. “You should take your customer outside and shoot them.”
This laughable comment was suggested during a Think Tank session. The customer in question was demanding an Agile approach and refusing to prioritize a thousand-item requirements document. The speaker of this advice was joking, I think.

8. “Agile will not create competence.”
Steve Greene, Director of Tools and Processes at salesforce.com, emphasized the strength of his team as an indicator of Agile success and the panel agreed that the transparency inherent in an Agile approach will highlight those who are struggling to perform effectively.

7. “The embedded social engineering practices of Scrum give it a significant advantage.”
In a personal discussion with Robin Dymond, a managing partner at Lean and Agile consultancy innovel, LLC, he highlighted the important concept that Planning Poker, Daily Scrums and Continuous Integration are all examples of social engineering constructs designed to improve communication (and eliminate a huge barrier to positive project velocity.)

6. “I’m not sure if we are reaching your Zen state of Agile with this answer.”
Responding to a question regarding the “next higher state” of Agile teams, this Panel answer from Roy Maines of Wachovia received a few laughs.

5. “Our biggest challenge is translating the value of Agile into a pricing structure that resonates with our customers.”
I heard this comment stated several different ways by development companies/teams with external customers. The challenge being that the customers want to know “what is this thing (the final version) going to cost and how long will it take to build?” The answer was ultimately some version of “let us deliver something valuable in our first sprint and build on it from there.” Several people indicated frustration that this answer was not good enough for their customers.

4. “Now that our projects are Agile, we are discovering our infrastructure is struggling to keep up.”
Of course, this one was near and dear to my heart, as Stelligent specializes in helping companies overcome this challenge. Several leaders noted that their waterfall-influenced development infrastructure and software developers unfamiliarity with accelerated delivery principles was a barrier to fully realizing the advantages of their Agile transformation.

3. The entire presentation from Israel Gat.
Unfortunately, I cannot provide a simple “nugget” from Israel’s presentation that moved from the bitch-goddess Success through empirical analysis of the actual impact of Agile within BMC Software. The real-world, large-scale analysis of Agile’s overwhelming success within BMC was fascinating.

2. “Despite all advice from consultants, we went all-Agile, all-at-once.”
Another quote from Salesforce’s Steve Greene in a very interesting talk about how inter-related project dependencies prevented them from the tried-and-true approach of starting Agile with a small pilot and allowing it to build through an organization over time. Salesforce turned Agile all on, all at once, and has never looked back…an impressive story of corporate culture, resolve and confidence.

1. “At a minimum, I want to be able to react to market conditions. My desire is to shape market conditions. My goal for IT is to not get in the way.”
The keynote speaker, Niel Nickolaisen, CIO and Director of Strategic Planning, Headwaters, Inc. led off with this important business perspective on why companies have interest in being Agile. The ability to link Agile practices will business goals is a key skill for anyone looking to transform an organization. I felt this comment best reflected the sentiment of the panelist, speakers and attendees that Agile is not the end, it is the means; business value is the true goal.

So, what do you think? Did you attend the summit? What did I miss? Regardless, what do you think of some of these ideas and thoughts? Are you experiencing similar challenges and successes?

I often run into teams who attempted to jump skull first into TDD and eventually threw their bones up in frustration when either schedules became scary or they ran into scenarios too frightening to test. Are there areas where test-driven development gives you the spooks?

We’re terribly excited to announce that on Tuesday, October 30th, we will be hosting a roundtable discussion on TDD at our lair in Reston, Virginia. Get into the spirit of Halloween by treating us with your horror stories on the trickiest problems when implementing TDD. We’ll be talking about what spells work and what spirits don’t, while mingling over a cauldron of fine wine (courtesy of Savoy-Lee), cheese, and other potions. We’ll also be raffling off a screamingly appropriate iPod shuffle.

When: Tuesday, October 30th from 5:30 PM to 7 PM

Where: Stelligent’s haunted headquarters (map)

Who: Ghosts, goblins, witches, and anyone who is screaming to use TDD or creepy enough to think about TDD

You need to RSVP, so please respond sooooon because tombstones are limited.

Do you live for Test Driven Development? Do you dream about implementing Continuous Integration? Do you like helping other people adopt these principles?

If you answered yes to these questions, you should consider working for Stelligent! We’re growing and are looking to build our team with superstars having solid software development experience (Java, .NET, C++, etc) and who live and breathe Agile techniques (like TDD and CI).

See our Employment page for more information and apply today!

Recently, Steve McConnell was interviewed by PM Boulevard about Agile development.

I appreciate his non-dogmatic, sensible approach to software development practices. Here’s an excerpt of McConnell’s take on Agile:

I’ve always been pro-whatever-practices-work-best. In many situations the practices that work best are the practices that today are associated with agile development. And in some circumstances, other older practices still work best.

So I’m not pro-agile or anti-agile. I’m not pro-CMM or anti-CMM, pro-BDUF or anti-BDUF, or pro-pair programming or anti-pair programming. For that matter I’m not even pro-waterfall or anti-waterfall.

Hear, hear! My post Am I Agile or Not? speaks to a similar philosophy about software development practices as well.

BDD, or Behavior Driven Development, was essentially created from the idea that most developers were not realizing the full potential from TDD, or Test Driven Development. A large problem with TDD is that it tends to put people into a verification-centric mindset; whereas the concept of BDD is on writing specifications, rather than tests, to assert that an application does what it is supposed to do.

In this month’s “In pursuit of code quality” article, entitled “Adventures in behavior-driven development”, Andrew Glover shows you how to get started with BDD, via JBehave (Java based framework). He also demonstrates how you don’t have to think about tests with BDD; you can just pay attention to the requirements of your application and ensure that the application behavior does what it should to meet those requirements.

As always, don’t miss out on the code quality discussion forum where you can learn first-hand about code metrics, test frameworks, and writing quality-focused code.

I think one of the reasons that I have had great success with CI Factory when introducing teams to CI is polish, or ease of use.  Some of that polish comes with CI Factory out of the box, this post is about that extra that I have found myself adding of late.

I like to provide a script that will get developers all setup from the get go.  Recently I have found the best place to locate this script to be on the CCNet dashboard.

The workspace setup script should check for the needed source control client, create the directory structure needed, and get the latest from the source control repository.  Lastly it opens a Windows Explorer window to the Product directory:

From here the developer can run a build by double clicking the Build.bat.  I have gotten to including a check for required software at the beginning of the personal build.  For example if Visual Studio 2005 SP1 is required I check for it and prompt the developer about it if missing.  Where possible I have the script install missing software with the developers permission.

Once all the required software checks pass the rest of the build runs as normal.  The last bit to be polished is the cctray install.  In CI Factory the cctray download is a zip not a setup.exe.  I like to turn this into a self extracting zip and include a pre-configured settings.xml file.  This way when cctray starts up for the first time it is already configured.

In my experience these things leave developers the head room to focus on things that deserve their attention.  Communicating this through actions like polish go a long way to demonstrating how CI can have an affect on the quality of their lives.

To add download links to the main web dashboard edit the file:

C:\Projects\<project name>\Current\Build\dashboard\templatesFarmSideBar.vm

<table width="100%">

  #foreach ($link in $links)

  <tr><td><a href="$link.Url" class="$link.LinkClass">$link.Text</a></td></tr>

  #end

  <tr>

    <td>

      <a href="WorkspaceSetup/CreateWorkspace.bat.txt" >

        Workspace Setup Script

        <br/>Save As .bat

      </a>

    </td>

  </tr>

</table>

Here is an example of some NAnt script added to the personal build that checks for VS 2005 SP1:

<property name="VisualStudioServicePack" value=""/>

<readregistry hive="LocalMachine"                  

              key="SOFTWAREMicrosoftDevDivVSServicing8.0SP" 

              property="VisualStudioServicePack" failonerror="false"/>

<ifnot test="${VisualStudioServicePack == ‘1′}">

  <ask answer="Answer" 

question="It looks like Visual Studio 2005 SP1 is not installed.  Do you wish to continue?" 

      caption="Proceed Without Required Software?" 

      showdialog="true" >

    <options>

      <string value="Continue"/>

      <string value="Stop and Install SP1"/>

      <string value="Exit"/>

    </options>

  </ask>

  <ifthenelse test="${Answer == ‘Stop and Install SP1′}">

    <then>

      <asyncexec program="cmd" 

      commandline=‘/C " explorer http://msdn2.microsoft.com/en-us/vstudio/bb265237.aspx"‘ 

          createnowindow="true" 

          redirectoutput="false" 

          useshellexecute="true" 

          waitforexit="false" />

      <fail message="Installing VS 2005 SP1!" />

    </then>

    <elseif if="${Answer == ‘Exit’}">

      <fail message="Please install VS 2005 SP1!" />

    </elseif>

  </ifthenelse>

</ifnot>

The batch file for creating the workspace is a little clunky compared to NAnt script.  I have been mulling around the idea of including NAnt in a self extracting zip and executing a script instead of this batch file fun:

echo off

set ProjectName=CI Factory

set SVN.URL=https://ci-factory.googlecode.com/svn/%ProjectCodeLineName%

mkdir "%ProjectCodeLineDirectory%"

SET /P Anonymous="Do you wish to do an anonymous checkout of the source? Yes for patch creators, No for submitters:(y,n)"

IF %Anonymous%==y set SVN.URL=http://ci-factory.googlecode.com/svn/%ProjectCodeLineName%

IF EXIST "%ProgramFiles%\TortoiseSVN\bin\TortoiseProc.exe" GOTO UseTortoise

svn –version

IF NOT %ERRORLEVEL%==0 (set PATH=%PATH%;%ProgramFiles%\Subversion\bin) ELSE GOTO UseSubversion

svn –version

IF NOT %ERRORLEVEL%==0 (set PATH=%PATH%;%ProgramFiles%\CollabNet Subversion Server\bin) ELSE GOTO UseSubversion

svn –version

IF %ERRORLEVEL%==0 (GOTO UseSubversion) ELSE GOTO NoSubversion

:UseSubversion

IF %Anonymous%==n SET /P SvnUserName="What is the user name you wish to use to checkout the source?"

set Credentials=

IF DEFINED SvnUserName set Credentials=–username "%SvnUserName%"

svn checkout %Credentials% "%SVN.URL%" "%ProjectCodeLineDirectory%"

IF %ERRORLEVEL%==0 (GOTO OpenFolder) ELSE GOTO END

:NoSubversion

echo I can’t find where you have Subversion installed!

GOTO END

:UseTortoise

"%ProgramFiles%\TortoiseSVN\bin\TortoiseProc.exe" /command:checkout /url:"%SVN.URL%" /path:"%ProjectCodeLineDirectory%"

IF %ERRORLEVEL%==0 (GOTO OpenFolder) ELSE GOTO END

:OpenFolder

explorer "%ProductDirectory%"

:END