The Bad Build System Drinking Game

Software build systems. A lot of them are bad, but how bad is yours? Play the build system drinking game and find out.

• Take a shot if your build system takes more than 2 minutes to do an incremental build. Take 2 shots if it takes more than 5 minutes.
• Take a shot if your build system takes more than 10 minutes to do a full build. Take two shots if it takes a long time to do a full build, and there are no incremental builds.
• Take a shot if your build system downloads things from the internet without being asked to. This could be either because your build system is trying to act as a package manager, or because your build system invokes your operating system's package manager. Or perhaps it just invokes wget! Take two shots if it downloads things using an unauthenticated protocol (such as HTTP) by default.
• Take a shot if your build system only works on one platform. Take two shots if it only works on a specific release (or narrow range of releases) of that platform. For example, if it only works on Windows XP, or Ubuntu 12.04, but not later or earlier releases of those platforms, you have to take two shots.
• Take a shot if your build system makes very specific assumptions about the build environment, such as "the current username is bob" or "the build directory is always /opt/build." Take two shots if those very specific assumptions require more than two pages of documentation. Take three shots if those assumptions are undocumented.
• Take a shot if any part of your build system is proprietary. Take three shots if it's proprietary and the company that made it went out of business or lost the source code. This still happens sometimes in the embedded systems world.
• Take a shot if you get mysterious errors if you don't run "make clean" (or something like it) after certain things have changed in the source tree. Take two shots if make clean sometimes doesn't do enough and you have to "manually" clean the source directory with "git clean" or "rm -rf".
• Take a shot if you can't parallelize your build by running "make -j", "mvn -T 2" or a similar option. This could be because of poorly written Makefiles (or other build files), or because the build system itself doesn't support parallelization. Take two shots if the same user can't launch two builds in parallel in different source directories on same computer. This could happen if the build system creates a lockfile somewhere-- for example, the Scala Build Tool ("sbt") does this.
• Take a shot if your build system dumps the build products into the source directory (i.e. doesn't support out-of-tree builds.). Take two shots if the build products aren't in the git or svn ignore list, and create noise when running "git diff" or "svn diff."
• Take a shot if your build system was not designed to be run from the command line. For example, if it requires you to visit a web site or click buttons in a dialog box, take a shot.
• Take a shot if your build system recursively invokes itself. Take a shot if your build system generates build files and then invokes a different build system. Take two shots if your build system generates shell scripts or m4 scripts, like automake does.
• Take a shot if your build system writes more than a screen or two (24 or 48 lines) of output to standard output or standard error for a simple incremental build. Take two shots if it generates more than a megabyte of output. Take three shots if it generates more than a megabyte of output, but leaves out the exception text from failing unit tests (like Maven does.)
• Take a shot if your build system does more than build the software by default. For example, if it runs tests by default (especially really long tests), take a shot. If it starts a web server or SQL server by default, take a shot. Take two shots if there is no way to skip running tests. Take three shots if your build system deploys software to production by default when run without any additional options.
• Take a shot if your project contains build files for more than one build system. For example, if your project has build files for both automake and cmake, or both Maven and sbt, take a shot. Take two shots if there are things that you can only do with one build system or the other. Take three shots if nobody knows exactly what can be done with one build system or the other.
• Take a shot if your project's dependencies are undocumented... for example, if it depends on the bash shell or curl being installed but that isn't documented anywhere. Take two shots if it depends on an older version of a certain dependency being installed, but this isn't documented anywhere.
• Take three shots if your project has conflicting dependencies. For example, if your project pulls in Guava 11, but also pulls in another dependency that itself requires Guava 8, take three shots.
• Take a shot if your build system interacts with source control in any way other than just getting a commit revision to identify the version-- for example, if it runs a git or subversion checkout as part of the build process.
• Take a shot if your build system is based on XML. Take a shot if your build system is based on any external scripting language that the user has to install separately. Take two shots if your build system is based on Perl.
• Take a shot if your project's build files don't work with the latest version of the build system. For example, if your project uses automake and it doesn't work with the latest automake version, take a shot. Take two shots if you informed someone on the project about this and he or she told you to downgrade your build system's version.
• Take a shot if your builds sometimes mysteriously fail and nobody knows why. Take two shots if people know why but are too lazy to fix it.
• Take two shots if your project can't get repeatable builds. This could happen because your build system has a dependency manager which periodically refetches the latest versions of dependencies without being explicitly asked to do so-- like Maven does. Or it could be because your Makefiles are poorly written and pull in too much from the environment. Either way, take two shots.
• Take a shot if your project's build spews warnings messages. Take two shots if months go by and the warnings still aren't fixed.
• Take a shot if you can't build your project without building other bundled projects. Take a shot recursively for every bad thing that appears in the build system of those other projects.
• Take a shot if you are the only one who knows how the build system works. Take two shots if nobody knows how the build system works.
• Take a shot if you think that your build system might have started as a prank that got way out of hand. Take two shots if you're sure of it.