Leadership does not see value in standard process for machine configuration and new developer orientation

Question

About 3 months ago our lead web developer and designer(same person) left the company, greener pastures was the reason for leaving. Good for them I say. My problem is that his department was completely undocumented. Things have been tough since the lead left, there is a lot of knowledge both theoretical knowledge we use to quote new projects and technical/implementation knowledge of our existing products that we have lost as a result of his departure. My normal role is as a product manager (for our products themselves) and as a business analyst for some of our project based consulting work. I've taught myself to code over the past year and in an effort to continue moving forward I've taken on the task of setting my laptop up as a development machine with hopes of implementing some of the easier feature requests and fixing some of the no brainer bugs that get submitted into our ticketing system. But, no one knows how to take a fresh Windows machine and configure it to work seamlessly with our production apps.

I have requested my boss, who is still in contact with the developer who left, ask them to document and create a process to onboard a new developer, software installation, required packages, process to deploy to the productions application servers, etc. None of this exists, and I'm spinning my wheels trying to get my computer working as a functional development machine. But she does not seem to understand the need for such a process to exist. Apparently the new developer who replaced the one who left has been using a machine that was pre-configured for our environment, so even the new developer could not set up a new machine if we added another developer.

My question is two part:

1. Am I wrong in assuming a process to on-board and configure a new computer to be part of our development eco-system should exist?

2. Am I being a whinny baby and should I figure the process out and create a document on my own?

Answer 1

First of all, it is odd that a developer has to setup the working environment. This task is usually for system administrator(s). So, taking into account that this isn't something you should do at all, you have the right to expect someone else to do this for you.

In most (if not all) companies there is a notice period. It usually ranges from a week to a month. But anyway that time is enough for the person leaving to help the company _ make some documentation, add comments to the code, document the architecture, etc. I'm afraid its too late to do this now, but don't forget about it next time someone leaves.

You are absolutely right to expect that there should be a process for setting up a new environment. In fact, if your company grows and you have more developers, you'll face the same problem _ this could be a heavy argument to convince your boss. You could even use the argument to convince the management to hire a system administrator for such tasks (I pre-assume you don't have one since you face the problem). Besides setting development environment, if you have a new machine it has to be integrated into the local net, etc.

Answer 2

Am I wrong in assuming a process to on-board and configure a new computer to be part of our development eco-system should exist?

No. Having these processes will avoid the problems that you have already faced. In some larger organizations, there is a standard disc image of what a developer's machine should look like. When a new developer is hired, an available computer with the right hardware specs is wiped and re-imaged using this "developer" disc image. A standard checklist (sometimes includes post-imaging software installation for certain tools not included in the image) is followed by the tech people that do this to ensure that all developer machines start off the same way (users can tweak and modify them after they get them - at their own peril!).

Similarly, some applications with notoriously complex setup have documents explaining to new developers how to check out the code, configure the server, and build and locally deploy the application. One application even has a setup script just for workstations to make this process easier.

Am I being a whinny baby and should I figure the process out and create a document on my own?

You are, but only a little bit. It's one thing to say that this should have all been documented long ago, and the developer who left should have done a complete knowledge transfer to their replacement days (or weeks if possible) before they left. It sounds like none of that happened, and it's all in the past now anyway.

So what now? I doubt the developer who left will be of much help. They already have a new day job and who knows what they're busy with in their own life. I doubt there's any legal grounds your manager could use to force them to help. It would be nice if they took a few hours of their own time to answer some questions, but don't count on it. It looks like you're stuck figuring out most of it for yourself. This gives you the opportunity to document the proper process thoroughly and get it right. Those whoe follow you will thank you for this! Good luck!

Answer 3

First things first, you need to get off Visual SourceSafe. I think that needs to be said. At the very least move to TFS. And there are other options as well.

Now that that's out of the way. I think this is a case of, "if you want things done right..." Your ultimate goal should be that a developer can turn on his freshly installed machine connect to source, get latest, hit f5 (or whatever you use for your run application shortcut) and have a working application.

One option is to build a working environment from the ground up and use it as a baseline developer image. When a developer comes on board, all you have to do is deploy that image to his machine and it should work.

There are some books on how to move your environment toward a more hands-off state. I like Continuous Delivery and Continuous Integration from the Fowler series myself, but there are other options out there.

Answer 4

When I started my current job we had a documented procedure for setting up a developer PC.

I followed the procedure on my own, determinedly avoiding to existing team's "help".

(The knowledge needs to be embodied in the document, not the developer who's been ther longest.)

I marked up the procedure with red-line changes where it was wrong or incomplete, and aw week later had two things, a procedure that worked and a working development PC.

After a hard disk failure a year later, it took 2 days to rebuild.

Tell your boss: if the hard drive fails on that PC, there will be no development happening!

I decided 2 days was a waste of two days....

Now we use virtual machines with disk images for each development project.

Setup is to copy the VM image to the target PC and start it. There is an icon called "runme" that you click on, It asks your username and then that changes the username used to access source code to your own one. It also changes the IDE's blank document author field to your name.

(I wrote runme in about 2 hours, we're developers, we program our problems away)

Our developer PC's are standard machines except for a VM server.

We're using virtualbox, which is not expensive.

Using Virtual Machines makes replacing a machine is a no-brainer 20 minute job. This task would be faster if we had gigabit ethernet to copy the VM over.

Full discosure: I'm the team leader where I work and my management give me a free(-ish) rein.

Answer 5

There should be some documentation saying what software is required to compile and run the application.

There should also be documentation outlining what a client box requires to run the application.

They are not the same list.

If your company were to hire a new developer, how long would it be expected for them to start coding? A day? A week? Without knowing what software is required to compile the code, this can be a trial and error process that could take a while. But, it should only be something that needs to be done once.

My question is, what is the new developer doing? This should be his job, not yours. He is the other guy's replacement. Yes, it sucks that he's entered an environment without documentation, but it should be his task to document things. Get him to sit down and figure out what the development environment is and to document it. Get him to figure out and document what is required to run the app on a client box.

As for contacting the old developer, I wouldn't. IMHO, if a dev leaves a company with no documentation or knowledge transfer, they are hoping to be called to do some work at a consulting rate. It is unprofessional and shouldn't be rewarded. Yes, it might take some extra time to figure it out for yourselves, but you/the team will learn something in the process and the documentation produced will be current and up to date.