No budget has a line for waiting. It is paid anyway, in salary, every time an engineer starts a build and loses the thread of what they were doing. The vendor of the build tool most Android teams use puts it plainly: "Build performance is essential to productivity. The longer a build takes, the more it disrupts your development flow. Since builds run many times a day, even small delays add up" (Gradle).
We Removed Our Own Promise
The earlier version of our engineering article on this subject promised to cut build times in half. Nothing supported that number, and it is gone along with the title. A vendor can publish results for its own sample project. Nobody can promise yours.
Measure First, Then Change One Thing
The instruction that matters most is numbered zero in the vendor guide: "Before making any changes, inspect your build with a Build Scan or profile report." The method that follows is a loop a manager can check on: "Inspect your build. Apply a change. Inspect your build again." A team that lists five optimizations it applied last sprint and cannot say which one helped has skipped this step.
The Defaults Are Conservative
Several of the largest gains are switched off until someone turns them on. Running work in parallel is one: "by default, Gradle runs only one task at a time". Reusing the results of earlier builds is another: "By default, Gradle does not use the Build Cache." Each is one line of configuration. Neither is automatic.
Structure Decides the Ceiling
Settings only go so far. If every part of the app depends on every other part, a one-line change rebuilds everything and no switch fixes that. The vendor calls tightening those dependencies "one of the most impactful changes you can make to improve build performance in large, modular codebases." That is an architecture decision, and it needs an owner.
What to Ask Your Team
- How long is a typical build, and where does the time go? If nobody has a report, nobody knows.
- Which of the off-by-default features have we enabled?
- What was the last change we made to build speed, and what did it measure?
- Who owns the dependency structure between modules?
-Rocky
#EngineeringProductivity #DeveloperExperience #BuildSystems #EngineeringDreams #StrategiaX
Originally published on ANDROID-ARCHITECT, the Android engineering blog of Strategia-X, with the settings and the CI workflow.