If two processes need it, it does not go inside either one

Most ICM folders that feel cramped after a month have the same problem. Everything in them is a process, because a process is the only shape the tree knows how to hold.

Then you build something that more than one process uses. A video renderer, a formatter, a checker that validates output before it moves on. It has no home, so it goes inside whichever process needed it first, and now the second process reaches sideways into the first one's folder to get at it. Do that three times and the tree stops being a map.

The split that fixes it is processes and capabilities, side by side at the top.

A process is a job with an owner and an end. A capability is something processes call. The test is one line: if two processes need it, it does not go inside either one.

The part that does the work is what each capability publishes. Not its implementation, just a short contract: what it takes in, what it hands back, what it does when the input is wrong. Three lines is usually enough. Processes reference the contract and nothing else.

Two things fall out of that for free.

You can replace the tool behind a capability without opening a single process file. The renderer becomes something else next year and the contract does not move.

And when something breaks you know whose fault it is before you open anything. Output wrong but shaped right, the process is wrong. Output the wrong shape, the capability is wrong. That question used to cost me an afternoon.

The tell that you need this: you have a folder whose name is a tool rather than a job. That is a capability wearing a process costume.

9 comments

If two processes need it, it does not go inside either one