Software failure statistics are abundant and serve as clear evidence that we must reform software development. While industry claims an IT labor shortage is the motivating force behind outsourcing, the greatest factor is directly related to our inability to deliver value-add software. As organizations continue to lose faith in IT as a trusted partner, the services we offer are little more than an ample commodity, and the search for cheaper labor will persist. But, there is no IT labor shortage.

Read more

For the past two years, I’ve been writing The Agile Developer column at Agile Journal. Most of the articles are small focused pieces that share my experience with a specific agile practice. This month’s theme is sharing agile successes, so I took the opportunity to traverse back through many of my previous articles and discuss how each of these practices fit into a more complete agile development approach. The Agile Roadmap can serve as a launching pad for those teams new to agile, or as a gap filler for struggling teams.

I’m sure there are some omissions and gaps in coverage - some I know of, others I may not. If you feel strongly about a practice or technique not mentioned in the article, please comment.

I wonder if Andy has seen this.

Since it’s inception almost two years ago, I’ve been writing the Agile Developer column for the Agile Journal. Shortly thereafter, I started the Agile Junction blog. While I’ve continued to write the column, I haven’t posted a blog entry in damn near a year. In my new role as Online Editor over at Agile Journal, I’ll be turning my attention toward managing all types of on-line content. Hopefully, that means more blogging, but it definitely means more activity surrounding other forms of on-line content. Thankfully, Liz will still be serving as Editor-In-Chief of the Agile Journal monthly publication. In the next few months, there are going to be some exciting changes taking place at Agile Journal. Be sure to check it out.

I encountered an incredibly interesting situation recently that clearly illustrates the importance of Continuous Integration. Two separate teams were each working on separate software modules. Eventually, these teams knew they’d need to integrate the two modules into a larger whole. Unfortunately, communication wasn’t that great between the two teams, and while they each had a robust suite of unit tests (they created stubs when testing the integration points between each other), and regularly tested their individual components, they did not ever test them together. Finally, the day came (late in the project, mind you), when the two teams needed to integrate. In fact, integration even went fairly well, with the two modules able to communicate between each other without many problems. Integration testing revealed something alarming, however. A major piece of functionality was missing. Each team thought the other was providing that behavior.

The moral of the story, of course, is that had these separate teams been focused on integrating their two components early and often, this problem would have been discovered much earlier in the development lifecycle. But working in silos is easy and integration is hard. By creating a false sense of progress by avoiding integration until late in the lifecycle, they jeopardized the project.

Agile 2008, being held in Toronto August 4 to 8, seems like a long ways away. However, the submission system just went live this week. I’m excited because I have the opportunity to help organize the Developer Jam stage. There are a few changes surrounding the conference for 2008, starting with the submission system, which is wide open to the public. Any session proposed can be reviewed by any registered user, so hopefully we’ll build some great sessions with the level of community involvement we hope to achieve. Because the conference has been a sell-out the past few years, we’ve also secured a venue in Toronto that can host up to 1600+ individuals.

But what’s most exciting for me is the return of agile in the trenches…getting down and dirty with the developer again. My main issue with last years conference was that it seemed to have forgotten about the developer. There was so much “agile in the enterprise this”, and “application lifecycle management that”. So I’m very excited to help build a track (we’re calling them stages) that focuses exclusively on the developer. I know we can all still stand to learn more about unit testing, continuous integration, refactoring, and more. Please, take a look at the Developer Jam, submit a proposal or two, and provide some constructive feedback. We’ve assembled a great review committee consisting of some outstanding professional developers (listed at the bottom of the Developer Jam page). Let us know what you think would be cool to incorporate into the Developer Jam stage at Agile 2008.

Updated (11/02/07) : Please note the responses from Alberto and Bob attached to this post. They’ve offered some assurance that Crap4J does not transmit any code to their servers, and that the licensing snafu was due to a simple oversight. They also resolve to correct the licensing agreements. Thank you, Alberto and Bob! : End Update

I went to install the Crap4J Eclipse plug-in. As part of this plug-in, there are four separate features, and I happened to actually read the license agreement for each of them. In a nutshell, for three of the features (Agitair JUnit Runner, Agitair JUnit4 Suport, and Public API for Generated Tests), the license agreement states that the software is experimental and primarily for academic, research, and open source use. But that’s not the alarming part. It also says that it transmits your code over the open internet to be analyzed on non-secure Agitair computers shared by multiple users. Here’s the exact text:

THIS SOFTWARE IS INTENDED PRIMARILY FOR ACADEMIC, RESEARCH, AND OPEN SOURCE
USE. WHILE COMMERCIAL USE IS ALLOWED, PLEASE BE AWARE THAT YOUR CODE
IS TRANSMITTED OVER THE OPEN INTERNET AND ANALYZED ON NON-SECURE
COMPUTERS SHARED BY MULTIPLE USERS.

I don’t like that much, and it seems a bit sneaky to hide that rather important note in a license agreement that I doubt many folks read. There should be a more noticeable disclaimer somewhere. Also, I found no such notice in the Ant Task distribution (in fact, couldn’t find a license agreement included at all). But that’s not saying the Ant Task does or does not transmit your code.
I don’t know the internal behavior of Crap4J. Maybe it doesn’t send your code anywhere. But the license agreement indicates that Crap4J does, or at the very least, that they have the right to do so. Maybe, giving them the benefit of the doubt, they didn’t fully review the license agreement, and aren’t aware of what it says. Either way, the fact that this important note is buried within a license agreement without any other public disclaimer is very alarming and deceiving.

A bit later than I had hoped, but I wanted to take a moment to reflect on Agile 2007 in Washington, D.C. last week.

I arrived at Agile 2007 on Wednesday, midway through the conference. After a few conversations with attendees , I’m certain I’ve captured the essence of the conference. Immediately upon arrival, I jumped right into the second half of a panel discussion focused on Agile Portfolio Management. Then last night, I was invited to an Agile Roundtable discussion hosted by the fine folks at Stelligent, where a significant portion of the conversation centered around agile adoption and transition. You can obtain an overview of the discussion in this eWeek article. Thursday, I attended two different sessions. The first discussed The Enterprise and Scrum, and the second focused on Agile in the Waterfall Enterprise.

Therein lies a major theme of Agile 2007 - agile transformation and agile adoption within the enterprise. It seems that the majority of speakers and attendees I’ve spoken with who have agile experience are Scrum masters, agile coaches, or agile mentors looking for better ways to bring agile to the enterprise. For instance, conversations that emphasize vendor integration and COTS software packages typically turned toward contract and vendor relationship management. But as a developer, my area of interest lies more with strategies related to testing an application that integrates with a COTS package, and the infrastructure required to support frequent deployment of a COTS package. Not that we need another session on testing… But seriously, we cannot forget the developer within the agile enterprise. Some ideas for great developer sessions that come to mind include choosing an agile technology stack, principles for increased architectural agility, and tools for an agile infrastructure. Maybe next year.

Of course, with that said, Agile 2007 appears to have been a smashing success. It was sold out well in advance, and the enthusiasm of the crowd was tremendous. The conference felt small and personal, which allowed for a high degree of interaction between the speakers, vendors, and attendees. Hallway discussions were frequent and intense. But after spending some time speaking to the folks in the trenches, I share their opinion…more content discussing agile development techniques would have made the conference even greater. After all, the developer produces the one [and only] artifact that truly matters..the source code (pssst…don’t forget that).

Now, onto SD Best Practices in Boston.