The wait equation is an idea that comes from science fiction writer Robert L. Forward and expanded on further by Andrew Kennedy. The basic idea is that the wait equation evaluates whether it's more advantageous to launch an interstellar mission immediately, with existing technology, or to delay until advancements enable faster travel, potentially turning centuries-long journeys into mere decades.
Now, I'm not going to bother with the equation itself especially since there doesn't seem to be a "canon" one but I think the same idea applies to investment in any fast-changing field as well. Using AI to illustrate, let's say you would like to undertake some project for your company and you would spend some amount of time T_s. Let's say that there are some vendors (ex. OpenAI, Sourcegraph, etc.) who are working on similar things and if their offerings were better, you would spend less time on this project (ex. you want to do a code search chatbot but Cody isn't good enough yet so you decide to wait until Cody gets better and then you just pay up for Cody). Let's say that the amount of time it takes to complete this project by integrating with a vendor that solves your problems effectively is T_v. Now, to determine whether or not we want to invest in a project subject to these considerations, we need to think through the difference between T_s and T_v as well as the cost of waiting. The cost of waiting is project dependent so we'll just add another variable C_w.
To think through the difference between T_s and T_v, we need to calculate the revenue opportunity cost. The revenue opportunity cost is represented by the following (Total annual revenue - annual glidepath revenue) / (# of employees - # of employees to KTLO). Note that KTLO means "Keep the lights on", it refers to the work that is necessary to keep a company functioning rather than increasing the company's revenue and glidepath revenue refers to the revenue the company would make without investment in increasing revenue. The embedded assumptions here are that anytime we want to spend an engineer's time on something that something should ideally increase our revenue from the glidepath revenue (the revenue we would get if we ceased research and development entirely) and also we generally don't need engineers to keep the lights on. Why do we care about this?
The answer is that if we assume T_s and T_v are quantified in weeks then we can do the following to calculate the value of the difference (T_s - T_v)*ROC where ROC is the revenue opportunity cost calculation from earlier. Representing this in Python:
// We assume T_s and T_v are in weeks
// C_b is the cost of building
C_b = (T_s - T_v) * ROC * 1/52
// C_w is the cost of waiting
if C_b > C_w:
print "Wait!"
else:
print "Build it!"
Now let's apply this concept to a real project. Let's say that we're deciding whether or not to invest in building out automated PR reviews for our company. Let's assume the total annual revenue of this company is 100 million dollars and the annual glidepath revenue is 80 million dollars. Note that it's very difficult to calculate the proper glidepath revenue in practice so there will usually be some kind of assumption made no matter what you do. Let's say we have about 400 employees but only 300 are needed to keep the lights on. This leads to an ROC of 20 million dollars divided by 100 which is equal to 200k.
Let's assume that if we had a vendor that met our needs, building out our automated PR reviews solution would just be a matter of spending 2 weeks encoding our review guidelines into something that the vendor would accept and integrating them with Github. By contrast, let's say that if we built our own solution it would take around 2 months (8 weeks). This gives us T_s(8) and T_v(2).
Now, we can do C_w. The cost of waiting is something we can calculate by estimating how much engineering time is spent in reviews and how long we're willing to wait. Let's assume our company operates on a semi-annual planning cycle so we'll wait 6 months. Then let's assume that engineers spend roughly 15% of their 40 hour work week. This entails roughly 6 hours a week on code review. Now, we can use our ROC from before:
// 2080 is the number of work hours typically in a single year
C_w = 200_000 (ROC) * 1/2080 (Converting to ROC per work hour) * 6 (# of work hours) * 6 (# of months) * 4 (# of weeks in a month) * 100 (# of engineers)
This entails C_w = 138_460 so the cost of waiting is $138,460. Performing the final calculation looks like this:
T_s = 8
T_v = 2
ROC = 200_000
C_w = 138_460
C_b = (T_s - T_v) * ROC * 1/52
// C_b = 23076.923076923078
In this case, C_b is significantly less than C_w which implies we should build it. Now, of course there's a lot of assumptions made in this particular example but hopefully it illustrates the broader point. Sometimes, a buy vs build decision isn't as simple as looking at vendors on the market and deciding whether or not their cost is less than the cost to build. Sometimes, it entails thinking about how urgently you need what you're looking for and whether or not the market will eventually produce a solution that meets your needs.