In "Never Hire a Build Guy", Rolsen writes about two different build systems written for the same taxonomy. Even though the systems were in the same domain, one was much more complex as it contained many more moving parts. Yet it was a much simpler system to build were as the simpler system build required one to follow 12 pages of instructions.

The reason Rolsen decided that one should never hire a build guy is that as long as there was someone to perform a complex build, there would be no motivation to address the problem.

...give any competent software engineer 12 pages of instructions and tell him to follow them, oh, twice a week and you will have an automated build before Thursday.

In the end Rolsen admits that hiring someone to perform the builds is a good idea as they do tend to have a different and valuable view of the system. Roslin has suggested that developers do not like spending any time working on the build system. Is the problem really that simple or is there a more complex reason why many shops have overly complex builds?

Personal Experience backs up Kirk's comment above. If you hire a dedicated build guy, they tend to have a lot to do at project startup, with spikes of work now and then as the build configuration needs changed , but quiet the rest of the time. To stop themselves getting bored, they add some really cool but complex features.

Far better (in my opinion), not only to get a competent software engineer to look after the build. Even better, rotate this function amoung the team so everybody understands and 'owns 'the build process.

Paul , FirstPartners.net

What typcially happens is when you hire this build guy, really what you hire is a young, inexeperianced person who doesn't really know what is possible. Hell, they don't even know how to develop or what is required of a large project.

With tight deadlines, this person is not given time to learn about builds, improve the builds, and make it so the builds can be done by anyone. They are spending too much time workthing through the 12 page document.

In "Never Hire a Build Guy", Rolsen writes about two different build systems written for the same taxonomy. Even though the systems were in the same domain, one was much more complex as it contained many more moving parts. Yet it was a much simpler system to build were as the simpler system build required one to follow 12 pages of instructions.The reason Rolsen decided that one should never hire a build guy is that as long as there was someone to perform a complex build, there would be no motivation to address the problem.

...give any competent software engineer 12 pages of instructions and tell him to follow them, oh, twice a week and you will have an automated build before Thursday.

In the end Rolsen admits that hiring someone to perform the builds is a good idea as they do tend to have a different and valuable view of the system. Roslin has suggested that developers do not like spending any time working on the build system. Is the problem really that simple or is there a more complex reason why many shops have overly complex builds?

Maven is a good way to simplify complex builds in my opinion.

I use maven every day and my opinion is it's overhead. I'd rather go with ANT and keep it simpler than having projects and silly project dependencies. but that's me.

If you are only dealing with one single project, Maven may be overkill. However, if you have to do similar things over and over again, Maven could save a lot of hassles for you. Moreover, if you use and give back to the Maven community or your own company's maven repo in terms of archetypes, you would be able to reduce your workload and training time because you reduce the customizations. Although the side effect is you would be eliminating your own job, which is fine since it should allow you to do other things that are more interesting (unless you're outsourced).