Ask Slashdot: What Do You Do If You're Given a Broken Project? 308
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?"
Enjoy your Death March (Score:5, Informative)
http://en.wikipedia.org/wiki/D... [wikipedia.org]
You were not hired to finish the project (Score:5, Informative)
You were hired to be the scapegoat.
Suck it up (Score:5, Informative)
It's a sad thing. When someone who is well respected basically gave birth to a turd, and you need to clean it up, this is not ideal, but definitely the nature of the business... the business will become acutely aware of how crappy this app is in short order without your input.
Advice: keep your nose clean. Don't complain about this person's code, but explain how the condition of the code will cost your time and energy to fix the problems as you dial in new changes. When they question you on it, tactfully explain that design decisions in the app are not entirely flexible, and changes may cascade into other areas that need to be fixed.
If the "well respected guy" is still there (Score:5, Informative)
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.
Like Any Other Project (Score:4, Informative)
Not many details to go on here, but I would handle this like any other project. Triage the problems and requirements, then work with the system owner to work them off. Be respectful to the developers who came before you. They may have been handed the same lousy situation, and done their best to work within the boundaries provided. If you are nice, they should be willing to help you understand the history of the app. They may have sacrificed robustness to accommodate some other requirement when they first wrote the system. Since you seem to have other options, then you don't have a lot to loose, and perhaps much to gain if you can bring this system under control.
Step one, do not criticize. Step 2, document. (Score:4, Informative)
As you have said that the person who worked on the project before is well liked and respected within the company, while you are the new guy with no good will or social capital built up in the organisation, the last thing you should be doing is forming any kind of criticism of the code or the person who wrote it.
However, if the project is truly "Broken", then the person who worked on it before will not be the untouchable God type. He may be the asshole programmer from Hell who purposefully wrote code that could not be maintained by anyone else, in which case you are his patsy and you are probably on a losing bet, because he is just waiting in the wings to swoop in, pull an all-nighter bashing away at the keyboard to rescue the company from the incompetence of the new guy, all for a measly 50% pay rise... I have seen it happen to a few contractors and it is not pretty.
The "obvious" solution, of course, is to quit and find another gig. However, the next place (or the one after that) will probably have a similar scenario, so the best approach would be to start learning to tackle the problem on this project.
That means that step 1 is to look at where YOU went wrong. By that, I mean that either your initial code analysis was incomplete (you did not check out the code before taking the assignment, or maybe you had no opportunity to check it out), or you started coding before understanding the existing structure (or lack of). Yes, you are under pressure to add value, contribute, justify your existence, and so on... but that will be doubly true next month. If you cannot make the argument in the first week/month that you need to review the existing code before making changes and adding features, then you are not going to be able to make that argument at any point. It takes a particular kind of coder to write updates to existing code without first understanding what the existing stuff does, and that type is rare, especially when dealing with an un-maintainable bird's nest of code.
If the code is already documented, verify that the documentation is accurate. If it is not already documented, then document it. The code may need to be re-factored before you can make any meaningful contribution, but right at the beginning of the project is the only possible window you will have for that kind of analysis.
If your response at this point is "I do not have time to document the code", then my advice would be to leave with your sanity and most of your reputation intact. You have already seen that coding hot, without any insight into what you are working with, causes unexpected and unexplained problems.
I know which broken project we are talking about.. (Score:5, Informative)
http://beta.slashdot.org/ [slashdot.org]
Re:Make a real assesment (Score:4, Informative)
Re:Short answer: Run. (Score:5, Informative)
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.
Re:Write tests. Write more tests. (Score:4, Informative)
Too bad the poster here was AC and didn't get modded up, because he is absolutely, positively right. All the people here who talk about code analysis, etc., are completely missing the point. Simply ask, publicly, for the test cases showing a positive path, and the test results. If they can't be provided, go back to management with the statement, "I don't understand why, but I'm not getting the same results as the previous engineering team did. Before I add any features or fix any bugs, we need to baseline what works and what doesn't.
I inherited a project like this in exactly the same circumstances. It was a dangerous time for me at the company, and the previous engineering lead did make some questionable accusations, but by keeping it non-confrontational he basically ignored me and went back to what he was doing. Management eventually saw that I was dedicated to getting things working so long as they let me do what needed to be done, out of their own self-interest.
I give a lot of credit to my product manager, who helped me navigate the political waters on that one (which included being called an incompetent liar to my face by the previous engineering lead). It worked out great for me in the long run.