Own (and Refactor) the Build
Often teams that at highly disciplined about coding practices either neglect build scripts or treat them as a black art. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code.
One rationale for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages, and that the build is what creates executable artifacts for developers and end users to test and run; the code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and some decisions about the build process that could make the code (or the coding process) simpler.
Build scripts written using the wrong idioms are difficult to maintain and, more important, improve. It is worth spending some time to understand the right way to make a change. "Bugs" can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong. The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work.
In earlier times, testing was something that was left the the "Quality Assurance" team. Now we realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.
Understanding the build can simplify the entire development lifecycle and reduce costs. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.
Learn enough of your build process to know when and how to make changes. Build scripts are code and are too important to be left to someone else, if for no other reason than because the application is not complete until it is built, and the job of programming is not complete until we have delivered working software.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page