# Estimate subplan weight#

Why do we plan? Trying to assign a numerical value estimate from first principles is mostly a waste of time, because what youâ€™d need to measure is by definition everything youâ€™ve decided not to measure (assuming youâ€™re only considering the value of planning, not doing it). That is, you canâ€™t inspect the evolution of the worldâ€™s values and costs (tools) beyond your own notes and thoughts (that would be planning). You also canâ€™t expand on and think through your own notes on the topic (that would be planning). Itâ€™s possible to provide a numerical estimate of value only from reference class forecasting, that is, experience in a particular domain.

Said another way, you have two options for estimating the value of planning. First, schedule a small planning session (i.e. a planning subplan) and see how much value you get out of it. That is, did you change what you are most likely to work on next? Are you likely to be able to reuse the plans you did create? Did the rescheduling improvements on the items you will do make up for the cost of planning? Second, you can try to remember how continued planning in a particular area (a â€śdomainâ€ť) paid off in the past (i.e. without collecting new data).

The frequency of how often you come back to planning should make you think of the step size in machine learning; a step is analogous to a plan and stepping is the experiment. You can e.g. accumulate steps and add them up before taking them (build up a plan). Itâ€™s also a terribly hard hyperparameter to tune, except through experience on the model you are trying to train. To pick a step size you often have to simply guess and experimentally check if the loss goes down.

Said another way, the value in imagining more possible worlds depends on your domain. How experienced are you in it (how much data do you have)? For example, in war the situation is unstable and rapidly changing; see the quotations in Plan. See also Cynefin framework and Volatility (finance).

If your values are not stable (what your customers are asking for) or your costs are not stable (what abstractions or resources you need to solve your problems) then you shouldnâ€™t plan as far ahead. You canâ€™t stop time, and the rest of the world is moving forward. In the terms of a version control system, you need to regularly â€śmergeâ€ť the thoughts of outsiders (who are making world state commits independent of you). These can be both changes in the market (what the world values) and changes in tools (what you need to solve a problem).

Usually, hitting some subgoal should be a trigger to go back to planning (many people have a habit to do so). Usually, the associated decrease in your uncertainties may lead to a change in your plans, and even if it doesnâ€™t you likely to need to plan out your next steps in more detail. Still, this isnâ€™t a hard rule. In theory you should compare the estimated weight of a planning subplan (based on this document) to the estimated weight of your currently selected subplan.

The noun â€śplanâ€ť is defined in the Test section below. We use the verb â€śplanâ€ť to mean any of the steps listed in the â€śCostâ€ť section. Humans are good at imagining the future and seem to do so to a fault; we crave stable learning environments/domains (with stable values and costs). See also:

# Test#

Estimate the weight (give a score to) a subplan, that is, a piece of plan that achieves some subgoal. Prefer the term â€śsubgoalâ€ť to â€śintermediateâ€ť goal; see the language recommendations in Goal. A Plan is typically associated with one goal (see also Planning), though we use more use it loosely if we intend to kill two birds with one stone. Itâ€™s trivial to define a new goal as the logical conjunction (AND) of other goals.

To estimate the weight (relative importance) of a subplan (e.g. small enough to do in a day), you need to consider it in the context of a larger plan (e.g. something that takes a week), all other larger plans that pass the same test (achieve the same goal), and all your goals (since it may help you achieve multiple goals).

An â€śactionâ€ť is the smallest (atomic, indivisible) possible subplan; see Reinforcement learning. For a high-level overview of computer planning, see Automated planning and scheduling.

A plan is a set of subplans (paths) that we expect will bring us to any state where some particular variable (in the state space) has a particular value (to any state in the set of goal states). See State space search.

Said another way, to weigh a subplan you need to consider its own weight as well as the expected rewards that you can achieve from the new state it brings you to. That is, you must consider the $$R_a$$ (rewards) associated with the orange squiggly lines in the drawing in Markov decision process:

## Graph example#

In the following git-styled graph, the * mark world states. A plan is also denoted git-style with e.g. a..b. In this example, a..c is a subplan of a..e. DAGs have long been used for scheduling. See Directed acyclic graph - Scheduling and PERT chart. The git style makes it easier to draw (in ASCII) and therefore easier to annotate in ways custom to the planning problem.

