Own (and Refactor) the Build
Quite often teams that at highly disciplined about coding practices treat build scripts as a black art. Projects with highly refactored code have build scripts with duplication that are difficult to maintain, and cause many of the same problems that the poorly factored code causes.
One explanation for this is that build scripts are in a different language? Yet, most software developers enjoy learning new languages.
Is it because the build is not "code"? The application won't work unless you build it.
Much like code, where there is duplication in the build process is a place where things break when there are inconsistencies. Build scripts written using the wrong idioms make it difficult for others to understand how to improve the build.
The build process is where everything comes together to create executable code that is tested by developers, built in an integration environment, and tested. "Bugs" can appear when an application is built with teh 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.
A simple to execute build makes it easy to get a new developer started, and get consistent results when multiple people are working on a project (thus avoiding a "works for me" conversation). Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts are code and should be treated as such.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page