I don't like the inventory analogy. Code changes are the aggregation of keyboard events. At what point do these events become "inventory"? Every key press, ever

I don't like the inventory analogy. Code changes are the aggregation of keyboard events. At what point do these events become "inventory"? Every key press, every point at which the code compiles, every day, when the feature is done? It is still very clearly work in progress if it exists on a branch or behind a feature flag. Since people usually start out writing code on their own, the tendency is to wait until the feature is done before committing. Therefore, some pressure should exist to try to get things merged because that is actually optimal on a team. However, it doesn't need to be dogmatic or drag in analogies from the manufacturing industry. Technical debt is also a bad analogy. There is just the current state, the desired state, the set of activities required to go from one to the other and their associated cost. Sure, every now and then something hacky is done in order to (for example), land a customer which you plan to get back to (i.e. take on debt and pay it back later). It isn't that common however so the analogy almost never applies. How about we just stop using analogies in software altogether?