Kief Morris asserts that having a professional on the team dedicated to managing the build process is an anti-pattern. Of course, any investor knows the virtue of a diversified portfolio, and having skills transferred across all members of the team is certainly beneficial, but surely having someone that really knows what's going on when the build fails is a good thing to have, not an anti-pattern?

The Build Monkey Anti-Pattern

 

surely it's a problem if you only have one person that really knows what's going on when the build fails.

I have played the role of "build specialist" in the past, and I think it depends on what is meant on a team by "build specialist." If there is only one person on a team that can touch the build scripts, that can fix the continuous deployment system, or that can configure the continuous integration server, that is definitely a problem. It is inevitable, however, that one person acts as the "build architect." The build system should have collective ownership, but there will always be one person who owns the vision for long term improvement, who acts as the domain expert in the field of builds, and who holds everyone accountable for having ownership over the build.

If you have a team of "generalizing specialists," (http://www.agilemodeling.com/essays/generalizingSpecialists.htm), having one person on the team that specializes in builds, while everyone else "generalizes" in builds, can work well.

This bit of foolishness was debunked by Adam Smith when he wrote about specialization in "The Wealth of Nations" back in 1776.  Is having dedicated Systems Admins an anti-pattern?  What about DBAs?  Heck, what about an accountant?  Following Kief's logic, having anyone at a company doing anything specialized means that "everyone else becomes dependent on them."

As a developer, I will get bored doing mundane tasks that a build engineer does.

I will not find it intellectually stimulating. I'd rather use my talent and creativity building something useful with my bear hands onto the keyboard.

I'll leave all the build engineering, project management, system testing and bean counting to other low lifes.

Do you mean Developers are smart and build Engineers are dumb? Streamlining the build process as an art, need to have passion about that work, most developers are not good at it and the excuse they come up is exactly yours. I am a developer but I love build work too.

Speaking as a "low-life" Build Engineer that currently works designing, developing and maintaining build systems for one of the biggest software firms in the world...I've gotta say, I've never in my history at several compaines met a "developer" who is even nearly half as "talent[ed] and creativ[e]" as they think they are.

The bottom line is...if coder's could do their own job properly, the need for dedicated build engineering/QA/Support would be almost zero...they can't, so I have a job...and a well paid one at that.

For small project it not reasonable to have a separate SCM person who would support build scripts. Only in the begining you need to put visible effort to setup build scripts, but the support is quite trivial. Most likely dependencies update would be the most frequent change and it could be easyly done by any team member.

If you have continious integration server then it could be supported by system administrator.

For medium size - big organizations it makes sense to have a sparate SCM department. The department would define SCM policies and processes for all projects in the company.

nuff said...

 

Bill

It is clearly not an anti-patternt. I'm working for a big IT company as a Build Specialist (Build Architect actually). We have a team of build engineers. We have a quite unified idea about how different projects shall be built. This allows us to build builds for projects fast. On small projects it is usual that any engineer can perform build modifications and help developers/testers to resolve their issues. On larger projects we usually assign at least two build engineers in order to have a deputy if someone would like to take a day off. One build engineer is assigned for many projects as well.

For us is Completely ok to support 20+ Java/.Net projects with 4 build engineers.

If we're talking about one developer who knows maven or ivy or gradle better then the rest of the team, but everybody else can rtfm to figure out what was done. then the author is clearly crazy to call that an antipattern. But we're talking about a dedicated FTE whose sole job it is to maintain a build, then something is broken somewhere on that project.