# How many toolsmiths should your team have?¶

This notebook explores how much of your team you should allocate to toolsmiths, and the corresponding tradeoffs. The assumptions are explicitly laid out and varied over different sets of ranges to give an envelope of potentially useful values: jump to the end of this notebook for a visualization that summarizes the envelope. THere are several different ways to interpret this data as well, depending on what you consider the job of a toolsmith to be.

Before you spend too much time reading -- or making extremely important decisions -- based off this notebook, you should remember that everything is made up, and the numbers don't matter. The point of this notebook is to help build intuition, and not to be a precise recommendation. All the graphs are low-fidelity and XKCD-style to reinforce that fact.

There's also a tl;dr; near the bottom: you can jump to it by clicking here.

This is part of a series of notes on building developer tools that ended up being much longer than I ever anticipated, available here.

## Utility functions¶

First, starting with a collection of functions that will be useful in building up the actual model, with a few simple tests next to each utility: following my style guide this notebook should be executable from top to bottom. (If you'd like to run it locally, remember to install humor sans for the pretty fonts.)

### Modeling the impact of toolsmiths¶

Using sigmoid cuvers as a way to model the effect of toolsmiths: if all the toolsmiths together put in $x$ person-days of work, the "productivity curve" returns the new productivity for engineers. (A "person-day" is the amount of work we expect the average engineer to complete in a day.)

The utility function is a heavily parameterized sigmoid curve to allow testing against different shapes and assumptions around how the effect toolsmiths can have.

### Brooke's law¶

A confounding factor while dealing with large teams is the slow-down triggered because of the coordination overhead, among other things. Assumptions for this particular exploration:

• each additional team-mate costs 1% person-day of time
• the total overhead is capped at a maximum of half a person day

(Presumably, some sanity prevails at that point, and engineers are organized into teams to cap the communication overhead.)

### Estimating work done¶

For simple calculations, assuming

• there are a 100 total engineers working on the project
• the total size of the project is 100 * 100 = 10,000 person-days

For these numbers, it'll take 200 days to complete the project (.5 productivity per engineer, 10,000 / (100 * .5)) without any toolsmiths.

To evaluate the effect of toolsmiths, it's interesting to determine:

• what's the maximum amount of work we could do in 200 days
• how fast can we complete the project

This utility function simply walks through each day, adjusting the productivity multiplier and total work done along the way. The interesting data is returned as a tuple, along with a line demonstrating the work done per day.

### Finding an optimal allocation¶

Finally building up to something interesting: a function to figure out the optimal allocation between toolsmiths and engineers by simply brute-forcing all options.

The example checks the optimum allocation with a linear productivity curve where we can double productivity by spending 10,000 person-days of work: both to maximize total work completed, and to minimize the time to finish the main project.

Then it checks these values by graphing out all the intermediate values.

### Varying the optimal points¶

Last but not least, it's most interesting to identify how the maximum work, minimum time, and optimal allocation change with different productivity curves. Abstracting this out to avoid duplicate code.

Testing this out with the simple linear model of productivity that we used above.

Exploring with a linear productivity curve, while varying the maximum increase in productivity.