>>If you create proper programming documentation (with an index) then there isn't this problem. Second, I tend to create classes for business objects. If I know what the business object is, finding the code will be there as well.
>>
>>One other point. By keeping the methods short and highly cohesive, once I've proven that it works as intended, I don't tend to spend a lot of time on it thereafter. So I really don't have that many situations where I'd be required to dig.
>
>I agree. However, I haven't seen anybody maintain proper programming documentation - indexed or not. ;)

Sadly, this is the case more often than not. If I had to guess why this is, I'd probably say that it's a case of mis-set priorities.

In a schedule crunch, it and possibly code reviews is seen as less important than getting the software out the door. The end result turns out to be "mining for code" and too much time spent on that when the next modification comes up.

OTOH, when done properly, even during a schedule crunch, these are things that help shorten the schedule. There's less redundancy and problems are caught sooner, while they cost less, rather than later.