This approach is analogous to GitOps, where the state of a resource (such as a cluster or deployment) is tracked in version control. The first major difference of this system from GitOps are that it looks forward rather than backwards in time (â€śimaginingâ€ť commits). That is, it is prescriptive rather than descriptive. Relative to GitOps, this system also expands the state under consideration to the world/universe, which means it will never stay up to date automatically (it is only updated as often as you come back to planning). For a more detailed definition of GitOps, see GitOps | GitOps is Continuous Deployment for cloud native applications).

* h: Pay bills: B 2017-07-07 4PM $110 * g: Mow lawn: L 2017-07-07 3PM$90
* f: Buy a lawn mower: 2017-07-07 1PM $70 (immediate$10 deprecation of mower)
| * e: Lawn service mows lawn: S L 2017-07-07 3PM $120 | * d: Play with kids: S K 2017-07-07 3PM$100
| * c: Pay bills: S B 2017-07-07 3PM $80 | * b: Call and pay lawn service: S 2017-07-07 1PM$60
|/
* a: Initial commit: 2017-07-07 12PM $80  We assign scores (in$) to every world state. Putting $values on spending time with your kids and a mowed lawn clearly allows for every kind of Intangible asset. These wonâ€™t show up in your bank account, but they can still make you the â€śrichest man in townâ€ť if theyâ€™re what you want to measure (quote from Itâ€™s a Wonderful Life). World states are marked with what goals they achieve (e.g. B, K, L). The set of goal states associated with L is {e, g} in this example. L can be specified in greater detail elsewhere, such as grass in some acceptable height range. Often (not always) a reasonable sanity check is that the same goal adds the same value (in$) at every point in the graph.

Weâ€™ll use capital letters for states we want to emphasize in general, not just goal states. In this example S represents a subscription to a lawn moving service. When this state is true, we may pay e.g. \$20/week to get our lawn mowed. We can use this system to describe the administration of other significant resources as well, such as employees (â€śhuman resourcesâ€ť) or computers (â€ścomputing resourcesâ€ť).

If we were really using git these detailed states (capital letters) would not likely be recorded in the commit messages, but in files. From that perspective, these capital letters can be seen as the tree of files in the commit. To generate a short, unique ID (other than a capital letter) you could use an Issue tracking system. From that perspective, goal states are â€śfeaturesâ€ť (or fixed defects) and achieved states in general might be â€śtasksâ€ť (e.g. refactors that increase the amount of code that must be managed).

In this example, we would like to compare the subplan a..b to a..f. Starting along one path always involves forsaking all others (because time cannot be reversed). If we discover along the way that one approach is going to be e.g. more expensive than expected, we can â€śrebaseâ€ť an old rejected plan into the future.

## VNTE and INVEST#

This article uses VNTE as a synonym for â€śplanâ€ť based on the same three letters in INVEST (mnemonic). The letters SI are addressed indirectly. This acronym is useful because itâ€™s more specific than the word â€śplanâ€ť (an overloaded word) and it summarizes what needs to be considered in creating a goal/plan in the order it needs to happen (Value first, Negotiability and Testability second, and Estimation last).

## Single-use and multi-use plans#

The article Directed acyclic graph - Applications lists scheduling and data processing networks as the first two common applications of DAGs. Is there a fundamental distinction between scheduling and data processing networks? Both are forward-looking; we expect a data processing network to run (in the future) when we execute it.

Said another way, a Bayesian network is a data processing network that encodes a â€śplanâ€ť where the time scale is much shorter than a human-executed plan, and (critically) where we expect the plan to be reusable. Typically we use a different word (such as â€śprocessâ€ť) for multi-use plans, but when we expect to use a plan only a few times we may distinguish a â€śmulti-useâ€ť plan. See also the â€śfrequencyâ€ť characteristic used to describe plans in Types of Plans in Business: Breadth, Time-frame, Specificity & Frequency.

A circuitâ€™s time scale is much shorter, and its uncertainties are drastically different. Because its uncertainties are lower (though still not zero) we expect the â€śplanâ€ť it will execute to be much more reusable. We are so confident it will work, in fact, that weâ€™ve hardcoded it into silicon. Bayesian statisticians like to point out that standard logic can be seen as a special case of Bayesian logic.

