Extreme web development?
As with many people for whom programming is central to their work (be they developers or project managers), I recently started feeling like the process of developing something (planning, coding, testing as discrete processes) was not very conducive to actually getting development done. This is exacerbated a bit when the primary focus of your development (as it is with most of the projects I work on) is the creative presentation.

In traditional development projects, it has been my experience that the QA portion generally gets the short shrift as deadlines get missed early in the process, but delivery dates don't get moved. With Internet marketing efforts, an additional layer is added to the mix in the creative development. With this being the focus of many of these projects (and, which clients who are typically marketing folks and not technology folks), now the entire technology aspect of a project suffers from the deadline creep phenomenon (QA, typically, still getting the shortest straw). The result is projects whose primary budget goes to creative development, with little money to build the functionality required by the client, or inherent in the way the creative was designed (especially in Flash projects).

It is because of such an issue with a project we are currently working on that I turned my attention to Extreme Programming this morning; something I had heard mention of from time to time, but had never stopped to take a look at. Somewhere along the lines I got it into my head that it was a more iterative development cycle which might be adaptable to our projects. I'm, admittedly, still trying to get my head around what Extreme Programming (XP) is all about, but the thing that struck me about it, and that, no doubt, strikes most people about it is that it pairs up programmers on the same computer to build code.

While this is an odd idea on the face of it, it struck me as an obvious (in retrospect) way to handle many of the typical time-wasting parts of programming. I'm not going to go into a discussion of what XP is all about and what problems paired programming solves, nor am I going to go into a discussion of what some of the apparent (to me, anyway) problems of this method might be. What ever the pros and cons of paired programming, it was really set up to work on projects of a larger scale than the ones we usually work on where there are at most 3 developers, and in by far the most common scenario, there is only one.

What it took me until late this evening to realize is that we DO, in fact, have a problem that XP can solve: the creative/developer interface.

Let me start by saying that in our office the creative director and the web developer are entirely different people. The web developer being primarily a technical role, and the creative director being primarily....well...creative. I understand that other places handle these roles differently, but in our office, this is the way of things.

The problem is that there is a HUGE breakdown in communication between the developer and the creative as the creative does a good deal of their work on their own answering to internal account staff and the client, typically only touching base with technology on the eve of a presentation. What then happens is that only the most obvious technical issues of the design (those that we can think of on the spot, or very soon after) ever get pointed out to be rectified. Major problems are almost always found after the presentation and then its an issue of undoing client expectations which many an account person is loathe to do. Further, as the creatives build their conception of the site, they often discuss functions (as simple as what an animation looks like) amongst themselves and forget about it for the internal review, or assume that they had communicated it earlier (when in fact they are likely remembering a conversation they had with other creatives), meaning that the technology understanding of the build is out of sync with the creative understanding. And since the creative understanding is often what is sold into clients, technology suffers.

Enter Extreme Web Development. No doubt you see where I am going with this, but to be explicit, I am proposing putting a technology person AT THE DESK of a creative person FOR THE ENTIRE COURSE OF THE CREATIVE DEVELOPMENT. It's true.

No doubt this will drive our developers crazy (as well as the creatives) but for nearly all of the same reasons that paired programming is a good idea, paired designing is a good idea as well. It also has the benefit of streamlining a process that is desperately in need of streamlining. While the creative is working out a particular issue that doesn't immediately require a developer's attention (e.g. color correcting), the developer can be building the base code for the site and incorporating any elements that have been client approved, or aren't dependent on client approval. This removes the current lock-step process where the creative development has to be nearly completed before the implementation can begin. And when the developer has a question about how something should animate, what the timing is, or other details dependent on the creative's brain, access is instant.

This also has the benefit of cross training our creatives and our developers, another big problem in our office. There just isn't time to educate the creatives of what a technology can and cannot do. This often leads us with designs that are needlessly complex in one area, but don't take advantage of existing technology in another. Our creatives aren't tech people and we don't want them to be, but the more they know about what is easy and what is hard to do, the better our designs will take advantage of the technology for the good of all (including the clients).

Obviously, this is not without its drawbacks. In as much as Extreme Web Development (XWD, let's say) gains from pairing in all the ways that XP does, it suffers in all the ways XP does, and probably to a greater extent. Since we're talking about two entirely different job functions, working styles and personality types are bound to clash if the situation is not handled correctly. The up side is that in our office, most everyone is working on more than one project at a time. This provides pairings an opportunity to separate and work in other pairings, or alone (if, for example, a creative is working on an offline project).

The one thing that will make this more possible than it might normally be is the prevalence of laptops. Currently our developers have desktop machines to build on. That will have to change so that they can be more mobile. It is possible to mobilize the creatives as well or instead, but since color accuracy is such an important part of what they do, I expect they'll stick with their workstations for a little while yet.

There you have it. Web developers with their laptops parked at the desks of the creative directors for the entire course of the build. I'm going to push this through on the next project that presents itself.

Wanna know how well it worked (assuming you're arriving here much later than today)? Drop me a line at roblogATthenetatworkDOTcom.

Now, I really need to get to bed.
- posted @ 11:09 PM