Time to 100, or tt100, is the amount of time it takes an engineer to write 100 productive lines of code and a way to assess how quickly the codebase is being meaningfully edited.
Who can use this?
| Core | Plus | ||
| ✓ |
How the time part is calculated
We start by looking at how much of the code is not removed or modified during an extended time period such as a month, while screening out noise like someone adding a large library. We'd then look at how many days each developer was active to come up with the result. We look at when people are actually coding and only take into account those spans of time so that days spent planning or holidays don't affect the calculation. We assume eight hours per day.
How it's useful
Time to 100 (tt100) is a measurement of how long it takes an engineer to write 100 lines of code. This is a way to measure velocity based on how quickly code is being produced (as opposed to something less concrete like tickets). But hang on. We all know mere effort is not the same as forward progress—which is why we use two different forms:
- tt100 Raw: The amount of time required to create 100 lines of any type of code, regardless of quality.
- tt100 Productive: Time required to create 100 lines of code, minus rework. In other words, forward progress.
Let’s look at an example of how this works. This graphic shows example tt100 statistics for an engineer, who we’ll call Tom:
Tip: This graphic shows tt100 differently than it appears in Flow and is used solely for the purpose of this example.
Looking at these metrics, we see a couple things:
- Tom’s tt100 Raw is trending down over time. He’s writing more code, faster, when measured in an absolute sense. In January it took him over two hours to write 100 lines of code, and by June he cut that in half to about one hour.
- However, Tom’s tt100 Productive has is drifting in the wrong direction. Even though it takes him less time to write raw code, it used to take Tom about three hours to produce 100 productive lines, but now it’s taking him almost twice as long to reach those same 100 productive lines.
The difference between these two tt100 metrics is important: it’s a sign that Tom is checking in a lot of work, but actually is struggling a bit compared to before. Knowing this, the team lead should intervene before this snowballs out of control. Together, they can discuss how to get things back on track.
Common culprits for this kind of shift include both engineering and non-engineering factors:
- Dead-end implementation paths
- Poor or shifting product requirements
- Lots of requested edits during code review
In the example shown above, this was the result of ill-defined requirements: Tom is working really hard, but a trial-and-error approach to defining feature requirements isn’t serving anyone. Knowing how much work is being wasted here, Tom and the team lead can now meet with the product owner and find out whether these late-term adjustments are worth the extra expense and delayed delivery.
Historically, these kinds of conversations are difficult to have in absence of concrete data. With tt100 metrics, this becomes more tactical: “The constant spec changes are causing this work to take 1.8 times longer than it normally does to deliver. We need to work toward clearer targets, or be comfortable with some significant delays.”
If you need help, please contact Pluralsight Support.