I am a build manager and release engineer with a programming/SW dev background. I manage build scripts and makefiles for our SW team on our project to produce different versions of releases and I thoroughly enjoy my job especially the automation and optimization aspects of it, even though I do not get to write production code per se. We have nightly builds and more formal build releases which I am in charge of making sure execute correctly.

One of the newer developers on my project is having difficulties building their software in their own local environment after making necessary changes.

It would be very time consuming for me to isolate their error by simulating their operating environment where they are unable to compile their modified code.

No other developers have come to me with this problem. Relatively speaking, we operate on a small to medium size team of SW developers (between 10 and 15 consistent developers) and all of the other developers are able to compile their code without issue.

Instead of spending hours simulating the new developer's environment and trying to reproduce a specific error in relatively complex source code, is it reasonable to tell them to just check their code into the daily build which I know exactly what is checked in and is maintained very intensely which I know for a fact compiles and builds without issue?

Update: the core issue may be the developer's level of inexperience in setting up their own dev environment. The code will compile fine before the changes are made, then once introduced to build fails. All other changes made to code do not run into compilation issues. All "daily" source code is under version control (managed by myself) so reverting to a previous version is a minor issue.

  • 8
    You're suggesting risking a broken daily build every time this developer needs to make a change for as long as he's employed, to save a few hours of troubleshooting? I have to say, you're the first build manager I've met who would make that trade off. – Karl Bielefeldt Jun 3 '16 at 2:48
  • 1
    Find out why his machine fails to build your software. It doesn't matter how much time it takes; solving the problem is essential. Pave the machine if you have to. – Robert Harvey Jun 3 '16 at 3:11
  • 1
    Tools like Vagrant exist just to alleviate this problem vagrantup.com – Neil Smithline Jun 3 '16 at 3:49
  • 2
    @NeilSmithline: Hmm... I think I would want to know why the build is failing first. – Robert Harvey Jun 3 '16 at 4:18
  • 1
    What info is available to the new developer to diagnostic why his code won't compile? Is he getting a compiler error and unable to fix it himself (possibly due to inexperience or ignorance) or is the error buried somewhere in the build process so he can't diagnostic it himself? – Vincent Savard Jun 3 '16 at 18:34

If I were in your shoes, I would take this as a chance to improve the build scripts so they can provide more detailed information about what exactly is failing, so finding the root cause should be a much simpler process than it seems to be now.

Moreover, instead of "simulating their operating environment", why don't you just walk over to the place of the dev and solve the problem directly at his machine? (Or, if you are in different locations, use some kind of screen sharing software for this)?

  • That is a very good point I am looking to make all aspects of the builds as robust and intuitive as possible. I inherited a bit of a mess for different versions so I am trying to weigh the pros and cons in my intermediate state of attempting to revamping build scripts as soon and effective as possible. – John Dream Jun 3 '16 at 7:18

For new developers, you should have a document, hopefully less than one page, with complete instructions how to set up their computer to create a build that they can run and try out. (Obviously this involves getting source code, all the required tools, and so on). And the very first task of every new developers should be to take that document, follow the instructions exactly, change the document to clarify anything that is unclear, find out how to make it work if it doesn't work by either thinking, googling, or asking colleagues and updating the document, and to produce their build.

If someone cannot get their build working, you go to their desk, find out the reasons, fix it, and update that document. It doesn't have to be intuitive. There need to be instructions that work and that can be followed without involving any mind reading. Experience should also not be needed, just the ability to read and follow instructions.

PS. Comment on another answer was: "It's also fairly common for existing team members to struggle to recreate their old dev environment when a new computer is provided." That's where written instructions come handy as well.

  • Also instructions that work may stop working due to a change in the base computer image that the new developer has (IT department changes, computer manufacture changes) or a change due to a newer version if one of the tools. – Eric Johnson Jun 3 '16 at 10:24
  • That's why the task is to make it work and update the document if needed. – gnasher729 Jun 3 '16 at 17:14

The core issue probably isn't inexperience setting up a dev environment. It's more likely to be that setting up a dev environment is a manual process at all.

I've worked somewhere that had pages of instructions on setting up a new dev machine, with an estimated time cost of two days to complete. This meant every developer had a slightly different set up, none of which matched the chef-managed CI machines, so code would build on a local machine then fail under continuous integration.

I don't recommend this every-machine-slightly-different approach. The developer who is struggling to build the code is likely to be extremely frustrated with the manual set up process, especially given it's slowing down development.

So I think you (or one of the developers) should entirely automate the set up. Either via a management tool like chef, or simply by providing a stock install with the dependencies loaded. I'm a big fan of vagrant, but sometimes you need the bare metal performance for compilation.


It is not unusual for new developers on a team to have trouble setting up their dev environment if the dev environment is not documented in an up to date fashion. This is really a point of attention for the other developers, not for you as a build manager. You own the builds, but the developers own the dev environment. It is up to them to assist the newbie in setting up their machine, and to document the process so it doesn't become a game of whack-a-mole every time someone new joins the team.

  • Agreed. It's also fairly common for existing team members to struggle to recreate their old dev environment when a new computer is provided. – Jon Chesterfield Jun 3 '16 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.