Volume Number: 13 (1997)
Issue Number: 12
Column Tag: From The Factory Floor
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.
