April 15, 2007
Some perspective on how Adobe apps are built
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.