The Register hosts a Q&A with Photoshop co-architect Russell Williams about how the team changed its ways in the CS3 development cycle, making product quality paramount, improving the team’s work/life balance (i.e. fewer "Photoshop widows/-ers" who never see their loved one), and yet still delivering a rich set of features. In brief: rather than building all the features up front, then spending the rest of the cycle fixing them, the team moved to a more incremental development model, insisting that bugs be fixed as we went along (not allowing them to build into a late-stage "bugalanche"). The article is a good read if you work in product development, or if you just want some inside geekery on how this stuff gets done.
Russell addressed the engineering side, so I thought I’d add some product management perspective. Overall I’m pleased with how things have gone, but no approach is perfect, and it’s worth noting some of the challenges we faced. [Continued in this post’s extended entry]
- The team’s ability to deliver a public beta–a first for a major Adobe application*–is probably the single greatest tribute to the new method. In the old days, we could have delivered a feature-rich beta, but the quality would have been shaky at best. This time, as Russell says, "The public beta was basically just ‘whatever build is ready on date X,’" because we knew it would be stable.
- Flexibility means uncertainty about what features you’ll be able to deliver. As you’d imagine, that can be pretty stressful for a product manager whose responsibility is the overall feature set.
- It’s hard to do agile development when you have to interact with organizations that aren’t necessarily set up for it. Corporate marketing, for example, want to know early on what features you’re planning to ship. With our approach we deliberately kept ourselves from committing to certain things until late in the cycle. Short story: you have to keep the paint wet on documentation, marketing, demo scripts, and so forth much later than you otherwise would.
- This is particularly challenging when outside groups are having to handle a large number of projects at once—a situation that makes them want details & confirmation sooner, not later. And it’s one thing when you’re talking about marketing or docs, quite another when you’re talking about an external technology team (“Will you commit to doing the integration work we need?”).
- This was a learning experience for everyone, including beta testers. I think that a number of folks who were used to seeing everything up front spent more than a few months saying, “Er… so this is all there is?” And we could only say, “We don’t know yet, and we won’t know for a while. ”
- The upside of this was that we could make course corrections more easily than in the past. With the old method, an engineer would sign up for features A, B, and C, then get them all to a marginal level of quality as quickly as possible, then spend the rest of the cycle fixing bugs. With the new method, she would work on feature A until it was pretty well polished, asking for feedback the whole while. If we decided that further work on feature A was more important than feature B and/or C, we had a much better time making that trade-off.
- By the end of the cycle, then, we started hearing much happier noises from the testers than I remember in the previous two cycles.
- A minor point, but a real one: those of us who give demos throughout the cycle often had to juggle a great number of builds—the 3D build, the correct correction build, the performance build, etc. I’d often find myself running three or four separate copies of CS3 simultaneously on my Mac (possible via a little hacking of the resources). Tabbing through several identical feather icons while people look on is… interesting. So, if you’re going to go down this route and plan to demo, you should make sure you’re stocked with RAM. 🙂
*Lightroom, the Flash AS3 preview, and other efforts were different beasts in a variety of ways. Photoshop CS3 is the first time Adobe took one of its flagship, shipping applications and released it this widely with a full set of new features.
One comment with the article brings up the longer length of the development cycle and the perception that there are less features in CS3 compared to prior – basically that this time around it has taken longer for supposedly less.
[Heh–you know, it almost doesn’t matter what we do: some people will always perceive it to be a ton, while others will greet it with a shrug. I was just on a phone call with a French journalist who said, “It’s amazing how much innovation you guys have poured into CS3. It really dwarfs CS2.” Back in the days of numerical designators (PS4, PS5, etc.), someone would ways pipe up to say that “This is more of a .5 release…”
As always, any list that enumerates the changes big & small that we’ve made is kind of meaningless; all that matters is how they affect you, and sometimes the smallest things (e.g. making it possible to rename a layer right in the Layers palette, instead of in a dialog, as was enabled in PS7) have a big impact. I’m rambling, but the point is, you can’t really quantify this stuff. –J.]
It seems that the longer cycle would not be because the team changed the development process, but rather because of the Apple/Intel migration as well as the absorption of all the Macromedia product.
[Those have been, in fact, major, major challenges. That we don’t talk about them is probably the best thing we can say, because it means things have gone about as smoothly as one could have hoped. You’ll never see the year of effort that went into switching to Xcode, nor should you: it’s our job (and Apple’s) to make things Just Work. –J.]
Neither Apple or Macromedia has been mentioned specifically as a factor, so it does sound like your changes were the cause of a longer development cycle.
[As Russell said, the development cycle is specified by the company. We adjust our plans to fit. (That’s the only possible way to go when you’re building suites; otherwise everyone would set their own schedules.) –J.]
And to me, less shipping bugs is better product and that is part of doing good business. Other than the one-time Intel Mac issue, I don’t think many of us are dying for a yearly update to the Creative Suite.
[Nor were you ever getting one. The shortest cycle I can think of was Photoshop 5.5, which was (I think) 14 months. Everything else has been 18 months or more. –J.]
Sounds like a good change.
I don’t know if you can really call the development process we did for CS3 “Agile Development.” We really did a hybrid of many development methodologies. Perhaps we could call it “more agile” or “semi-incremental.” Was it better than what we had done in the past? Absolutely. Was it perfect? Nope. It was definitely an experiment and a learning experience. I remember a conversation really early on with a product manager who was more than a little skeptical of the changes.
[Impossible! I don’t know know what you’re talking about. 😉 –J.]
I’m planning to post something on this topic in the near future and I’ll be sure to frame it from the QE perspective -given it was really about putting “Quality First.”
[Great; please let me know when it’s up so that I can add a link to it. –J.]
One question: did only the Photoshop development team change its way to work or did other teams (Ai, Id..) do the same (good) thing resulting in an overall improved CS3 suite?
I couldn’t agree more. The feature that sold me on PS CS was the fact that in full screen mode you could move the image anywhere you wanted with the hand tool. In CS 2, it’s the fact that you can change the opacity and blending mode in the middle of a free transform. I don’t think these additions were featured selling points.
Speaking of free transform, this article helps me understand why one engineer getting sick meant that the full free transform for smart objects got derailed for another version. I’d have payed for CS3 if that were the only new feature. Which is not to say that I won’t be first in line to upgrade for all the other great improvements CS3 offers!
Speaking of free transform, this article helps me understand why one engineer getting sick meant that the full free transform for smart objects got derailed for another version. I’d have payed for CS3 if that were the only new feature. Which is not to say that I won’t be first in line to upgrade for all the other great improvements CS3 offers!
So my question is this. Does agile development mean that updating 300 copies of CS 3 on a network (both mac and windows) won’t suck?
Because CS2’s updates? Suck.
Dyson in a black hole – level suck. Thanks to that boneheaded installer Adobe uses, you can’t just push out updates with ease.
(Well you may be able to on windows, but sure as *hell* not on a Mac network).
In fact, there’s a thread about this on the MacEnterprise list, and it’s universal opinion that updating CS2 is the single most onerous task anyone running a Mac network has, and it’s made *extra* special by the fact that Adobe uses extra-low bandwidth connections to their update servers.
In fact, I’ll say that unless you start making us type in, compile, and build the patches BY HAND prior to deploying, you could literally not make the process suck MORE.
Me, I just wish that every single person at Adobe has to update CS2 a thousand seat Mac network SOLO. Maybe if you had to deal with that debacle of dumb and the pain it causes yourselves, you’d not be so blase about inflicting it upon others.
[Let me see what I can find out about the new installer. –J.]
The entire IT community would appreciate it. It’s amazing how making updates so painful can make you want to use anything else.
So… one developer working on a feature at a time. Did one developer do that feature for the Mac and the PC?
Yes, Troy Stein, each developer is responsible for features across all platforms (OS, OS revs, hardware) that we support.
Dave Story
Adobe