Skip to content

Speaking at ESDC

The first week of March will be a mix of old and new for me. I’ll be speaking at a new conference, ESDC, the Enterprise Software Development Conference. This conference isn’t just new for me, it is new period, taking over the traditional calendar-slot of the defunct SD West. If you’re interested in attending you can use my last name as a discount code when you register to get $100 of the full conference pass. You can also register to attend the expo for free as long as you register by February 28th.

I’ll be giving two talks at ESDC, both on Wednesday March 3rd. I start the day bright and early with #605 Going Lean: Slash Waste with Build & Deployment Automation at 8:15 am, and finish the day at 4 pm with #906 Creating Habitable Code: Lessons in Longevity from CruiseControl. Lean software development has been a hot topic for me lately, as members of BayXP and the Silicon Valley Agile Meetup should know, while practices for creating long-term sustainable code has been a long term sustained interest. I’ve delivered the Habitable Code talk before but this’ll be the first time doing it solo, without Paul Julius by my side.

Build Engineer Bootcamp and CITCON Minneapolis

Paul Julius and I have put together a training class for neglected population:  build engineers. We don’t mean release management people exactly, though sometimes they have the build engineer job. No, we mean those people who are told “go write the build script”.

Historically the build, like an installer, is a very low status job. So historically it goes to low status people, like the most junior developer on the team, or perhaps even a QA person. The result is that many build scripts, like many installers, more or less suck. I think this is more a reflection on the low status of the task than the skills of the person; there is just very little incentive for fixing a bad build. But that’s mostly because so few people have worked in environment with an excellent build they don’t know how much their missing.

We think that in the move to agile development your build can be a major blocker, or and that there are major productivity gains at stake, so it makes sense to approach your build engineering efforts as a serious task. We think this is a big enough problem with a big enough potential gain that we’ve organized a public Build Engineer Bootcamp for April 22nd-23rd in Minneapolis. Come and learn how to get your build system on a solid footing and then stay for CITCON (free, but separate registration) and learn about how to take your continuous integration and testing efforts to the limit.

Hope to see you there!

OSTATLI: Safari & Firefox with Watir

I went to Elisabeth‘s Open Source Testing Automation Tools Love In with a very clear mission: “Get SafariWatir testing my local WordPress instance the right way“, where the right way meant using a single script that would also run against IE and Firefox without modifications. I’m not sure I was a good OSTATLI participant because I spent most of my time in the corner trying to get my goal met while other people were talking about cool stuff (which is why Watir/FireWatir/SafariWatir didn’t make the list of tools; I didn’t know we were making a list). But I had a blast anyway and was able to meet my modest goal.

My starting point wasn’t quite ground zero but it was close. I used Ruby on a project for a couple of months a couple of years ago but I haven’t used it since. And I’ve never used Watir. The last time I wrote tests to drive a browser it was 2002 and I was using WinRunner.

My motivation for this project came as a side-effect of my recent change from full-time to consulting/contract work. I’ve been working out of NextSpace, a coworking operation in Santa Cruz, and that has given me a different set of colleagues than I’ve had in the past. I’m now daily rubbing shoulders with a range of interesting people, but a bunch of them churn out websites for a range of clients. The technologies vary — WordPress, Drupal, Flash, Ruby/Rails, etc — but one common factor is there seems to little in the way of automated testing, even for sites that involve a lot of custom coding. I’ve wanted to know if some of the tools from enterprise IT and product development could be applied in their context.

I was interested in using Watir for a few different reasons. One seeming motivation is that I’ve done some consulting for WatirCraft, but that’s getting things out of order: I was interested in what they’re doing before I started working with them. What really attracts me to Watir is the philosophy that they want to take maximum advantage of Ruby as a language, as opposed to having a language neutral API like Selenium. I enjoyed Ruby when I worked with it and I’d like to do more of it. I also really like the idea of Ruby as a language for testers. Testers have long done more coding than they get credit for; switching that coding to Ruby should offer more opportunities for collaboration with developers and more credit and status from the coding they were doing already.

