Mordy Golding, who spent a couple of cycles working as an Illustrator PM, has posted some perspective on how Adobe applications are created. It’s a bit of a long read, but Mordy touches on some common questions, including:
- How does the team decide which features to build & for what markets? For example, how is something like Flash integration weighed against something like N-color printing support?
- Why doesn’t the team have more resources to put towards various priorities?
- Why doesn’t Adobe typically add functionality in small dot releases?
- If a feature exists in one application (e.g. the OpenType palette in Illustrator, or separations in InDesign), why is it hard to move to other ones?
I’m never quite sure how much of this people outside the company will find interesting, vs. thinking "Just get it done, guys." (I bounce between those poles myself.)
As for resources, I think a couple of points are worth making:
- Very often, products don’t get staffed in accordance with the money they bring in. Photoshop, for example, doesn’t get anything like the number of engineers you’d expect based on revenue. Why? Because the revenue is needed to fund new areas of development that may not turn a profit for a while. Years ago, I’m told, the PostScript group (then the big bread winner) resented having to fund the dinky little applications group. Clearly, though, that was the right move for the future. At present it can be frustrating to know that you could do Kickass/Long-Requested Feature X if you had just one or two extra bodies (very frustrating) , but that’s the nature of the biz.
- Although we all clamor for more engineers & QE folks, without whom we can’t build anything, it’s probably good that we’re constrained. Otherwise, we’d go nuts building features, resulting in tons of complexity. That is, we’d be knocking ourselves out to serve customers, but rapid unchecked growth would probably overwhelm just about everyone.
I really think Adobe should look to unifying code bases going forward. Adobe applications are some of the most inconsistent I’ve ever used from one company.
If there was one set group of developers working on codebase X (let’s say Cooltype) then all Adobe applications would automatically get all the features or bug fixes in a new release.
Right now there’s a waste of time and resources if you have every application using different versions and different code bases for the same thing. It’s a lot of duplicated effort that shouldn’t have to exist. And if they are unified, it means it is far easier to add new features or fix bugs.
And since all of the Adobe applications are now updated in lockstep, it means unified code wouldn’t ship independently in different products. And apple takes a similar approach for it’s pro apps (the pro apps frameworks).
I am no programmer, but isn’t it somewhat counter-productive to have ‘competing’ libraries in apps (i.e. AI’s and ID’s text engines)?!
Wouldn’t it be easyer to develop a thorough scalable library and implement it across the range, thus freeing resources for app-specific features?
[Sure, absolutely. It’s just hard to do, but we do more of it every cycle, in ways that may or may not be obvious (e.g. the new UI in CS3, moving Photoshop to the common PDF engine in CS2, etc.). –J.]
I’m interesting in hearing this stuff – I’m no programmer but I’ve dabbled in it enough to have some interest in the development cycles of the big apps.
I also do web development, which is completely secondary to my being a designer. To do that I think it helps to understand the thinking behind your tools in order to use them better.
The technology we use can’t always be taken for granted. It’s easy to think that working with color is nothing for software, when in reality there is a huge amount of problem solving and testing needed before it can ship.
I’ve always though that Illustrator 9 added a bit too much all at once and that is probably why the application wasn’t stable or fast compared to prior versions.
I believe Mordy came on after AI 9 was out and helped with the long list of fixes. Even now I still see lots of designers abuse the transparency features because they don’t understand them.
So yeah, both you and Mordy are OK by me posting about this sort of thing. It’s good communication and fits right in with a company-sponsored blog.
Ah…how I’d love for ID, ILL, and PS to all share the SAME text engine.
[FWIW, they’re closer than they’ve ever been. But we hear you, and of course there’s the small matter of the former Macromedia apps & getting standardization there. –J.]
And how I yearn for the glyphs palette to be in Photoshop some day.
Sigh…
Some apps are pixel based vs. vector based so I would think that it’s not simple moving tools cross platforms. Plus, I’m sure how much object oriented development is done on these type of applications which makes sharing that much harder if your not and assuming they are on the same development platform. I would also be interested to know if your 6-sigma, lean, etc.