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.
Best Answer
"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:
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.