I was also interested in doing this experiment with Ruby because Bret/WatirCraft have been working on a new WatirCraft framework, with the source available in GitHub, and one of the enabling changes in Watir was to allow browser independent scripts by using All the references I’ve seen to this reference IE and Firefox, but since I’m on OS X (and because I’m a bit of an Mac fanboi) anything that doesn’t work with Safari is a non-starter. I went so far as to ask for Safari support on the WatirCraft UserVoice page only to be told it was already there. Oh. Okay then…

So here’s what I actually did. I installed the very awesome MAMP, an all-in-one installer for Macs to run an Apache, MySQL and PHP stack. Next was WordPress 2.7. Ruby 1.8.7 came via the also awesome MacPorts. Then began the fun that started “sudo gem install …”:

  • safariwatir
  • firewatir
  • rspec
  • cucumber

I didn’t actually use Cucumber, but there was talk of it in the air and the examples look interesting so I gave into the peer pressure. (Maybe in a future OSTATLI…)

Honestly I struggled a bit getting started from that point, trying to run the Watir tests against SafariWatir… or even the SafariWatir tests on itself! But here the power of Twitter came in handy, with Dave Hoover stepping up from behind the SafariWatir twitter account and updating the directions for running the Watir tests in GitHub in real time. Dave likewise saved me from the rathole of the old SafariWatir tests. In the midst of my struggles I did come to appreciate GitHub. It was trivially easy for me to fork SafariWatir and send a couple of minor tweaks back to Dave. After years of taking submission to CruiseControl via patch files and working with CVS and SVN, I’m jealous!

Eventually I was able to sort our some basic RSpec syntax and some basic Watir syntax and put together this script which met my goal. If you have the default WordPress 2.7 site running on port 8080 (and you have the same admin password that I left hardcoded in the script) then this script will open Safari, log into WordPress, post a message and logout. Change Watir::Browser.default = ‘safari’ to Watir::Browser.default = ‘firefox’ (and install JSSH) and the script will run against Firefox instead. This setting is in script for connivence; if I were testing in anger I would be setting it with an environment variable from Rake as I ran the tests.

My plan for the future it to take this a step farther and try running the same tests from Celerity. My vision is a system where we run tests in Celerity for fast feedback and then run across browsers to surface compatibility issues.

I would love to do more work doing cross-browser testing with Watir (and fix some of the incompatibilities in the process). If you know of anyone with a contract for that kind of work they can contact me via The CI Guys website.

StrengthsFinder Report Circa 2005

Back in 2005 I read Now, Discover Your Strengths and took the original StrengthsFinder test. My top 5 strengths were:

Strategic: People strong in the Strategic theme create alternative ways to proceed.  Faced with any given scenario, they can quickly spot the relevant patterns and issues.

Input: People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information. 

Learner: People strong in the Learner theme have a great desire to learn and want to continuously improve.  In particular, the process of learning, rather than the outcome, excites them.

Individualization: People strong in the Individualization theme are intrigued with the unique qualities of each person.  They have a gift for figuring out how people who are different can work together productively.

Intellection: People strong in the Intellection theme are characterized by their intellectual activity.  They are introspective and appreciate intellectual discussions. 

My original fear was that the StrengthsFinder results would be like reading your horoscope: no matter what came back you’d find a way to make it fit. But at the same time I took the test so did two others in the management. It turned out we all shared 3 of these traits but the differences really did seem to fit the people. And looking back I do think it has been these traits have have shaped my career and my passion for what I do now.

A Dissenting Voice

PJ and I just received the feedback from our talk at SDBP on Creating Habitable Code. I was very pleased by our marks, particularly the 8.6 for “Would you recommend this session to a colleague?” But reading the comments, we obviously left at least one attendee unconvinced and unimpressed:

