Standards for how developers work on their own workstations

Question

We've just come across one of those situations which occasionally comes up when a developer goes off sick for a few days mid-project.

There were a few questions about whether he'd committed the latest version of his code or whether there was something more recent on his local machine we should be looking at, and we had a delivery to a customer pending so we couldn't wait for him to return.

One of the other developers logged on as him to see and found a mess of workspaces, many seemingly of the same projects, with timestamps that made it unclear which one was "current" (he was prototyping some bits on versions of the project other than his "core" one).

Obviously this is a pain in the neck, however the alternative (which would seem to be strict standards for how each developer works on their own machine to ensure that any other developer can pick things up with a minimum of effort) is likely to break many developers personal work flows and lead to inefficiency on an individual level.

I'm not talking about standards for checked-in code, or even general development standards, I'm talking about how a developer works locally, a domain generally considered (in my experience) to be almost entirely under the developers own control.

So how do you handle situations like this? Are the one of those things that just happens and you have to deal with, the price you pay for developers being allowed to work in the way that best suits them?

Or do you ask developers to adhere to standards in this area - use of specific directories, naming standards, notes on a wiki or whatever? And if so what do your standards cover, how strict are they, how do you police them and so on?

Or is there another solution I'm missing?

[Assume for the sake of argument that the developer can not be contacted to talk through what he was doing here - even if he could knowing and describing which workspace is which from memory isn't going to be simple and flawless and sometimes people genuinely can't be contacted and I'd like a solution which covers all eventualities.]

Edit: I get that going through someone's workstation is bad form (though it's an interesting - and likely off-topic - question as to precisely why that is) and I'm certainly not looking at unlimited access. Think more along the lines of a standard where their code directories are set up with a read-only share - nothing can be changed, nothing else can be seen and so on.

Answer 1

"If it's not in source control, it doesn't exist."

This is one of the few things in our profession that I'm borderline dogmatic about. For the following reasons:

1. Even though the workstation is company property, let's face it - there is a bit of an unwritten rule that a programmer's own workstation is his/her castle. I'm just uneasy with a workplace culture where anyone can routinely log onto it and go through it.
2. Everybody has their own flow (as you said as well). Trying to force all developers to organise their own local workspaces a certain way may go against their particular way of working, and break their flow and make them less efficient.
3. Stuff that isn't in source control is half-baked code. If it's fully baked code that's ready for release, it should be in source control. Which comes back again to the main point....
4. "If it's not in source control, it doesn't exist."

One possible way to mitigate the issue of wanting to look at code on people's workstations is to foster a culture of regular checkins. I worked at a company once where - even though there was no official mandate to do so - it was seen a sort of point of pride to always have everything checked in for the weekend. In maintenance and release candidate phases, CR items were deliberately very fine grained to allow for small, cleanly visible changes, and regular checkins to keep track of them.

Also, having everything checked in before you go on vacation was mandatory.

TL;DR version: Rifling through people's workstations is bad form. Rather than trying to foster a culture of making it easy to go through people's workstations to find what we want, it's better practice to foster a culture of sensible source control use and regular checkins. Possibly even hyper-regular checkins, and fine-grained tasks when in critical phases of projects.

Answer 2

Rather than enforcing a standard for how your developers organize their workstations, enforce a standard where all work is checked in at the end of each day. The check-ins could be to branches if still incomplete.

This way no one should ever need to access another developer's workstation.

I would imagine that this policy would meet with some opposition, but nothing compared to what I would expect if you enforced rules about the organization of ones workstation.

Answer 3

A few months back I was working on a rather large project and had to leave work abruptly as I found out I was being admitted to the hospital. I did not have time to check in my latest code for the project.

Luckily, it is convention here (though not "necessary") to store code in /var/www/ourdomain.com to mimic production. With such a logical, and easy to follow convention, it was easy for a co-worker to login to my machine and retrieve my latest changes.

I think some conventions are good. Though I agree with Bobby when he says

"If it's not in source control, it doesn't exist."

Also, a useful addition to any programmers workspace could be a front-bay hot-swap SATA drive on which to store all source and development projects. This way, if such a problem does arise, an employee can retrieve new source changes to the project easily without the need to login to the developers workstation.

Answer 4

