Dec 97 Factory Floor
Volume Number: 13
Issue Number: 12
Column Tag: From The Factory Floor
Sean Parent: The Photoshop Development
by Dave Mark, Copyright 1997 by Metrowerks, Inc., all rights reserved.
One of the most complex applications on either side of the great divide has got to be
Adobe's Photoshop. This month's Factory Floor interview is with Sean Parent,
Photoshop engineer extraordinaire!
Sean Parent sparent@adobe.com is an engineering manager and senior computer
scientist working on Adobe Photoshop. Being the author of Actions (a Photoshop 4.0
feature) has earned him the nickname "Official Photoshop Action Figure.
Sean joined Adobe in '93 coming from Apple where he was a senior software engineer
working on the PowerMac project. When he's not working, you can find him at your
local coffee shop or rushing home to spend a few minutes with his family.
Dave: In general terms, can you describe the Photoshop development
process?
Sean: If I had the time, I could write a book on this topic. Photoshop is a very large
application, on the order of a million lines of C++ code, and we have a relatively small
team, currently about 12 engineers, working on it. Our goal is to ship each release
simultaneously on Mac and Windows and our tier one languages (English, French,
German, and Japanese). We have a full version and a light version of the product
(Photoshop LE) and over 100 plug-ins.
We try and keep process minimal, with just enough in place to keep the complexity
from becoming chaotic. You can easily spend more time working on process than you do
working on product.
Feature ideas come in through market research, tech support, and from the team as a
whole. We also have a small set of target customers with whom we work very closely.
Engineering works with marketing to prioritize the features based on both customer
demand and feasibility. Each engineer is assigned a feature, and that engineer will
research the issues and write a short design document with input for HI, marketing,
and QA. Then he or she will implement the feature.
As each feature is completed and tested the engineers move to another feature. Each
engineer is responsible for keeping his bug count below 25 and testing occurs
throughout the product cycle. If your bug count goes above 25, it becomes your highest
priority.
Dave: What is your general approach to localization?
Sean: We have been spending a lot of time working on localization for the next
release, trying to streamline the process. Our approach is to imbed string tokens for
user visible strings directly where they are used. At runtime the actual text is looked
up in a unicode file from the token. The unicode text is run through a translation table
for the current platform script and used for display. We have tools that scan the
sources and generate reports about new strings, modified strings, changed strings,
duplicate tokens and the like. Translators are given a unicode text file with the tokens
in them and they just replace what they are equivalent to.
We also have an auto layout mechanism. It currently is a little heavy weight, you
have to enter expressions to completely describe the layout of the view. These
expressions are evaluated at runtime. I plan to, when I have the time, replace this
with a lighter weight and easier to develop for model that I've been working on.
This whole mechanism makes it very easy to develop since you just add strings right
where you use them, and it makes it very easy to translate. We have Pig Latin and a
bunch of other wacky versions of the application.
Dave: Any interesting opportunities for developers in the next release
of Photoshop?Sean: For those familiar with Photoshop 4.0, there is a feature
called Actions. An Action is like a small macro, you can record a set of steps (Action
Commands) and then play them back. For the next release we are exporting an API to
the Action system. You can now construct an Action Command and then send it to
Photoshop. The model is similar to AppleEvents but a bit easier to code to and it works
cross platform. Through this API you can bridge Photoshop to other scripting systems,
or write plug-ins that drive the application to do all sorts of things.
Dave: When we were discussing plug-ins you mentioned a unique menu
enabling technology developed for Photoshop. Can you tell us about
that?Sean: Most Photoshop customers have well over a hundred plug-ins. It would
be prohibitive, even for Photoshop, to keep these plug-ins loaded at all times. And it is
too time consuming to load each plug-in separately to query it to see if it is available
given the current document state. For Photoshop 3.0 we just had a set of flags that the
plug-in would provide, but with all the variables of a Photoshop 4.0 document this
was breaking down (the state of a document includes color mode, transparency
channels, color depth, selection, layers, etc.). The solution was to use the expression
evaluator, originally written for the view system and have each plug-in provide a
boolean expression which is evaluated to determine if the plug-in should be enabled.
The expression evaluator is about 3K of code, just a simple recursive decent parser,
and can calculate thousands of expressions per second.
Dave At this year's MacHack, you gave a presentation on managing the
Photoshop development process with a relatively small team. For those
folks who didn't get a chance to see the presentation, can you discuss
some of the core issues here?Sean: I think the biggest issue in developing
software, Photoshop or any other major project, is keeping things in control.
The traditional approach of getting all the features in-driving for an Alpha date --
and then bringing on QA is usually a disaster. Quality is an afterthought, with features
taking priority and you end up with a soaring bug count. Trying to rip half completed
(and wasted) features from the product to get to a point where you have something
shipable. This kind of development goes on all over the valley and is why software dates
slip. If you have a bug count over 10,000 how do you even begin to schedule a ship
date?
Photoshop follows a more evolutionary cycle. Each feature moves to completion
before we move on. QA is active for the entire life cycle. We have more QA engineers
than we have development engineers. By developing like this we can cut off
development when we are feature rich enough to call it a relase, wrap it up, and ship.
At any point we can cut off development on Photoshop and have the application ready to
ship, from engineering, within 3 months. Of course we have to schedule documentation
and outside dependencies, so making a cut is non trivial but we can be very responsive.
The other big issue that sends development out of control is what I refer to as the "fan
effect." This is all the stuff that happens after you hit that big ship date. You have a
bunch of people leave on vacation, you might loose a member or two of the team from
burn-out, you might have to do a bug fix release, you have tier 2 and 3 languages to get
out, marketing strikes a deal with someone to bundle your product but they need a new
version, you need an updater to go on the internet. People tend to focus on that first US
release and forget about the fan effect. All of these tasks chew your resources that
should be working on the next version. We are constantly looking at how to manage
these issues, how to plan for them, how to avoid them, and how to do them in parallel.
The goal is to hit that ship date and move everyone to the next version. We are still a
long way from that goal but we made a lot of progress between Photoshop 3.0 and
Photoshop 4.0 and the next release makes many more improvements.
Dave: Photoshop is clearly a performance sensitive application. What
process do you use to tune Photoshop for different processors?Sean:
Photoshop is architected so most of the performance critical code is isolated into a set
of "bottlenecks" that can be overridden. There are about 500 bottlenecks and these get
tuned heavily for each target processor. For the remainder of Photoshop, we focus on
picking efficient algorithms and writing maintainable, robust code. Then we measure
it and tune what is needed.
Dave: Photoshop is about 1,000,000 lines of C++ code. What kind of
framework do you use? With such a massive code base, how do you keep
it current?Sean: Photoshop was originally written with MacApp 1.1.1 in Object
Pascal. For Photoshop 2.5 it was ported to MacApp 3.0 and C++ and also ported to
Windows. During Photoshop 3.0 development Apple canceled the MacApp project (it
was later resurrected) and the Photoshop team took over development of the
framework. It still bears some resemblance to MacApp but we did our own port to PPC,
we have modified the view system, added scripting, our own exception handling
system, and lightened up a lot of the framework. Over 95% of the code is shared
between Mac and Windows.
For the next release of Photoshop, I would estimate that close to 50% of the
engineering time has gone into improvements in the code base, not features. This is
always a tough thing to balance. It is easy to spend too much time working on
architecture and not end up with a product and equally as easy to hack features in and
end up with an unmaintainable code base.
We try and keep the code base up to par with the latest language spec, OS features,
coding practices, et. all. The team is encouraged to spend time reading and Mark
Hamburg (my manager) and I are frequently handing out books to the team and making
runs to Computer Literacy. With as much code as we have, correct and robust tools are
very important. We are constantly trying out the new features in the compilers and
trying to raise the bar on our code. When a new language feature becomes available it
is rarely supported well enough through all the tools that we can adopt it right away,
but we can gain some experience and push tool developers in the areas we feel are
important.
STL (the C++ Standard Template Libarary) is a good example. It provides a
tremendous amount of power and can greatly simplify coding. But support for
templates is still weak among the compilers and linkers (the VC++ linker has a limit
of 255 characters for a symbol, and STL can quickly exceed that). You can also get a
fair amount of code bloat using STL, and none of the current tool vendors have linkers
that will fold identical routines (it is very common with STL to have multiple methods
that generate identical code but are operating on different types). We have started
using STL, but slowly until we gain experience and the tools get better.
Dave: Photoshop is one of the first major applications to take advantage
of the Latitude porting libraries. What can you tell us about that
experience?
Sean: Photoshop 3.0 was shipped for Sun and SGI built with Latitude. At that time the
Unix Photoshop team was a separate porting team (they were even in a different
division). The port went relatively smoothly, it took a team of 5 less than a year to
release. The code modifications they made have since been rolled into the main code
base. A lot of the changes were to get Photoshop compiling with the various compilers
and tuned for the specific platforms. The one great side benefit was being able to use
some of the Unix debugging tools like Purify -- we found and fixed a number of
difficult problems in the main code base from this effort.
Latitude supports a large portion of the Mac API with a large degree of fidelity. Even
direct access to many data structures is supported. It was certainly a much easier way
to get to Unix than a direct port.