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.

  • 8
    -1 for going Gestapo on a programmer's command center.
    – Geoffrey
    Jan 11, 2011 at 13:10
  • 21
    Wait, how did the second developer know the first developer's password?
    – TheLQ
    Jan 11, 2011 at 13:11
  • 12
    +1 for an excellent question. "Going gestapo" is not relevant in a corporate environment in my opinion since developers are working for the corporation and therefore relinquish access rights to their local machines. You want privacy, use your own hardware.
    – Gary
    Jan 11, 2011 at 13:34
  • 6
    If the developer could be contacted for the password, why didn't you just ask him which version was the current one?
    – Ben L
    Jan 11, 2011 at 14:34
  • 2
    @Gary: what? no, that’s complete (and very dangerous) nonsense. It’s a looong shot (both logically and legally) from working for a company to giving up personal rights for privacy. I wouldn’t call Jon’s action “going Gestapo” (even before he explained it more) but companies do go Gestapo sometimes and this is something that needs to be prevented and fought on all levels. I can only speak for Germany but here you do have certain privacy rights even when working on company-owned hardware. Jan 11, 2011 at 15:16

9 Answers 9


"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.

  • 12
    +1: Someone's out sick, messing around on their workstation is probably going to be more cost than value. One person's already gone. Now another is wasting time trying to figure out what's going on. Huge management nightmare for no value. Until it's in source control, it never existed.
    – S.Lott
    Jan 11, 2011 at 12:17
  • 1
    If he's off for the day? Yup, for the rest of the week? Maybe, for a month? No chance. This is one of those nasty "shades of grey" problems... we're back, again, to commit early, commit often - so the patterns don't necessarily need to be workstations but use of version control, but clearly its something worth thinking about.
    – Murph
    Jan 11, 2011 at 12:48
  • 3
    @Murph: If the changes are committed somewhere every X days, the maximum amount of work that can be misplaced is X days' worth, and that's true no matter how long the developer is unavoidably out. The proper thing to do is to have policies about checking in frequently enough so that the amount of lost work is within acceptable bounds. Jan 11, 2011 at 16:04
  • 2
    @Guzica The mention of "If it's fully baked code that's ready for release, it should be in source control." While true it should also be in source control when a stopping point is reached. Taking the approach you mention is precisely why a developer hoards their code on a local machine until it is "fully baked". Jan 11, 2011 at 17:01
  • 2
    Legalities aside, it's quite disrespectful to open up a machine to rummage through code. Bad management (not requiring regular commits) does not ease the disrespect. A partial solution is to store working copies on a network drive that can be accessed in emergencies. Jan 11, 2011 at 18:53

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.

  • 2
    @Jon Hopkins: "Releasable" is easier to manage than "Stable". Releasable includes stable as well as product owner is ready for it. And you'll do a lot of branch-to-release processing. Branch-to-stable has too much potential for subjectivity and "worked for me" discussion.
    – S.Lott
    Jan 11, 2011 at 12:15
  • 2
    -1 I disagree with this without a huge amount of qualification, checkins should occur at a logical point - and not arbitrarily at the end of the day. (Yes, we should aim not to leave 'til we've got to a sensible breakpoint but life doesn't always cooperate.) Backups should be distinct. And we all need to be a bit less precious about access to our boxes (not changes to, access to)
    – Murph
    Jan 11, 2011 at 13:10
  • 4
    @Murph Checkins into 'trunk' or mainline (whatever you want to call it) should only occur as you describe. However, there is nothing wrong with having developers 'save their work at the end of the day' by committing to a personal branch (although this is a lot easier with git or mercurial than with SVN). And compared to enforcing guidelines on how developers workstations are configured (which was our starting point) it is a downright sane solution.
    – Kris
    Jan 11, 2011 at 15:04
  • 2
    @Gary Rowe How doesn't it? You check into a branch. Takes all of two seconds and no need to worry about breaking the build (which would not be based on a personal branch).
    – Kris
    Jan 11, 2011 at 15:06
  • 2
    Daily "unstable" checkins and all kinds of branches and such, with associated history, may quickly make a mess of your SCM. However, I am a fan of a feature of TFS called "Shelvesets" which is essentially the same thing - it holds file(s) in a named set (with an appropriate comment), which could be shared among team members. You could conceivably put everything you are working on into a shelveset every day, without clogging up source control. Jan 11, 2011 at 16:37

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.

  • "... it doesn't exist". To others, that is.
    – user1249
    Jan 11, 2011 at 17:10

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.

  • 4
    @Murph: Going "off sick" accompanied by an urgent need to get something from his system is a really rare situation. May not be worth any standardization efforts.
    – user8685
    Jan 11, 2011 at 11:11
  • 1
    Besides if the guy hasn't checked it in, then it is not ready. Why risk with the code in an unknown state? What if there is something tiny he was meant to get to the next day, you don't notice it, believe you've completed it, put it in production and then boom!
    – user8685
    Jan 11, 2011 at 11:15
  • 1
    I can understand why someone should read your mail and shouldn't change anything on your machine but how about if it was standard to share (read-only) your code directories? That would get round most of what I perceive as your objections but still allow people the possibility of getting to your work in an emergency. Jan 11, 2011 at 11:43
  • 3
    No backup on that prototype?
    – JeffO
    Jan 11, 2011 at 13:33
  • 2
    @Developer art, why did you not work in a branch of the versioning system?
    – user1249
    Jan 11, 2011 at 16:57

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.


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.

  • 1
    How would that help? The question would still exist, we'd just be talking about which branch within his local DVCS repository rather than which workspace. Jan 11, 2011 at 13:34
  • Don't assume its the tools - its also appreciation of how best to make use of the tools that can be lacking. What's obvious to some needs to be shown to others. The anti-pattern of lots copies of the source tree is one I've seen a few times. Yes, DVCS can help - but in this context we'd still have an issue with identifying the right branch and - if we want to go further - with making those Work In Progress branches available. @Jon the local DVCS should automagically push to that user's "backup" of their repository. At the very least if moves the problem off their box.
    – Murph
    Jan 11, 2011 at 13:37
  • @Jon -- I guess the point is, his diverse branches would be in something that would have merging functionality built into it, rather than just scattered directories of diverging files. Plus, getting him up and going on the DVCS would have been a training opportunity.
    – Dan Ray
    Jan 11, 2011 at 13:38
  • 1
    @Dan - But some of those branches are dead ends - proofs of concept, things with assorted debug code in that you don't want merged in, older versions. The fact you have merge functionality doesn't help when you don't know what you should be merging. Jan 11, 2011 at 13:44
  • @Jon - I guess that's true. Maybe there's just no recovering from somebody really committed to making a mess.
    – Dan Ray
    Jan 11, 2011 at 14:06

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.


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).

  • 1
    I did specifically say in the question to assume that the person can't be contacted. Jan 11, 2011 at 17:08
  • @Jon, in that case consider his unfinished work lost, assign it to another programmer, and then start pondering on why this happened in the first place.
    – user1249
    Jan 11, 2011 at 17:19
  • There's a logical inconsistency in there - "you don't know what your developer is doing" vs "you have to delegate" which means you know what he's doing but possibly not how - which in turn is why you need to get at the code... (yes, communication may help to sort this out but if you trust your devs to solve a problem and its a smallish problem - for a given dev - then "go fix this, bye!" may be as much management as is needed).
    – Murph
    Jan 11, 2011 at 17:27
  • @Murph, then enforce a rule of "commit often - in a branch" and push to central at least daily.
    – user1249
    Jan 11, 2011 at 19:16

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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