Question: My internship mission consists in recoding an entire software which was coded 8 years ago by a current senior developer of the company in another language.

The only trouble is that I changed the organization of the software from bottom to top. I switched to MVC instead of the "all in a file" pattern for example.

How do I show him my current work without sounding like "your previous work sucked so much, that's why mine is so different" ?

Answer: 
> 
> How do I show him my current work without sounding like "your previous work sucked so much, that's why mine is so different" ?
> 
> 
> 

**Call it version 2.0.** Or 3.0, or 4.0 or whatever. Just make sure that you've incremented the major version number, so that it's clear that this version is significantly different from its predecessor. That way, it's not so much like you're correcting flaws in the previous code as reworking the whole project to meet new goals.

**Make a list of improvements.** How is your version appreciably better than the previous version?

* Does it do the same job 3x faster?
* Does the code now include a suite of unit tests that ensure that it does the right thing?
* Does it have any major new features or capabilities?
* Have you made the code fully compliant with the company coding guidelines?
* Did you rewrite the code using the company's new favorite language?
* Is the code now modular, so that it's easier to test and easier to extend?

In short, focus on what's good about the new version, not what was not-so-good about the previous version. The longer you can make the list of substantial benefits, the harder it will be to argue that the changes aren't improvements. Avoid listing minor changes like bug fixes, though -- you could probably have made those in the existing code without a major rewrite, so minor things will undermine your argument.

**Be prepared for some criticism.** Even though the code was written 8 years ago, the original author is likely still one of the company's subject matter experts on this topic, and he/she may notice some details that others haven't. Accept the criticism in a positive spirit. Take notes so that you'll remember to address all the issues that are raised during the discussion.

**Be prepared for any reaction.** Chances are that the original author will be glad that this old project has been rewritten and will no longer be something they have to answer questions about. Or, they might feel somewhat attached to one of their early projects and sad to see it fall by the wayside. Just be open and honest, answer questions as best you can, listen to what they tell you, and don't take negative comments too personally.
When discussing your changes, avoid any use of "your old way" or "your old code". Once you join the development team, think of it as becoming "our code". 

Every developer knows that, given a few years, a new framework, development practice etc. could come along to do the work of a piece of code cleaner and faster. Whether it comes from an intern or a grizzled programming veteran, your senior developer colleague should have an open mind to examine your work fairly, so long as you are not sounding as if you are singling him/her out, or refusing to acknowledge criticism of your own work.