Before Hans Dockter got famous with Gradle he was just a normal software engineer like you and I.
He got frustrated, shouted at his laptop, and twiddled his thumbs waiting for his build to finish, just like everyone else.
Since solving his frustrations by building Gradle, Hans has worked with development teams from top tech companies like Airbnb, LinkedIn, and Spotify. By fixing build automation issues for these companies at scale, he’s got a pretty good idea about what works and what doesn’t.
Thankfully, even if you don’t work at a big well-known tech company you can still apply the same lessons to your own projects to build software more effectively.
Here are 5 quotes from Hans Dockter that’ll open your mind to new ways of building software.
1. “I started the Gradle project out of deep frustration in working in low-productivity environments. The amount of time it took to make progress and get feedback on changes in the enterprise environment was incompatible with how I work.”
Before Gradle was Maven, and before that was Ant. If you never built Java code with Ant, you’re not missing anything.
It involved downloading dependencies manually and storing them in version control. In Gradle you just declare a dependency in your build script, and Gradle automatically fetches it.
The more the build tool does for you, the better.
And when it does it fast, as a developer you become unstoppable. Suddenly you’re developing, testing, and deploying new features with minimal interrupts, without breaking that elusive state of flow.
Obviously getting to zero build time is unattainable, at least for now.
But Hans is brave enough not to settle for good enough. By incorporating features like incremental build into his build tool, repeating unnecessary work is avoided.
This ethos has obviously rubbed off on his team. Almost every Gradle release brings new performance improvements to make our lives a little easier.
2. “Most mature industries have engineering disciplines dedicated to making production efficient and effective. This includes chemical engineering and industrial engineering sectors that have process experts widely understood to be essential to their firm’s economic success.”
Despite the fact we use its products 24/7, the software industry has only existed since the 1950s.
For much of that time, software development was separate from the business. The department was given a list of requirements and expected to deliver something years later.
Thankfully, with the introduction of Agile, development is now much more integrated with business. We get features to market in weeks, not months or years.
But there’s still A LOT of waste:
- Teams sit back and wait for their slow build to complete, telling themselves “that’s just how it is”.
- A few tests fail on the way to production, and they say “we can just ignore them”.
Proactive teams measure everything in their deployment pipeline and invest in fixing bottlenecks. It can be difficult to get buy-in from the business, but when you express a problem in terms of how many man-days / year it wastes, people start to take notice.
Whether you’re on a big or small team, taking an interest in your build system and delivery pipeline can be one of the biggest payoffs to make the development ecosystem in which you work more enjoyable.
3. “Process improvement initiatives will fail without bottom-up, grass-roots user acceptance. The intuitive case for DPE [developer productivity engineering] is not based on the impact to management…instead, it is based on a visceral understanding of the pains experienced every day by developers.”
5 years ago I joined a team which, to put it politely, had underinvested in developer productivity. You couldn’t even start the application without following a 1960s NASA-style launch procedure.
The problem was that the team had got used to developing software at a snail’s pace. They didn’t know any different.
Fortunately, the team was small and my boss was also a developer. I painted a picture of a better developer ecosystem using tools like Gradle and Docker. Eventually he got on board.
Hans knows that when you’re stuck in a trap, the first step to getting out is knowing you’re in one. Once you make a small improvement that your team notices, eventually they too will believe things can get better.
With your team behind you, justifying investment in your build and deployment systems to management becomes much easier.
4. “Most developers want to work in an environment that enables them to work at their full potential. Organizations that cannot provide such an environment are seeing a drain on their talent.”
If you join a team and see room to improve the development process, it can be fulfilling to get the chance to implement that.
In more process-heavy teams that might not be possible. You might want to fix the CI pipeline, but that’s managed by a DevOps team who won’t even give you read-only repository access.
If a company doesn’t provide an environment for software developers to do good work (or at least improve that environment), they won’t stick around for long.
From the developer perspective this is important on 2 levels:
- To work in a productive environment for your own enjoyment.
- To attract kickass colleagues to join you.
By surrounding yourself with developers better than you, you fast-track the learning process.
5. “Successful projects, in particular, suffer from inefficient toolchains. An unmanaged and unaccelerated toolchain will collapse under the pressure of project expansion.”
There’s nothing like the buzz of a growing team. New faces, lots of knowledge transfer, and people bringing years of experience to the project.
If you work in an office, maybe the occasional free doughnut.
Scrum masters busily organise work schedules, while developers race to implement new features. Eventually what was a small codebase grows exponentially.
The number of modules, dependencies and repositories increases, and slowly your build time creeps up.
Just because you use a modern build tool like Gradle doesn’t mean your project is immune to slow, unmaintainable builds. You must use Gradle to carefully model your build, then it handles the heavy lifting.
By using features like multi-project builds, custom tasks, and convention plugins correctly, you can ensure your build system scales in a maintainable way with the success of your project.
Hans Dockter has done a lot for Java software development by shining a light on the frustrating parts of the development process and shouting “this can be better!”.
Whatever your role, your team size, or type of project you’re on, a little understanding of the tools you rely on every day goes a long way.
After years using Gradle to improve the developer experience on projects, I put everything I know into a book. Following a step-by-step approach, you too can finally uncover the mysteries of the build script and help your team succeed.
To take your software building abilities to the next level grab a copy of Gradle Build Bible today.
Stop reading Gradle articles like these
This article helps you fix a specific problem, but it doesn't teach you the Gradle fundamentals you need to actually help your team succeed.
Instead, follow a step-by-step process that makes getting started with Gradle easy.