The unifying concept is causality, and similar points are made in Directed acyclic graph - Applications - Causal structures to unify all of the topics under â€śApplicationsâ€ť in causal language. In causal networks we tend to drop a specific datetime from the nodes because we expect it to be reusable in the future. Our plans encode our causal theories about the world; what we expect will work to change state in it.

## Necessity#

In the language of Types of Plans in Business: Breadth, Time-frame, Specificity & Frequency and Plan, we must always keep an eye on the â€śbreadthâ€ť of our plans. Generally speaking, this is the amount of state we plan to manage or create as part of the plan. Itâ€™s not wise for an individual to execute a plan of high breadth directly for a variety of reasons (individual memory limitations, risk of too much theory without experimentation, ignoring value in executing faster with a team).

# Estimated cost#

Much of this process has not been automated, but see Brainstorming and Computer supported brainstorming.

## Limit planning time#

If you only considered the â€śvalueâ€ť in planning then the frequency at which you planned could be nearly continuous. That is, you could spend one hour every week, or four hours every month, for a total cost of about four hours every month either way. However, planning is a skill that takes you out of focused work on your current subgoal, and requires focused work (to some extent) in itself.

Therefore in practice we need to plan for a certain minimum number of hours, which indirectly determines the minimum possible planning frequency we achieve (more frequent is better, and possible with an established planning process). This minimum effectively determines the minimum size that your subplans can be (the â€śactionâ€ť size). In periods where you come back to planning every time you hit a subgoal, and your time estimates are accurate, you may notice all subgoals end up being about the same size. If so, you can avoid a requirement to regularly come back to planning (timeboxes).

All plans tend to reduce uncertainty about your action choice, at the cost of more planning time (imagining based on whatâ€™s in your head, rather than testing based on whatâ€™s outside it). An alternative way to reduce uncertainty, as mentioned, is to execute only the first step in an existing multi-part plan (preferring experimentation to theory).

## Reuse unexecuted plans#

You can often restore (rebase) old plans where youâ€™ve identified value. The more you plan, the larger this body of â€śoldâ€ť plans becomes (becoming both a burden and a helpful resource). Only include incremental changes in time on this graph; absolute dates would quickly go stale. On a team you could have multiple people explore different ideas in parallel. Everyone on a team should be coming up with and presenting ideas regularly, further complicating management of this artifact. For an example, see Select subplan.

One way to look at planning is as a process to let you Expand focus to everything you care about; the big picture. If you can see the big picture then you know it is more likely you wonâ€™t â€śmissâ€ť high value (critical) or low cost (opportunistic) tasks. Planning tools and artifacts let you see a â€ścompressedâ€ť picture of the state you care about to help you plan better. In theory, we expect the CEO of a company or the leader of a team to use planning artifacts to see the big picture and select the best actions for the group from all available options. These artifacts are small and so can easily be converted (on demand, i.e. the subset of tasks that is required) to e.g. the Jira (software) format. See also Comparison of issue-tracking systems and Comparison of project management software.

### Converting plans to history#

Obviously if youâ€™re seeing the big picture as you work, then your git history (via git log) should eventually match your plain text git plan. If it doesnâ€™t, then youâ€™re either bad at predicting the future or getting distracted. If you think youâ€™re getting distracted, see comments on estimating before expanding focus with a new browser tab in Expand focus. If your future vision is poor in this domain, you still want to retrospect and consciously update your priors.

One approach is to always label an entry with â€śTargetâ€ť (analogous to a build target) in your plan. This subplan should always including a time estimate (the E in VNTE). When you commit the plan to git, you commit to the plan and should aim to hit the goal by the (padded) time estimate added to the commit timestamp.

If you donâ€™t finish to your satisfaction (roughly, no need for an alarm) return to planning as you would if you had finished. Feel free to do so early if you want to quit early, or you discover a more valuable goal. Be opportunistic, looking for accidental value.

When you come back to planning, and as you start (e.g. right now), create a new Explore domain VNTE as your â€śTargetâ€ť with appropriate details. This will include the overhead of retrospecting and estimating the subplan weight for at least two goals. Itâ€™s not wrong to create a continuation subplan (because it still seems most valuable despite expanding focus), or to not continue (because youâ€™ve lost focus in going back to planning). See comments on execution-based prioritization and focal is important in Narrow focus. If you donâ€™t pad your estimates, the cost is planning overhead (you Expand focus to compare at least two ideas).

