Uneven increases in build times are one of the 'silent' indicators that could point the project may be heading in the wrong direction. As someone who likes to put data in code and generate code with T4 Text Templates, I have to be careful not to overextend. I treat these build times as Canary in the Coal Mine, an early warning system.
I like to use a small C# Script File -csx, to measure the build times of the projects and to store the results in the markdown file in the root of the projects (location of the sln). To force myself to run this build speed test, I have created a bat files that prepare the environment for development (starting services like db, docker, etc.) and run build speed tests. Having it as clean as possible in a desktop environment is an advantage.
Having build times over time in the git is excellent because you can see how the project is evolving and how the build times are changing. This is not a 'scientific' or 'precise' measurement, but it can give you a good idea of how the project evolves. Sure, if we store build times in the pipeline, but this is simpler, and you can even compare different developer computers.
| DateTime | Computer | Solution | Build Time | Success | Notes |
|---|---|---|---|---|---|
| 2024-12-28 09:32:14 | ELSA | Shockley.sln |
221.87 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-28 16:45:24 | ELSA | Shockley.sln |
236.97 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 08:07:31 | ELSA | Shockley.sln |
246.35 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 10:03:38 | ELSA | Shockley.sln |
36.61 | ✔️👊😺🐯✈️💥🚀 | Removed T4 Templating to separate projects |
| 2024-12-29 10:06:39 | ELSA | Shockley.sln |
18.69 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 11:28:16 | ELSA | Shockley.sln |
60.43 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 11:30:10 | ELSA | Shockley.sln |
21.48 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 11:32:02 | ELSA | Shockley.sln |
29.32 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 12:41:07 | ELSA | Shockley.sln |
20.32 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 12:41:39 | ELSA | Shockley.sln |
19.38 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 12:42:15 | ELSA | Shockley.sln |
16.45 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 15:33:54 | ELSA | Shockley.sln |
17.14 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 15:34:31 | ELSA | Shockley.sln |
17.23 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 15:57:31 | ELSA | Shockley.sln |
17.55 | ✔️👊😺🐯✈️💥🚀 | - |
| 2024-12-29 15:58:02 | ELSA | Shockley.sln |
17.40 | ✔️👊😺🐯✈️💥🚀 | - |
| 2025-02-09 10:31:02 | ELSA | Shockley.sln |
20.24 | ✔️👊😺🐯✈️💥🚀 | - |
| 2025-02-13 08:16:18 | ELSA | Shockley.sln |
19.25 | ✔️👊😺🐯✈️💥🚀 | - |
| 2025-02-14 16:05:23 | ELSA | Shockley.sln |
21.33 | ✔️👊😺🐯✈️💥🚀 | - |
| 2025-02-14 16:05:58 | ELSA | Shockley.sln |
19.69 | ✔️👊😺🐯✈️💥🚀 | - |
Build times over time for the Shockley.sln solution on the ELSA computer.
I did some optimization for Shockley, removed some parts of the code that generated cs files from csv to separate projects, and built speed up considerably. Also, after 45 days since the end of the year, you can see that the project is a little slower. Unfortunately, I was already deep into the project when I added this script, so I don't have the initial build times, but I'm guessing they were much faster.
Conclusions
It's always beneficial to track software metrics as early as possible. Metrics do not have to be precise; they should be just good enough to provide insights. Having data for local build times is one easy metric we can implement quickly.
👊😺🐯✈️💥🚀
And for those wondering, 👊😺🐯✈️💥🚀 is an obvious reference for Razor and T-Bone from SWAT Kats.