I'll tell you the truth I feel uneasy about the very idea that somebody is going to log in on to my machine and browse through my stuff. Granted, it's the company equipment and property, but it is simply a bad thing to do.

Last time I left for a weekend the guys reconfigured the servers with the database and source control and for some reason felt it necessary to log in on to my machine and reconfigure the system for the new setting.

Too bad they had no idea what they were doing and they erased a prototype I had been working on for the last two months.

It wouldn't have happened if the proper communication was in place. That's what you need as well. Get to that developer and find out the state of the things. Even better, ask people for a report before they go on leave so that you take an informed decision whether you need anything of them or not.

But don't mess with people's workstations.

P.S. We do have a convention for a directory structure but it's main existence reason is a mix of history/configuration - put it anywhere else and it won't compile.

Answer 5

The first part of your question identify communication problems within your team clearly. Have you tried daily standups?

I agree with you when you say that standards will probably lead to inefficiency if they are too strict. Standards must be defined by the team, involving everybody.

In your case, I would wait few days after the concerned developer return at work. Then organize a meeting to talk about those standards.

In order to avoid any psychological blocks and resistance, don't name persons or specific things you saw. Keep it general, the goal here is to get input from everybody, including the developer you think should improve his way of working. The guy may consider your organization as a mess too.

During the meeting present the problem and ask clearly how the team could improve the situation.

The (whole) team decide what to do.

Answer 6

That user was probably suffering from a lack of proper tools. In particular, the use of a distributed version control system would have eliminated for him the need to have different directories of code in different states. He could have kept that all in branches and been much happier.

To the main point, though, no I don't want standards enforced on me on how I organize my own workstation. I'm currently pushing back about my department standardizing on an IDE (my boss REALLY wants us all in Eclipse because it's what he uses and knows well, even though IMO it's not the best tool for my job).

Let developers do whatever makes them comfortable. A comfortable developer is more productive than an uncomfortable one. And if somebody's NOT productive, and you suspect they're fumbling around locally with the tools, it's an opportunity for training, not a Good Time to Make New Rules.

Answer 7

At my old place of work, we had a system whereby each task in our bugtracking had it's own branch in source control. It was understood that most of the time, one bug/task is squashed by one developer so broken code was allowed to be checked into source control.

Once the code was in a state that it was stable on the development branch, a rebase was done dragging code in from the branch you were going to integrate with. Once you'd tested that merge, it would simply be a case of committing the code to the integration branch - it would require no merging as you'd already done the merge on your branch.

This way, you save the problem of developers worrying about committing code that's broken - and you can begin to apply social policy of making it super acceptable to check code in before you leave the office at night - nice and safe.

Answer 8

In this particular situation call the person at home, make it very clear that you are not doubting that he is ill but you need to have somebody else continue his work, and ask where the latest stuff is and in what state.

Then you need to consider what to do from here. If the problem is that people check in too seldom, consider using a distributed source control system that allows people to work in branches without disturbing one another.

If the problem is that you don't like developers having multiple workspaces on their machine, then get over it. Working style is individual and you should basically stay away from their systems as long as they work fine with the rules for the source repository. Personally I check out a new copy very frequently for different projects and only clean up once in a while.

If the problem is that you don't know what your developer is doing, the problem is political not technical, and you need to change your style of management. Please remember that developers are highly skilled personel who rarely like micromanagement and you have to delegate. Otherwise you will push the most skilled individuals away.

So, I would recommend encouraging a better way to work with the common source repository - say it is fine for people to work in branches, and let them commit frequently as long as they synchronize up their local copy to the master repository daily (as they will always do development work in a branch this will not influence others).

Answer 9

So how do you handle situations like this?

You can solve this problem with a source control system that supports personal unstable branches and by maintaining frequent commits. A commit does not have to come when an entire problem is solved. It should come whenever you benefit from source control. The end of the day is one of many points when a commit should happen so that you can see where your changes were made, back them up, and explain them to your future self or others.

Or do you ask developers to adhere to standards in this area - use of specific directories, naming standards, notes on a wiki or whatever?

We have an immense environment configuration document that denotes conventions, but not a standard. Standards are for production code and environments. However many of our development tools are setup to support the conventions and most developers don't expend effort bucking the trend.