This is not what I have experienced, at least not in real world software with mediocre documentation. Usually the software encodes only the "how", but the important parts are "why" and what aspects of the original problem led to that design.
Good teams learn how to transfer and adapt in the next project. Starting with the software only, lots of that can only be reverse engineered.
That was something I picked up from one of the more experienced software devs when I started - in his code there were far fewer comments saying "This section does x and y", than there were comments saying "We are doing x and y because ..."
