back to article Adobe edits the development cycle

For years the Adobe Photoshop team has been trying to get away from the traditional death march to a more agile development style. For its CS3 release, it made the jump, with the help of VP Dave Story. The result? More weekends off, and a third fewer bugs to fix. Mary Branscombe quizzed co-architect Russell Williams on how they …

COMMENTS

This topic is closed for new posts.
  1. Alex Batlin

    What about major re-arch work?

    I support the agile notion, and it works great when each feature is time contained enough that it can be completed on its own within a week or so.

    I have so far found it difficult to do the same on a major re-arch or re-factor exercise, where you do have to spend maybe three month with no easy to demonstrate output that people can actually start testing. Whilst I am sure it can be done, but the cost of hyper-division of work so far seems to outweight the benefit.

    Any comments about how to apply the agile method to the big-bang re-arch of an existing application, whilst in parallel doing minor service releases on the current arch, will be most appriciated.

  2. smallduck

    "For years"?, more specificially "For 10 years"

    http://www.mactech.com/articles/mactech/Vol.13/13.12/Dec97FactoryFloor/index.html

    Sean Parent: The Photoshop Development Process - by Dave Mark, Copyright 1997 by Metrowerks, Inc.

    ...

    Dave At this year's MacHack, you gave a presentation on managing the Photoshop development process with a relatively small team.

    [i was there! http://web.archive.org/web/19971009003116/www.machack.com/97/sessions/advanced.html]

    ...

    The traditional approach of getting all the features in-driving for an Alpha date -- and then bringing on QA is usually a disaster. ... Photoshop follows a more evolutionary cycle. Each feature moves to completion before we move on. QA is active for the entire life cycle. ... At any point we can cut off development on Photoshop and have the application ready to ship, from engineering, within 3 months.

  3. Eric O'Brien

    Same number of features?

    "Some people feared this would mean fewer features. That hasn't been the case." I don't know how one might actually *count* features, but as an end-user of Photoshop I find the feature set of the upcoming CS3 to be pretty thin.

    And this with a cycle time that's at least 30% longer moving from CS2 to CS3 than from CS to CS2. I count it to be about 24 months vs. 18 months.

    There are plenty of possibilities for new features... it's not like there is "nothing more to do." I can only hope that this new approach to development will give us CS4 in 12 months, AND with some significant new features. :)

    I wonder if the increase in the cycle time isn't because Adobe has gone to the "Suite" concept -- for each version of Creative Suite, aren't they aiming to rev ALL the products in the Suite? Products that are completed early must wait for which ever one takes the longest, right?

  4. Andy Dent

    re: What about major re-arch work?

    One way to apply the agile approach to a big rearchitecture is to base the initial development around writing tests and boxing parts of the existing architecture.

    This allows you to get feedback on if you are dividing up the existing architecture appropriately - are you getting testable chunks and can you write new software to talk to the boxed parts?

    It comes with a nice "shippable" side-effect - if you decide to avoid rewriting any existing chunks then they are already wrapped. It might just make more sense to use a screen-scraper to talk to a legacy program and put a web service wrapper around the whole thing.

  5. Mary Branscombe

    3 months vs overnight is a difference

    smallduck - Adobe wasn’t suggesting it was a revolutionary process or even utterly new – the point about them trying it before and the VP having been involved in similar at previous companies might give that away ;-) But this time they feel they’ve switched fully to incremental development – and 3 months to a working versions versus a working version every day is one big difference. Plus, that description is of quite a classic waterfall method of coders working on one feature after another in the main source tree; having features in isolated source versions and having a much firmer emphasis on bug fixing and a lower limit of bug are practical differences.

  6. Russell Williams

    Big Bangs, evolution, and feature counts

    The biggst bang changes we're doing have been recast as evolutionary: put in a new infrastructure and start converting pieces over piecemeal to use the new infrastructure -- requires that the new and old can coexist. In the past we've sometimes fallen down on this one by taking several versions to finish the last 10%. So we end up with 90% new stuff, 10% old, and 2 infrastructures for a while.

    The biggest items that can't coexist with the old just have to be started early in the cycle in a branch, and then the people doing them suffer through one or more extremely painful efforts to merge them into the main source. In the worst (thankfully very rare) cases this is accompanied by "nobody can change the main source this week while the giant "x" integration gets done". The Metrowerks->XCode conversion was particularly painful in this way, even though we kept the app building in both environments for a short while.

    Re: Sean's talk at Metrowerks, they gave up that time shortly thereafter and didn't make another serious effort at incremental development for at least another 5 years.

    #features. Every version we've shipped has gotten a certain number of complaints that the feature set was insufficient. "The last version had X and Y -- this version doesn't have anything that good". Based on the feedback from press and reviewers (who often have a lot of in-depth knowledge and have been using Photoshop for several versions), and our first-ever public beta (of several hundred thousand users), I think the amount of new feratures in this version is well on par with previous versions.

    One problem with a program that's got this diverse an audience is that the audience for the new features is split. We try to bias things toward the current growth areas and things that are broadly useful, and make sure that each key segment gets at least some love.

    There's a lot of other stuff in CS3, but I think the biggies (and certainly ones that took up a lot of time and energy) are: smart (non-destructive) filters, flexible B&W conversion, much better image alignment and blending (used for panorama stitching and merge to hdr, and now available to align or blend any layers), new Curves dialog, the quick selection tool, refine edges dialog (to refine any selection), Vanishing Point improvements (like non-perpendicular planes and pasting and dragging things around corners), more adjustments on HDR images, printing improvements, palette interface improvements in common with the rest of the suite, support for output for mobile devices, and a ton of new features in Camera Raw. And of course I'm not counting stuff that's only in the extended version. Oh yeah -- brightness / contrast actually does something useful to most people instead of just shoving your histogram off one side or the other.

    It feels like a lot to us, anyway.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019