You should try to hit 60-90% of your estimates, and not take them too seriously when planning. A padded estimate is different than a MAP estimate; both should be considered when you weigh subplans. It may be even appropriate to talk about a probability distribution as well as point estimates if you feel two subplans you are contrasting will have probability distributions with significantly different shapes. Can you afford to target a VNTE that includes significant risk of failure given your time estimate? See Risk.

## Reuse experiences#

Letâ€™s say you want to reuse your past experience to get to a friendâ€™s house:

* Drive to friend's: ???
* At home: Fri 11:00
...
* Now: Wed 14:00
...
* Drive to friend's: Mon 15:30
* At home: Mon 15:00


For example, if you kept track of (can remember i.e. have priors, or wrote down) how long it took to do something in the past, you should be able to estimate how long it will take to do in the future. If it took 30m to get to your friendâ€™s house last time, you can guess it will be about 30m this time. If youâ€™ve been to your friendâ€™s house multiple times and you notice it typically takes 30-40m to get there, you may be able to more accurately predict it will take 35m to get there.

You have likely generalized the many experiences youâ€™ve had of driving into a reusable action for getting from A to B. Then even if youâ€™ve never been to your friendâ€™s house but know the distance to get there, you can â€śrebaseâ€ť that action (commit) or subhistory (branch) to your future and use your process associated with the plan to make a prediction about e.g. how long it will take.

Said another way, you have many mental (or written) functions that you Pattern match against your current subplan. You may see multiple fit the goal, in which case you have to choose the best fit (e.g. an action to drive from A to B and action to drive to your friendâ€™s). This pattern matching can easily fail; all your mental/written functions are tools and if youâ€™ve only been thinking about one recently (i.e. a hammer) then everything will look like a nail.

These functions should take as an input a goal, and a function to estimate the increase in value and the cost. The first function (â€śEstimate valueâ€ť) will estimate the increase in value (due to state changes) associated with taking the action, given a stable loss function and certain specifics of the state the action acts on. The second function (â€śEstimate costâ€ť) will estimate the time cost of taking the action given some of the same specifics (e.g. it may be slower on larger inputs). Both are compressed forms of all your past experiences taking the action, in order to run faster than considering all your experiences (though you may want to save the data).

The â€śEstimate costâ€ť function is also a good starting point for solving the new problem, if not the solution in itself. If you have to fix conflicts in this function when you rebase it to your new inputs, youâ€™re learning something from a new training example. You can see the â€śEstimate costâ€ť function as producing a sales quote and the â€śEstimate valueâ€ť function an advertisement (or sales pitch).

In practice, you may need to use your â€ścommon senseâ€ť to tune the estimates produced by these functions as you rebase. Still, your â€ścommon senseâ€ť can only be based on your past experiences. You may simply be adding more recent (or more) of your own experiences to the estimates produced by the functions.

A major advantage of having such a library of reusable actions is that, if the actions are small, you should be able to combine these old but reusable actions into new subplans. For example, if you had broken down the steps to get to your friendâ€™s house and your momâ€™s house you may have discovered some are repeated (e.g. closing the garage door) and some are easily generalizable (e.g. entering an address in an app to get directions). Directing the development of this library is similar to directing the direction of your career.

See Grok Your Bazel Build: The Action Graph for an introduction to actions in Bazel. The action graph is Bazelâ€™s â€śplanâ€ť for executing the build, constructed from the highly reusable plans encoded in BUILD files. A preference for small actions is explicitly discussed in Dependency Management | Bazel. In this context, smaller actions also make re-executing actions faster (through parallelization and caching).

Do not assume any dependency is necessary or good or bad. See:

## Find value#

We write â€śvalueâ€ť on every VNTE first (hence the order of the acronym). If you donâ€™t understand the value in a plan, ask the requestor for it. If the value is low, then you donâ€™t ever have to go as deeply into the cost estimate (saving planning time). If itâ€™s zero or negative, you can throw the plan away. Value drives all development, every new commit (businesses exist to make money).

