We used to do manual code reviews (i.e. no special tools) and this was the best method we found. Our development department doesn't have team foundation server, so I can't comment on that.
- All work is tied to a bug or an agile story that has a unique ID. When the work is checked in (or shelved, which is submission without actual check in), the description will always have this identifier.
- In a stand-up or over e-mail the reviewer would be notified that bug ### or story ### is ready for review.
- They do source control diff between new versions of the files and previous versions and copy/paste the output of diff into a word document. We have a code review word document template which is preset to use have 2 levels of headings: level 1-module, level 2-file name. It also defines formatting style for actual code (8pt Consolas). This step obviously was the biggest pain, but with Word template and Ctrl-A, Ctrl-C, Ctrl-V sequence, it's not that many clicks.
- Now that the document is in word, the reviewer can highlight the code in question and add comments using Word's review system.
- All documents are stored in a document repository and labeled with corresponding bug or story number.
- Once the document is done, the link to the repository is shared with original developer. Then we'd either have a code review meeting if changes were significant enough and need discussion, or just leave it up to original developer to go through comments on his own time.
After trying numerous manual methods, this was the one we found to have the least amount of overhead while allowing us to actually review every change.
However, our engineering team just rolled out Review Board and although I haven't used it that much yet, so far I'm loving what I have seen. It has all the flexibility of our word docs, but no more copy/pasting and manually fixing formatting. As an added bonus it keeps a permanent archive of all comments so you can go back years in time if you ever need to. Also it allows you do diffs of diffs, which is great when you want to do a review of a code review. This part we found to be very difficult with manual procedures because you can't see what was changed in response to first code review, instead you end up redoing the entire thing.
Although you did say you don't want to use tools, I'd strongly urge you to consider Review Board. It is open source and completely free. So you can roll it out for yourself and the 5 people you maybe working with. The rest of your company doesn't have to use this tool if they don't want to. And you don't need to worry about getting any purchase approvals.
== Update to comments from question: ==
On my team, we have people in NY, CT, TX, Poland and India. What makes things even more interesting is that extremely high percentage of the team doesn't know the product or technology all that well, so very few of us do most of the review. So yeah, senior devs are definitely busy. In the process I outlined, primary reviewer would do initial walk through the code independently on his own schedule. But afterwards we schedule a meeting and primary reviewer walks the coder through his comments. The meeting can have other reviewers, but they are considered secondary and are not obligated (but not discouraged from) to review every file or make comments.
I agree with others comments that having the final meeting in real-time, even if you have to use web conferencing is much better for knowledge transfer and for helping your new guys understand the code so that they'll start producing things that make your senior devs even busier. But again, that depends on the volume and type of comments, sometimes (very infrequently) comments are so minor that the meeting is skipped.
I can also relate to you when you say it's hard to roll out new tools. I work for a very large corporation and typically there's so many people involved that even outside of the fact that no purchases are ever approved, there are so many interests/agendas that nothing is ever agreed on. What's nice about Review Board is that you can skip all that and just start using with your small team and if you have to (if it really comes to that), you can host the web services on your own dev machine.
Having worked in places with code reviews and ones without, it has become one of my make-or-break issues in looking at new employment. The time you save avoiding emergencies because the problems didn't surface until you got to prod is much higher than the time you spend in code review. And that doesn't mention how much less stressful it is to find a problem in code review.
You could start small though if the team needs convincing. Since you would like your code reviewed, start there. Ask one or more of your colleagues to meet with you for an hour or so and go over some pieces of code that you feel you would like feedback on. If the feedback is largely negative, don't get defensive. Really take notes and consider making the suggested changes. But do it on something that you haven't sent to prod yet (or frankly you won't make the changes). You can even do it informally at your desk, just call someone over and say, "hey I'm not sure if I have the best solution here, what do you think?"
Another way to gradually get people to start to see the value of code review is to have a once-a-week session where everyone has to present a piece of code for review (or you rotate through each person but only one a week depending on the complexity of the kind of code that needs review). Bring doughnuts or bagels the first time! If people feel uncomfortable with telling someone in person or if you think people will be too defensive, have them email the boss and have him consolidate the comments so that the person being reviewed doesn't know who said what about the code. Frankly, I prefer to know in person who said what because my own assessment of their own coding abilities will help me decide how seriously I should take the criticism.
If you can't find someone to code review your work, sit down with yourself and try to explain the code and why you are doing what you are doing as if someone was there. I'm amazed at how often it is the person who built the code who found the problem in the course of explaining what the code was for. It also helps to sit down with your requirements document as a sort of checklist and make sure you aren't missing something required.
Best Answer
Double-check your motivation. If you think the code should be changed, you ought to be able to articulate some reason why you think it should be changed. And that reason should be more concrete than "I would have done it differently" or "it's ugly." If you can't point to some benefit that comes from your proposed change, then there's not much point in spending time (a.k.a. money) in changing it.
Every line of code in the project is a line that has to be maintained. Code should be as long as it needs to be to get the job done and be easily understood, and no longer. If you can shorten the code without sacrificing clarity, that's good. If you can do it while increasing clarity, that's much better.
Code is like concrete: it's more difficult to change after it's been sitting a while. Suggest your changes early if you can, so that the cost and risk of changes are both minimized.
Every change costs money. Rewriting code that works and is unlikely to need to be changed could be wasted effort. Focus your attention on the sections that are more subject to change or that are most important to the project.
Form follows function, and sometimes vice versa. If the code is messy, there's a stronger likelihood that it also contains bugs. Look for those bugs and criticize the flawed functionality rather than the aesthetic appeal of the code. Suggest improvements that make the code work better and make the operation of the code easier to verify.
Differentiate between design and implementation. An important class with a crappy interface can spread through a project like cancer. It will not only diminish the quality of the rest of the project, but also increase the difficulty of repairing the damage. On the other hand, a class with a well-designed interface but a lousy implementation shouldn't be a big deal. You can always re-implement the class for better performance or reliability. Or, if it works correctly and is fast enough, you can leave it alone and feel secure in the knowledge that its cruft is well encapsulated.
To summarize all the above points: Make sure that your proposed changes add value.