views:

130

answers:

1

During grad school, I started a project to package a lot of research algorithms into a nice user interface (let's call this project ABCD). I did not have time to get very far, so my department hired someone to take what I did and expand it.

When I finished my degree, I agreed to stay on at the university for a contract position to tie up loose ends. I inherited development work on the expanded version of ABCD. A company that I am interested in working for is going to license ABCD from my advisor and get access to the code and everything related to it.

The problem: the person the school hired did a terrible job with ABCD. Fixing things in the code is almost suicidally-frustrating due to how tightly coupled and messy it is.

I am concerned that this company is going to look at the code and think that it accurately reflects MY coding skills. Although I inherited the development duties, I had other work to do and didn't have time to redesign the system.

How do I protect my reputation so that the company knows it wasn't my fault? The company has been dealing with my advisor and I and they are probably not aware that someone else worked on this before me.

They are not hiring anyone at the moment but I plan on eventually applying and I am afraid they will remember ABCD and think that I caused the screw up.

Any advice?

One option is to tell the company right now how bad things are. I don't want to do this as it might kill the deal for my advisor. The licensing deal is actually two parts: the GUI and the algorithms. The algorithms are well written and is what the company wants. The GUI is just something extra, so I don't want to let that part of the code spoil the whole deal.

EDIT: Some responses suggested that the code in ABCD might be average because a lot of professional code is bad. I've interned at 3 different software development jobs (a research institute, a medium-sized business and a well known software company) and I've never seen anything approaching this.

+1  A: 

As Oded and Carson63000 already commented, say nothing. You wouldn't believe how bad most professional developers code and you don't know whether the people at the other company write better code :-). When they talk to you about it, explain. But don't make it sound like you want to excuse yourself or that you think that the other coder is a total idiot (most of the time, that makes you look like an idiot instead). Instead, argue along the lines, "Yes, it's not as good as it could have been but good judgement comes from experience and experience come from bad judgement. I learned some leasons due to that code." Try to turn it into an advantage. Like by saying, "For example, in the code XYZ is done and I've seen that this creates problems A, B and C which is a good example of why to avoid XYZ." That is, show that you know why the code is bad. A coder that knows that normally also knows how to avoid these mistakes.

DarkDust
Thanks for the response. I think the worst case scenario is the company sees the code and blacklists me from even being interviewed so that I don't even have a chance to explain myself. I think that this particular code is well below average for industry standards. I have interned at 3 software development positions before (ranging from another research institute to a well known software company) and the code bases there were all much better to work with.
DrCarbon
If the company had a real interest in you then they would not black list you from interview without giving you a chance to explain. Very few companies have a list of people that they refuse to interview. That is just not worth the effort. If you are qualified for the job you will get an interview. At that point (if the code really is a problem) they will ask you about it. Also if the code has not been delivered yet, then make whatever corrections you can to it (non-breaking) in the time remaining before delivery.
Adkins