> I've never seen anyone dig through VCS history to gain a better understanding of code.

One of my favourite interview questions:

    A bug is found where given a specific series of user
    interactions an error is raised. You search for this error
    in code and you find that the error is raised in a very
    old module which was written in a different style from
    the main codebase by a developer who has long since left
    the company. From a quick look around you see that this
    code is very complex, and probably quite important. It's
    obvious that it will take quite a bit of time to 
    understand what's going on simply by just reading the
    code in the module where this error is raised.

    Your job is to fix the bug. How do you approach this
    problem?

At my company digging through VCS (and our ticketing system) in order to gain a better understanding of code is a very common.

Edit:

I think if you're leaving commented out code for history's sake, you're Doing It Wrong. I disagree with the GP's idealism as much as you do, however. My beef with it is that if you're checking in commented code, you're obviously not reviewing your own diffs. It means you're likely to commit minor changes which were made for debugging purposes.

    // comment this, just to get this stupid module out of my way.
    //ensureNobodyDies();

Ticketing system sure. If you have the full history you'd get the original requirements hopefully, and revisions or issues along the way.

VCS. Maybe it's just a Web vs Other development thing. The history of an Action in Rails is going to be someone using mass-assignment unsafely. Or a dozen stylistic tweaks. Or implementing a pattern. Or removing it.

It's about the worst possible way I can imagine to attempt to understand requirements.

What I do find helpful is "git blame", and just talking to the person who implemented it. And if they aren't available, then hopefully someone who was there at the time, and involved with the feature, is. At least I have a time-frame.

As a last resort, if no one has any clue what's going on? Scrolling through VCS diffs would be an act of desperation perhaps. But I'd much rather look for tests. Automated or a Manual Test Plan. A Specification. Or just use common sense.

At the end of the day it's most likely that I'm tasked with this issue because the original implementation was a scheduling compromise, or the original developer just couldn't think of how to make it simple, so they made it complex.

Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-) Then it's absolutely the only sane way to implement it and you just need to try harder to understand. Duh.

> Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-)

I appreciate your humility, and I largely agree with your approach. You'd probably do quite well in my interview.

With respect to actual complexity rarely being justified, I'm presently a team lead for a system which involves fairly precise modeling of some very piecewise real world processes under very tight performance constraints. There are so many things we just can't generalize, either because there's no clean abstraction, or because abstraction comes with too much inefficiency. We try to keep our processes from smelling too much like old stale spaghetti, but unfortunately some things are just simply complex, and sometimes in the face of such complexity the most elegant and/or performant solution can make purists cringe.

> I've never seen anyone dig through VCS history to gain a better understanding of code.

I'm actually going through the ancient CVS history of Mozilla Firefox in order to learn about a relatively poorly understood piece of code that's still in there to this day:

http://mikeconley.ca/blog/2014/07/07/docshell-in-a-nutshell-...

and

http://mikeconley.ca/blog/2014/08/10/docshell-in-a-nutshell-...

You never wonder why particular lines of code happen to do exactly the things they do, in the exact order they do them, when your intuition would tell you that it would be a third as many lines if only the code called this or that utility function, or that it obviously doesn't handle the particular corner case of a new bug report? You must work on unusually well commented code bases then; I wouldn't get anything done without git log -p... at a minimum you will quickly find out which generation of maintenance programmer added the odd code in question and what (if any) bug it was intended to fix, so you don't break that use-case. Well, unless you're out of luck and the first generation of them lost the first 5 years of SCM history, that is...

No. If the intent behind the source code you're actually looking at is not apparent, then realistically, looking at it's history is probably equally useless.

If there aren't tests or specifications to cover the code, I generally assume any bugs are because of a lack of understanding and proceed from there.

Scrolling backwards through history and looking at progressively more naive or prototypical implementations isn't going to tell me anything except the code was likely underspecified IME.

Comments are infrequent, but when I write them, they're usually to try to clarify particularly complex implementation detail. Not to communicate requirements. Comments aren't the ideal place for that IMO.

> I've never seen anyone dig through VCS history to gain a better understanding of code.

git bisect, git log, and git blame are all indispensable tools. To counter your anecdote, I use them all the time and see others do so.

There's really no reason to leave dead imports in a file.