Theory of Constraints for Adobe Creative Suite

Recently I’ve been reading the book The Goal by Eliyahu Goldratt. Its a fundamental text of manufacturing management explaining the Theory of Constraints (TOC). It really has me thinking a lot about my own career goal. Here are some initial thoughts. After finishing The Goal I’ll have to find out if there are texts on TOC specifically for the software industry.

My career goal is to find a way to turn software production into something like a factory. There’s got to be a way to improve software processes in a way that is analogous to what the industrial revolution did for factory production. That is, crank out software on a very predictable and efficient process such that the art of computer science starts to become a craft. Assembly lines are analogous to the set of dependent events in the software process, which have been becoming more and more formalized over the decades. Interchangeable parts can be analogous to multiple versions of the same component or a component which replaces an earlier, obsolete component. Standards in tooling and quality are as applicable to software as they are manufacturing. To be sure, software is very different from manufacturing; but, I’d like to find a way to really revolutionize the software process into something more like a factory. Taking advantage of an existing revolution would be almost as satisfying.

I’m not sure how applicable TOC is for the software industry. We’ll see more when I’m done with the book; but, so far it seems only partly applicable to software creation in general. For the Adobe Creative Suite the concept seems to be somewhat more apropos. The Suite is really an assembly of many components and applications into a system of feature sets. As such, it seems the factory metaphor is more appropriate than when creating individual software applications.

Some definitions as they apply to Adobe software in particular:

Goal – Most simply put, the goal is to make money. For TOC this means increasing throughput while decreasing inventory and operational expense.

Throughput – For software this can mean the rate at which sellable features are delivered to customers. The sales rate is critical in order to maximize revenue; but, from an engineering perspective the rate of delivering unique, sellable features is more interesting. Given my particular role at Adobe, managing the Creative Suite, I’m most interested in an ecosystem of sellable features that satisfy creative and creative/developer customer needs. This can most easily be expressed as fulfilling key roles within the user workflows; but, such workflow attention is really not essential for the goal.

Inventory – Those assets which are consumed when creating throughput. For Adobe software (again, from an engineering perspective) this includes product ideas, project definitions, project requirements, designs, architectural designs, project plans, code modules, builds, test plans, test cases, components (libraries, etc.), application content, user documentation, (strike-through)integration documentation, applications (assembled components), installers, prerelease builds, media images (or ESDs), printed material, boxes and printed DVDs. There are plenty of business specific inventory items that I won’t go into such as advertising, marketing material and press demos. Software inventory is different from production inventory in that the storage cost is essentially free for almost all the inventory, just disk space on some server somewhere. The primary cost of inventory is the opportunity cost associated with sitting on inventory while it is in queue or waiting. The opportunity costs are quite significant though so the goal of reducing inventory is still important.

Operational Expense – The cost of taking inventory and making it into throughput. For software operational expense is dominated by personnel costs. Other items included in operational expense are things such as depreciation on equipment, utility costs and office space (which if owned can be part of inventory instead.) There’s plenty more but you get the idea.

The trick now is to find bottlenecks in the flow of inventory through the system so that the entire system can be optimized and flow can be controlled through these bottlenecks. Intuition and experience tell me that bottlenecks may occur at one or more of these locations: project definition, project requirements, implementing code modules, executing test cases, and integration (assembling components into complex applications or having applications coordinate feature sets). Some more investigation and actual measurements are necessary to determine the most critical bottlenecks. Then there is the task of optimizing the system by better control over the bottlenecks.

For very complex assemblies like the Creative Suite, the installers or build aspects can be bottlenecks as well. Indeed, I think these were bottlenecks in the past. One of my managers has kicked builds in the ass so hard that we’ve got it licked for the moment. It was a good lesson for me as well: never underestimate the value of a good release/build engineer. The last 18 months of my life were dedicated to the installer problem, which we now have a handle on but haven’t quite solved yet.

After that, using the standard manufacturing trick of reducing batch sizes should be very applicable to the software process. In this case, batch sizes really mean the size and complexity of the feature sets in any given iteration on a project. Just like in manufacturing, a smaller batch size allows us to get to market with that feature set sooner and respond to changing market conditions more quickly. SCRUM may have a role here.

Alright, enough for now. I’m through my second beer and starting to ramble. Hopefully I can find a text on TOC for software as well. Also, I’m TSP has a role here. More later.