What was this? Some of the comments were lame. No code comments???? Typing speed tests for developers? Sounds like a work culture I would not want to be involved in. Gold stars? Social rewards?! This sounds like grade school practices! As a software manager, I do what I can to avoid this nonsense. This was the only session of SD2008 for which I had negative comments. Very little content here.

With the other comments offering to sooth my ego — “Excellent presentation, I wish every member of my team could have attended” and “Great information, much more than expected” among the most gracious — I have the luxury of equanimity when considering this negative feedback.

The result is that I’m very grateful to this commenter for reminding me of the dissenting voices, the ones I mostly don’t get to hear.

In my daily life most interactions are with people who think very similar thoughts and our disagreements are largely trivial. It’s easy to forget that we’re still the minority. Agile has certainly crossed the chasm, but while we’re working our way through the early majority there’s many more people out there unconvinced and unimpressed. (… or maybe just uninformed? Last night at the Santa Cruz iPhone Developers meetup I met an experienced programmer who had literally never heard of big-A Agile software development.)

In the big echo chamber of the Agile community I sometimes find myself losing interest, for lots of reasons. We seem really good at spending a lot of words to capture subtle differences in technique. If someone tells me they “do Agile” I have no idea what they mean any more. Doesn’t “agile” just mean “do good things” now?

So I thank this Lone Dissenter. I needed his reminder of just how different the world can be.

Career 2.0: What’s your strategy?

Jared Richardson and Matthew Bass are working on a new book on actively managing your career, and as part of that effort they’ve started a blog on it called Career 2.0. On Monday their entry was “What’s Your Strategy?” where they asked:

  • What’s the single best career move you’ve made?
  • The worst?
  • Do you have a plan today? Have you ever?
  • What career advice do you wish someone had told you X years ago?

Jared asked for feedback in the comments but I wanted to talk about this here, in part so I can look back later and see how things have changed.

What’s the single best career move you’ve made? Hard to say but the top two are probably starting OpenAvenue in 1999 (with Jayson Minard), and to start working on the open source project CruiseControl in 2001.

Starting a company was a great experience, a real adventure. We were able to define our own culture and we were very successful at creating the product we wanted on the schedule we wanted. When the market went south in 2000 we were just a couple weeks away from closing a round of funding that would have seen us through the down turn. Things ended badly for the company when the tech bubble burst but just about everyone involved in OpenAvenue said that they would do it again. For me the biggest takeaway has been a sense of agency, the feeling that I can make things happen, along with the belief that everyone has the ability if they have the belief — which is why I think the book idea is excellent!

I started working on CruiseControl in 2001 as a continuation of our vision from OpenAvenue. We had been making hosted development tools and planned to add a feature “like Tinderbox” for any hosted project, what is now called continuous integration. With the demise of OpenAvenue I decided to create the system for a company rather than the product/platform we’d had in mind, then I found CC. I’ve spent a lot of hours over the last 8 years working on CC and answering questions on the mailing list. Helping people has really been its own reward. But from a career perspective this has also given me a platform for articles, blog entries, talks at conferences around the world, consulting, and even starting my own (with Paul Julius) conference series (CITCON: Continuous Integration and Testing Conference).

The worst? It was a move not made.

Back in 1994 I was the manager of all online services for technical support at Borland. At that time “online services” meant CompuServe, Bix and GEnie, as well as our FTP site and our own dial-up BBS. One of the people working for me was Roger Wegehoft who managed our in-house systems and who researched new technologies we should consider in support. One day Roger came to show me something, NCSA Mosaic and “The World Wide Web”. I was blown away. The potential was obvious! We spent about 3 hours in animated conversation describing the following 5 years of the web, ecommerce and all. Roger mentioned that one of the guys who worked on Mosaic, along with Jim Clark of SGI, had started a company over in Mountian View to create a commercial version… and I’m pretty sure we ended our conversation with the understatement of my lifetime: “someone’s going to make a lot of money off of this”.

