The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
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" ?
Unless this developer has given you indications of being territorial about this project or being generally incredibly proud/arrogant/know-it-all, you don't need to worry about it.
The code I wrote 8 years ago sucked. The code I wrote last week will suck if I look at it in 8 weeks, let alone 8 years.
Let the senior drive the conversation/review. Don't poke the bear and start explaining in detail why you used this or that technical detail instead of what was there before. If you're asked why, you can explain, but do your best not to denigrate what was there before.
The senior will likely take a look at his old code, shudder, and then properly point out all the mistakes, bugs, missed edge cases, etc. that are inevitably in there (because writing code is really, really, really hard to get right).
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?
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.
OK you were asked to switch the software to another language. That alone is something you can use to justify the design change. Talk about why this design is right for the new language (ignoring if it was right also for the old language) and why you made the choices you made and how the design concept was approved before you did it. This is a face-saving move. You did this because the new language made it the right choice, not because his code was bad.
Talk about how you tested to make sure the new software preserved the requirements built into the old software and if they differ, show that you made those changes based on new requirements as part of the project. Ask him specifically if he can think of anything you missed along the way in terms of functionality. This is appealing to his technical expertise on the current system and shows respect for his professional ability.
If it is applicable, reference some problems you were specifically asked to resolve and point to these as part of why you chose the design you did. Sometimes there are problems when we do an original design that don't show up until later and those can entirely justify changing how things are done.
Depending on the difficulty of the project, acknowledge how much his original code helped you in designing the new language version and made it easier than starting from scratch. Be careful of laying it on too thick here, but acknowledging that his version was helpful can disarm him.
On your own part remember that 8 years is a long time in software development and you probably did some things now that were not available to him then. If you used some of those newer things and use them as a partial justification for the different design, it will help as well.
Most importantly, treat him with respect and acknowledge his in depth knowledge of how the system is supposed to work. If you don't act as if you think his work was garbage, you will find it easier to work with him on this.
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.
In addition to the other great answers here, you need to keep in mind all the variables (no pun intended) that go into the creation of a solution. The original developer may have written awesome, innovative code for 8 years ago. (Keep in mind that ASP.NET MVC was just releasing version 1 8 years ago https://en.wikipedia.org/wiki/ASP.NET_MVC, and even then there were pieces of it that needed work before it was widely usable.) The Onion Architecture paradigm was first posted on Jeffrey Palermo's blog in July of 2008 (I'm a fan of this.)
Your code today may only be mediocre. It could still be better than the old code, but that's because we have new technologies, up to 5 newer versions of MVC to choose from, third-party support/extensions for MVC via Nuget, etc.
You also have a working product, so you could potentially take as much time as you want to rewrite it; the business doesn't have to switch to your version immediately. What was the previous developer's timeline? Were they in a crunch to get things working ASAP in order to support a start-up or a new product?
It doesn't matter how good you think you are. What matters is how well you can work with others. If the other developer reviews your code and says things like, "I like this! It's better than what I did," then you can pat yourself on the back. To just assume your code is better will make you enemies.
The best approach is to ask the other developer to look at your code and the finished product. "I was asked to do x. How does this look?" is a decent enough question to invite the developer to look at the new code.
If a rewrite was truly in order, sharing knowledge during development is another good way to incrementally show new features to other developers: "Hey! Check out this cool thing I found!", or, "I didn't know about this [language, framework, etc.] feature! Want to see this?". Going the entire development period without feedback is most likely a problem, since potential issues could have been found before they were tightly wound throughout the app.
Another way to prevent issues during development, and incorporate the previous developer, is to ask about things that seem odd. Not all code is commented, and there are likely reasons behind the way things are built and/or working the way they are after 8 years of development and maintenance. You could potentially lose functionality or introduce bugs into the business logic if you are asking these "Why?" questions, unless you had a new backlog of business requirements to work from.
Before the review, make sure that the original coder knows that the complete redesign was performed to make the code base more flexible and extensible for new requirements.
If you can point out a few examples of requirements that would have been relatively complex prior to the rewrite, but are trivial now, it demonstrates that the rewrite was made for objective reasons.
At times people can resent 'their' code being rewritten - so make sure he understands the reasons beforehand.
Was this person a senior developer when they write the code 8 years ago?
Probably not - so the code wasn't 'senior developer quality'.
Unless they are still writing code the same way they did back then, you should have little concern in showing how you've improved on their work using current best practices.
Ask for a review of your code tweaks. Indicate that you feel it improves upon the original but wanted to be sure and get more feedback on if you are going in the right direction. The correctness will speak for itself if that is the case and it will give respect to the other person as you are seeking their opinion on it.
The only trouble is that I changed the organization of the software from bottom to top.
Your other problem is apparently that you didn't discuss or obtain permission to do what you did, before you did it: because he's not expecting how much you've changed.
If I were senior developer reviewing a rewrite, one of my worries might be, "How can I tell whether the rewrite broke existing functionality?"
Do you have an answer to that question, e.g. are there defined system tests or acceptance tests, which the new version of the software is still passing?
If so then it's easier to review the new version on its merits, based on its superficial appearance and structure: e.g. to assess whether it's more modern, more maintainable, etc.
If not then you need to determine via code-inspection whether functionality has changed; which might be difficult if it's a complete rewrite.
The first step is stop seeing your work this way: you did not receive the task to rewrite bad code but to port it to a new language. That's what you did and that's it. Different choices are to be expected when porting, moreover if the codebase is old, so if nobody goes down that slope you shouldn't worry about someone seeing a judgement in your changes.
As a side note maybe you are not fully aware of all the reasoning behind the choices made 8 years ago that led to that code: maybe that was the best they could do at that time with the tools, constraints, specifications and so on.
If it was my 8 year old code that you rewrote in a new language, while changing the structure completely: First, I know for a fact that the code that I wrote in 2009 should be rewritten in a different language if the company wants to continue developing it in the long term. And I know that it needs significant changes, because I knew in 2009 that parts of it could be expected to stop working soon.
My question would be: How much responsibility am I expected to have towards that code? If you changed the language and the structure at the same time, that's a brave move. And you are on your own. You want to show me your work? Actually, I'm not interested. It's your code. If it works well, be proud of it. If it doesn't work, your problem. I'm not going to help you.
What I'm saying is that you are much too late. You might have come to me before you rewrote it. I could have told you what parts of the code are good, what parts are bad because I never had time to do them well, and which parts are ugly because they contain sometimes bizarre workarounds that will make the app stop working if you "fix" the ugly bits.
You worry about sounding like "your previous work sucked so much, that's why mine is so different". I don't know if that senior developer was an intern eight years ago, or was experienced back then. In the former case, he might think "your code is different, and it sucks just as much or even more". If he was senior back then, he might come up with a list of things you've broken.
