Relearning the agile lessons

My coding has been getting a bit bogged down recently, and I've finally stepped back a little to try and figure out why.

One of the lessons of agile development is that things go more smoothly if one proceeds by small steps. I realize I've been trying to implement too much at once, and as a result the code has been getting away from me.

So how did this come about? In-browser unit testing can take quite a bit of organization to put in place, and I've been so flushed by the ease of throwing stuff together with jQuery that I've neglected to create sufficient unit tests, and instead relying upon manual operation testing of the user interface. For the highly-visible user interface functions, and proceeding in small steps, I was getting away with this. But my current task is to save a shuffl workspace using AtomPub. The AtomPub handlers I've developed do have fairly good unit test coverage, but the additional logic needed to assemble the workspace to be saved is also rather complex, and it is here that I'm getting bogged down.

So I'm suspending that line of development, and reorganizing the existing code into modules around which I can put in place some decent unit tests. Strangely, I now feel that things are once again moving forward at a respectable pace! This is all work that needs to be done sooner or later, and sooner seems best.

jQuery with Firefox gotcha: use .html, not .xhtml

I've been tearing hair out over this error message from Firefox when trying to run my test cases from the local file system.

uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///Users/graham/workspace/googlecode_shuffl/jQuery/js/jquery-1.3.2.js :: anonymous :: line 911" data: no]

Line 0

According to a random page I found on the web, it turns out to be caused by a subtle bug in Firefox and XHTML parsing. The file's DTD declaration calls for transitional, loose XHTML. The file was being served with a .xhtml extension. Changing the file extension to just .html solves the problem.

jQuery rocks!

I've been most impressed by the way jQuery has simplified coding for the Shuffl user interface.

I've been trying to analyze why this is, and I have two (partial) answers:

1. jQuery implements a kind of publish/subscribe architecture: a function or plugin is a kind of published service, and a jQuery selector is a kind of subscription to that service. The advantage of a publish/subscribe architecture is that implementations of of the service or function provided are very highly decoupled from implementations of the consumer of that service, which makes for highly modular and loosely coupled code.
2. jQuery makes the overall code very modular. It is remarkably easy to add a jQuery plugin to an application, and just use it at the point it is needed. I think this is in part due to the publish/subscribe pattern noted above, but also that there's more to it that that, but I can't quite put my finder on what that is. Maybe just inspired design!

I highly recommend jQuery for browser based rich web applications - I've never previously known Javascript programming to be so easy.

Agile modelling and development

It has often bothered me a little that the early stages of a project seem to fly in the face of the "normal" agile mantra that all effort should be directed to satisfying a user story. But in early project stages, I find myself spending time on high-level design activities activities, and creating technical infrastructure, that of themselves do not directly contribute to a user story. I find myself wondering if that's because I'm too technically motivated to be a really effective agile developer. Recently, a colleague pointed me to an essay, Agile Model Driven Development (AMDD) [1], from which I take some considerable comfort. What is recognized here is that even for agile development, it can be appropriate to take some time (but not too much!) to perform "requirements envisioning" and "initial architecture envisioning", to "get a good gut feel what the project is all about" and to "identify an architecture that has a good chance of working". As always with agile development, the goal is "to get something that is just barely good enough so that your team can get going". This essay also says "For your architecture a whiteboard sketch overviewing how the system will be built end-to-end is good enough" - it seems to me that the important thing here, to be emphasized, is end-to-end (or: front-to-back). That is, to sketch a system that connects all the way from a front-end user to a back-end storage or service. Without really planning it, this approach is broadly what I've been doing in the early stages of Shuffl. In the light of this article, time I have spent, e.g., evaluating back-ends, even though the first iteration does not call for any persistence, does seem to be appropriate. As I near the end of the first iteration, I think I can say that having a view of what the back end may look like does help me to make decisions about how to structure aspects of the user interface code. An area where I've found my own practice of agile development has fallen down is poor estimation of effort and tasks. Getting the balance of granularity right for estimating is, I think, critical: too coarse a granularity and key elements are overlooked; too fine and the plans made don't reflect the actual development process when code has to be cut. Part of the problem here may be working alone, rather than part of a team, so that valuable discussion and review elements of the process are absent. Recommended reading! [1] Agile Model Driven Development (AMDD), by Scott Ambler. http://www.agilemodeling.com/essays/amdd.htm