Slashdot Mirror
Ask Slashdot: What Do You Do If You're Given a Broken Project?
X10 writes "Suppose you're assigned to a project that someone else has created. It's an app, you'll work on it alone. You think 'how hard can it be,' you don't check out the source code before you accept the assignment. But then, it turns out the code is not robust. You create a small new feature, and the app breaks down in unexpected ways. You fix a bug, and new bugs pop up all over the place. The person who worked on the project before you is well respected in the company, and you are 'just a contractor,' hired a few months ago. The easy way out is to just quit, as there's plenty of jobs you can take. But that doesn't feel right. What else can you do?"
http://en.wikipedia.org/wiki/D...
You were hired to be the scapegoat.
Talk to him. Plainly, just explain the issues you're having and what you're trying to get done to go over it with him. Ideally, get it in email form.
One of two things are possible here. He either did a quick "get it done" job to just get it over with really fast and move on...OR he potentially just has it setup using an approach you aren't familiar with. Even explain the issues to your boss if need be so that your boss can help to get you some of his time to go over this stuff.
There is good code and bad code...but there's also "different" code. I've seen many a developer absolutely lose their minds because something wasn't done the way they wanted it to be done even though it was a perfectly valid approach. That might not be the case in this situation, but as developers we can get a little set in our ways and a little OCD sometimes.
Keeping "respected guy" at a distance isn't going to help anybody. Absolute worst case, explain to your boss that in order to avoid breaking anything else you need him to at the very least, document how he did things. More than likely you'll ask respected guy for help and he'll have a look and either explain things or apologize. If things are tied together enough that when you change one thing, something else breaks then they are probably tied together for a reason. It would be odd for them not to be.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
http://beta.slashdot.org/
This space for rent.
I think this is good advice, and having been on the other side of this issue, I think it's important to note the worst case scenario may not always occur here. I had to write an incredibly large application on an absolutely impossible deadline, in a programming language I wasn't incredibly comfortable with using, and there weren't any "objections" allowed, given the setting. I was young, I wrote it, and accepted what I was doing was crap, but I had to cut every corner imaginable just to get it done. Fast forward ten years, the company wants to sell the application to others, because, while it's poorly done (IMO), it does everything desired and people are still looking for that type of software in our industry. Someone else was hired to review/rewrite/refactor. The guy who was hired eventually came to me expecting he was going to be the fall guy (hell, he may even have posted here), and when he brought his (incredibly well done) analysis of what was wrong, I told him he was absolutely right, he shouldn't be afraid to say it openly, and I'd be happy to help him understand the "guts" of what was trying to be accomplished.
Long story short, while I guess in most times it really is a political slugfest about to happen, sometimes it's that the person who did the application, rock star or not, was put in an untenable situation and did the best they could with it and is well aware it is garbage, spaghetti code that went through 100+ changes of scope due to poor project managers. It doesn't mean that person necessarily is going to hate you for it.