What if you were to come to a network where you had no idea what parts of it were most costly to modify? You have to start with value first in any search for high weight plans. If you had a network where you understood the costs everywhere, but no indicator of value, no development would happen. If you didnâ€™t want to e.g. increase or decrease output, the conversation about the plan would never have happened.

What if you were to come to a network where you wanted to improve it without considering any of your own values (if e.g. you have none)? Youâ€™d have to ask someone who did have values with respect to the network. Bill Gates was famous for selling products that never existed; he was an early adopter of the vaporware approach. With vaporware, you can query the market for the value of something before it even exists or you have any idea how to do it. In issue-tracking systems we often talk about TODO-x where x is a number; itâ€™s possible to estimate the value of a goal before anyone has any precise (e.g. numerical) understanding of how to do it. Of course, no one would have created the goal if no one saw value in it.

So where do you start? As previously discussed, most actions have inputs and outputs. For example, to Share comment you need to have a comment ready in your head and a web app to post it on. To Set subgoal you need a TODO-x to act on. Until we generate at least one idea about how to make money, we canâ€™t evaluate it (assuming you have no reusable plans or experience).

Said another way, most actions require an imagined world where the input exists as state somewhere in it (before you apply the function to it). You might say these actions depend on particular state in the world, in the same way that a target in a build system depends on itâ€™s dependencies.

Are there any actions that require no input (depend on nothing) or produce no output (donâ€™t define a target)? If an action didnâ€™t produce any output or modify some piece of world state, it couldnâ€™t add value (though many actions only depend on space to â€śwriteâ€ť to). Similarly, no actions depend on nothing. Everything we do depends on our own existence; see comments in Update dependencies.

In the language of attention, these inputs are what are focal as you work on the task (the state you are attending to). When youâ€™re planning, you are expanding your focus to all the state that is necessary to control the state you are interested in changing, which is initially everything you care about. See Expand focus.

What actions involve expanding your focus to your whole life, everything you care about? We could call these â€śimplicitâ€ť actions because they are the first part of the planning subplan (and therefore are always an action option), even if you have no reusable life experience or reusable plans to go on. In terms of a git graph, they are always there for you to pick:

...
| * Implicit action B
|/
| * Implicit action A
|/
* Now


Search for â€śVâ€ť with these implicit actions. For examples of these kinds of actions, see Explore domain.

## No to negligence#

We have a million possible actions we could be taking in every moment. Every action you say yes to is a no to a million others. The power of the answer â€śnoâ€ť to people making requests of you is that youâ€™re avoiding tunnel vision on the one action that is focal to both of you (and valuing more than only your relationship with the person).

When you say no to these million different â€śwideâ€ť subplans, you are effectively picking the â€śdo nothingâ€ť plan on the state they target instead. That is, time leads to effects on state. We often act only to avoid the consequences of the â€śdo nothingâ€ť option (e.g. if you donâ€™t take care of the lawn, your child, etc.). When does value ever go down? The â€śno-opâ€ť action can be expensive and itâ€™s important to include it as another implicit action. See also Neglect and Negligence.

Itâ€™s hard to accept that value can go down. Itâ€™s also hard to model a world where so many actions are happening in parallel, rather than you as the agent selecting a single action (of any duration) from many. Two options for dealing with the problem are to use a service to manage the state, or to schedule reminders to add actions to update the state.

## Contrast subplans#

When youâ€™re down to e.g. 3-4 subplans you often need to â€ścontrastâ€ť (i.e. emphasize the differences) between them to help make a final decision among them. See Set subgoal to improve all 3-4 ideas to add more details until you get to a point where thereâ€™s a clear weight difference among them.

Refining the plan on the idea you will end up working on is not a waste of time because you will need to do it anyways to come up with a first step. It may be a waste to refine the other 2-3 ideas, unless you end up working on them later (ideally you have stable values, so that you do). Avoid a bias towards refining the plan on only your currently favored option unless you are willing to make changes that will hurt its weight (not just decrease the time cost). That is, emphasize the differences in value rather than cost.

Once youâ€™ve picked out an item, you must narrow your focus (see Narrow focus) on it. That is, close all your planning documents and everything else that may be a distraction while you dig into the topic.