Development Blog: Post

Clinton R. Nixon, Senior Developer, August 08, 2007 1

I recently attended O’Reilly’s Open Source Conference in Portland and was very excited this year to see a tremendous focus on testing. There were sessions on unit testing and test-driven development; but, I was most excited to see people tackling one of the most complicated and least-advanced testing environments: web testing.

Testing web applications has been a bit of a black art. You’ve got a minimum of three languages to deal with (HTML, CSS, and Javascript), perhaps a fourth language for your tests, and a cornucopia of environments in which to test. Each web browser can be seen as a virtual machine for your application and, currently, there’s a bare minimum of four different virtual machines your application will have to run in (Internet Explorer 6, IE 7, Firefox 1.5, and Firefox 2.) That’s the fewest you can get away with, and you also have to worry about variations in browsers running on different operating systems. Yahoo!’s supported browser list has 22 separate browser/operating system combinations. It is no wonder to me why developers throw up their hands at browser compatibility issues.

Luckily, the team at the Open Source Applications Foundation has been hard at work. Their new testing platform, Windmill, is still rough around the edges but seems to be a great competitor to Selenium. Windmill’s focus is making it easier to debug tests and author them in any programming language, as well as fitting into continuous integration. It provides you with a nice test authoring environment and console with any of its supported browsers to help in the traditional test, fix, and refactor development cycle.

It is easy to forget that we are in the early days of web applications. The coming of Web 2.0 and the heavy use of Ajax is roughly analogous to the leap from text-based command-line applications to graphical applications on the desktop. I am very excited to see our testing tools begin to mature to meet the new challenges of this platform.

Patrick Reagan, Development Director, June 27, 2007 3

By now you’ve heard the news that we’re growing our team and branching out into the Durham, NC area.  This is potentially a big challenge for us as we strive to maintain constant communication within our project teams and between staff across our two locations.  While we’re still deciding on whether to use iChat or Skype for our daily Scrum meetings, we’ve settled on Campfire to stay in contact while we’re cranking out functionality for our latest app.

Our initial solution was to use an internal IRC server to keep the development team up-to-date and provide a forum for questions.  We had mixed success with this approach and knew that it wouldn’t work if we tried to roll it out to the rest of the company for a few reasons:

• Geek factor – Sure, we cut our teeth on IRC back in our college dorms, but that’s no reason to force our non-technical employees to /navigate the sea of commands.  If we wanted company-wide adoption, we needed a more user-friendly solution.


• Some assembly required – Since we hosted the IRC server internally, it was firewalled off from anyone outside the office.  This required everyone in the Durham office to connect to the VPN to chat with the rest of us in DC - not fun!


• History – There are ways to log history in IRC and provide a searchable interface, but we’re too busy to bother with setting that up.  We needed something that worked “out of the box” to give joining users insight into what happened throughout the day.

We were skeptical at first, but after a month of constant use Campfire has proven to be a better tool than we initially anticipated:

• Communication has improved – Instead of just the core development team, we now have everyone involved in discussions throughout the day.  Project Managers can alert us of new issues that crop up in production (that we don’t see in our exception notifications) and Developers can get clarification on a proposed feature.


• Cool bots – When they’re not hanging out in the VL “Bot Tub,” our Capistrano and Subversion bots send messages to the team whenever a deployment or commit happens.


• Context included – When people sign in, they can see what has been happening throughout the morning.  This means that a Project Manager can see what features have been implemented and are ready for review on our autobuild site.

I’m increasingly optimistic about our ability to maintain our “offline” culture in this on-line meeting space.  We always strive to keep a good sense of humor even in stressful situations and Campfire has allowed us to maintain the same levity in our daily communication.  Sure, sometimes we have to force some conversations back on track, but we’re able to have fun and get work done at the same time.

Kevin McFadden, Former Staffer, February 15, 2007 0

Jeff over at Coding Horror relays a metaphor from Roger Sessions at MSDN describing how the technically inferior F-86 consistently beat the MiG-15 in dogfights and how it relates to developers.  The answer? Maneuvering the F-86 was easier on the pilot, resulting in less fatigue over repeated maneuvers.  Thus, a developer or project that iterates faster will yield better results than one that focuses on quality.

A man would do nothing if he waited until he could do it so well that no one could find fault.  ~John Henry Newman

Regardless of the accuracy of the metaphor, there’s one thing I’ve seen in almost every project over the course of the last 15 years:

When a programmer thinks something is finished is never the same as a project manager or client.  It doesn’t matter how much planning you have, if programmers are rushed or relaxed, or how much testing occurred.  There are many types of programming projects (server, client-server, web, computation, etc.), and each one has its own idiosyncrasies; but, something is always forgotten, misinterpreted, corrected—or, the client just changes their mind.  Revealing these disconnects sooner will help minimize the number of surprise moments at delivery time, as in the swing-set example.

The big benefit of quick iterations is the feedback process.  Getting feedback sooner than later is always good, assuming the client can accept that what they see after an early iteration is not representative of the finished product.  The quick feedback process applies to the developer as well since automated tests minimize the refactoring and validation time, allowing you to handle change with minimal pain.

As Jeff says, “when in doubt, iterate faster.” It’s not always that simple when working with external clients, but successful fighter pilots developers know that without agility, it’s tough to be successful—especially with web projects.