We did create a website, repurposing our BBS technical support content, and then we were part of the team that presented to the executive staff that Borland should have a corporate website. And my following 3 years at Borland were interesting and in many ways successful (I was the 3rd person on the JBuilder team). But I’d like to think that the person I am now would have left the conversation and driven immediately over to Mountain View to get a job at Nextscape.

Do you have a plan today? Have you ever? Yes and no. Even though I consult on marketing I’m a consultant with a marketing problem. Since the original incarnation of Agitar wound down in April 2008 I’ve consulted on a wide range of topics with different clients: product management, interaction design, code reviews, unit testing, continuous integration, iPhone application development, QA test automation, marketing and corporate strategy. The range of topics makes it difficult to describe what I do, but part of my joy comes from that range. That’s a dilemma I’ve only partially solved with the niche marketing effort of The CI Guys.

My current plan is to continue what I call philanthropic marketing: I give away valuable stuff and hope that leads people to hire me. A large part of this is through CruiseControl and The CI Guys but it is also in the form of organizing CITCON, the Silicon Valley Agile/BayXP meetup, and the Santa Cruz iPhone Developers meetup.

What career advice do you wish someone had told you X years ago? Slam dunk: Find your passion. Follow it. Sol said it perfectly: Passion is recession proof.

I’m a consultant right now because I have a passion for helping people do their work better. When I’m doing my job well I feel like I’m making the world a better place, that I’m reducing the amount of suffering in the world.

I strongly believe that joy in your work is important to do it well. Maybe I’m wrong and you can rise to the top of your field without passion… but why spend your life doing something that doesn’t turn you on?

Continuous Integration for iPhone/Xcode projects

I just committed an initial pass at an Xcode builder for CruiseControl. If you want to try it out you’ll need to get the latest code from svn. Right now the plugin is extremely rudimentary: it has only the single attribute ‘directory’ which is where it will invoke xcodebuild.

Here’s an example from config.xml for capturing the images below:

    <project name="RaiseMan">

            <currentbuildstatuslistener file="logs/${}/status.txt"/>

        <modificationset quietperiod="30">
            <svn localworkingcopy="${BookProjects}/${}"/>

        <schedule interval="60">
            <xcode directory="${BookProjects}/${}"/>

            <artifactspublisher dest="artifacts/${}"


Even though the plugin is very simple has all the basics. Like the Ant builder can monitor the build output while it’s happening from the dashboard, and you can see errors and warnings in the jsp reporting app and in email. But unlike the Ant builder you can also publish the build log as an artifact so that you an view it later as plain text.

see build progress in the dashboard

see build progress in the dashboard

view build errors

view build errors

publish log as artifact

publish log as artifact

view complete build log

view complete build log

Hope you like it!

CruiseControl 2.8 Released

As of Wednesday night CruiseControl 2.8 is available for download (full release notes).

I’ve got a good feeling about this release because unlike a lot of releases I have the feeling that we’re doing more than adding feature and fixing bugs (though we did that too). This release felt like we were paying off technical/hygiene debt at the same time, at least in a small way. Not major refactorings, just lots of small changes to make things better. Some examples are:

  • Putting historical information on the download page. It is interesting to browse the history of the project on a single page and it also allowed us to delete a page off the wiki that had similar information.
  • Dan added the ability to specify a log4j configuration file on the command-line. This is cool both because it allows people to make changes w/out cracking open the cruisecontrol.jar and because it allows people to use the log4j xml format. The xml format offers some options that aren’t available using the properties format so we’ve opened up another bag of tricks for our users.
  • We updated to a new version of Jetty and at the same time we’ve exposed the Jetty configuration files. Like with log4j this opens up a lot of new opportunities for people to add behavior.
  • The documentation is now served by Jetty. Till now our help files were there but not served but the webserver — you had to go to the public website instead. <slaps own forehead>
  • The documentation for distributed usage is now available on the website. We’ve had support for distributed builds for three years but almost nobody knows about it.
  • New css for the jsp reporting application. I can’t believe how dated those pages looked. I can’t believe it was so easy to change. I can’t believe we waited so long to do it. (Now to update the screenshot in the documentation…)

