The Build Monkey Antipattern

a common pattern in software development teams is to have a person who owns the build system. this may be a deliberate decision, or it may evolve organically as a particular team member gravitates towards dealing with the build scripts, automated testing and deployment, etc. while it’s normal for some team members to have a deeper understanding of these things than others, it’s not a good idea for the knowledge and responsibility for the build to become overly concentrated in one person.

the build system should be looked at as a module or component of the software application or platform being developed, so the philosophy taken towards code ownership apply.

if a single person owns the build system, everyone else becomes dependent on them to fix issues with it, and to extend it to meet new needs. there is also a risk, especially for projects which are big enough that maintaining the build system becomes a full time job, that a bit of a siloed mentality can develop.

if developers have a poor understanding of how their software is built and deployed, their software is likely to be difficult and costly to deploy. on the flip side, if build and test tools are implemented and maintained entirely by people who don’t develop or test the software, it isn’t likely to make the life of those who do as easy as it could be.

in the past few months i’ve taken on a role which is largely focused on this area, and have been helping a development team get their build and delivery system in place. pairing with developers to implement aspects of the system has worked well, as has letting them take on the setup of particular areas of the build and test tooling. this follows what martin fowler calls “weak code ownership”, allowing everyone to take part in working on the build and test system.

special attention is needed for stages of the path to production as they get further from the developer’s workstation. developers are keen to optimize their local build and deployment, but can often be fuzzy on what happens when things are deployed in server environments. this is exacerbated when the platforms are different (e.g. developers working on windows, code deployed on linux).

even without platform differences, developers understandably focus on the needs of their own local build over those of production system deployment. this is natural when server deployment is not a part of their daily world. so the best way to compensate for this is to keep developers involved in implementing and maintaining server deployment.

driving the implementation of the build and deployment system according to the needs of business stories has also been useful. so rather than setting up tooling to test parts of the system that haven’t been developed yet, wait until the design of the code to be tested starts to be understood, and the code itself has actually started being developed. this helps ensure the tooling closely fits the testing and deployment needs, and avoids waste and re-work.