At the same time we’ve made these changes we’ve also laid the foundation for larger technical changes by upgrading our version of Java (to Java5), the JSP (2.1) and Servlet (2.5) APIs.

Good things happening, good things to come!

Searching for an Agile Core

Last week while attending Scott Ambler’s talk on Agile in Practice at SDBP I tried and failed to share his Agile Criteria slide in real time. Apparently there’s a limit to what iPhone, Twitter and sloth can accomplish in a dark lecture hall. So here, only one week and one day later are Scott’s criteria, the things he looks for when evaluating a team that claims to be agile:

Scott Ambler's Agile Criteria

  1. Developer regression testing, better yet TDD.
  2. Active stakeholder participation.
  3. Regular delivery of working software.
  4. Self-organization.

I had special interest Scott’s criteria because I’d just posted my own attempt to the CITCON mailing list the week before. I wasn’t trying to put together a magic recipe but rather to come up with a list of practices without which — or their equivalents — you will fail. My list was:

  • Iterations
  • Planning game
  • TDD
  • Automated acceptance tests
  • Continuous integration
  • Retrospectives

I think these two lists are pretty compatible, but there are two outliers: self-organization and retrospectives. I was surprised that Scott didn’t have retrospectives on his list. I’m naturally a lumper not a splitter, so I’m tempted to say that retrospectives are a vehicle for self-organization and call it a day. But I don’t think that’s honoring what Scott had in mind. By self-organization Scott meant the team should be organizing the work, deciding who does what. But is that really needed to be Agile? I can imagine using all the practices listed but having a manager assign the work for each story. I can imagine it… but it isn’t something I’ve ever done. I don’t remember having the need, though this may be selective memory on my part. Certainly the majority of the time who should do what is obvious to everyone, and when there are multiple people who could do the work then it is divided easily enough. So I’m not sure that self-organization is a requirement but I clearly believe it is better. Better to have people sign-up themselves and have feel a greater ownership in the project.

So is this it, do we have our list? If you’re not doing these you’re in trouble? I’m ready to put it to the test.

I (heart) my tests

(This isn’t for you. This is a love letter to my unit tests, who deserve it, who deserve a 5 am stream of consciousness homage.)

Slow builds really bug me. And having lots of unit tests is no excuse for a slow build. If you think they are, there’s something you’re not doing right.

This past week or so I’ve been much more active working on CruiseControl, and so the slow build time — 15 minutes for a release build? ridiculous! — were wearing away at my nerves. Even the subproject main was now taking 4 minutes to build, and I remember being unhappy when it got to 90 seconds. Something had to be done and tonight was the night.

Oh look, that one test class it taking 2 minutes all by itself. Why?!? It’s not doing anything very interesting. Hmm, any good free profilers out there? A google suggests not, so printf debugging profiling it is…

The setup method is taking 10 seconds? Well that’s bad… Delving… getJmxInfo() and getServerName() take 5 seconds each… ah, getJmxInfo() calls getServerName()! But all that’s doing is getting the server name with InetAddress.getLocalHost().getCanonicalHostName(). How about we cache the result? I mean how often is the host name going to change? Cache and run the test. 32 seconds! One change to go from 126 second to 32 seconds? How about the subproject build? Down to 2 minutes from 4?! This is going to stay.

I wonder how many other places in the code we’re getting the server name… Oh, a bunch! Extract out ServerNameSingleton.getServerName() and use everywhere. Run build…

Hmm, unit test failed. Expected 8000, was -1? Hmm… Hmm… Ah! Apparently just calling getServerName() isn’t enough, I actually need to assign it! Details, details… :)  Run the full release build…

7 minutes.

15 minutes to 7 minutes, for making one simple stupid change. That I found from investigating a slow test. And that I would have botched if it hadn’t been for another test.

Man I love my tests.

(Ok, now I can sleep.)