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...
Long answer: Run real fast.
You were hired to be the scapegoat.
document whats broken (known known), request budget to fix
document what isn't broken, but could break (known unknown), request budget to maintain
request budget to address change requests (known unknowns)
request agreement to address incidents (unknown unknowns)
You're very lucky: The person who created the project is with the company.
Question him/her!
Get an outline of how the project is supposed to work. Get broad ideas about each class, and the key functions in each class.
Then, write tests. Write more tests. Write even more tests.
In other words, you need to make sure that there's a second layer that 'knows' what the code is supposed to do and can ensure that it's still doing that.
Only after you have the tests complete should you move to fixing bugs or adding features.
First thing to do is complete a real analysis of the code and report to management with an estimate to re-write complete sections of the code. Go into it realistically and tell them up front what it will take to correct things, and why. I have been in this situation several times in my career and that has always been the best approach. There is no need to "knock" the other guys code (be positive, never the mudslinger) and done correctly, would look more like you have some fresh ideas that may not have been designed into it originally. Eother way, management wants to know what to expect and having realistic expectations as soon as possible will save everyones face in the loing term. If they feel your out of line, well, then it's time to look at all those other jobs your contemplating.
"Computers are a lot like Air Conditioners" "They both work great until you start opening Windows"
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.
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
It seems the OP is actually asking about the ObamaCare web site.
The new programmer, in this situation, may very well be seized by the impulse to throw that old turd out and rewrite it, but a turd in the hand is worth two in the bush. Replacing the application wholesale usually leads to an expensive boondoggle that has all the bugs that the old program has already fixed and delivers a fraction of the original functionality. You hear stories about this all the time.
That doesn't mean you can't improve the design as you're adding new features or fixing bugs. Especially once you start to understand how the program works. You can isolate it into a test environment (because most of the time they're just building and deploying directly to production,) push the thing up to a version control server if they don't already do that, improve the build and deploy process and improve the design of the code in ever increasing scope until that turd has a really nice polish on it.
Or, you know, not. It's really up to you.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
http://beta.slashdot.org/
This space for rent.
I think that's the first thing you need to do before deciding how to react.
Did the author decide he'd created an unmanageable hack and push management to pull in a contractor to either clean up the project or simply suffer through trying to maintain it, so he could get back to focusing on his other work?
Did management rush the author to get something "usable" out the door so they could put him on another project, and you're just the mop-up crew?
It's very likely one of those two things. You could respond to either of them by simply "run, forrest, run!", or you could roll up your sleeves and get to work. If you choose to take it on, your approach will depend on why you are there. First off, trashing on the author won't get you anywhere with anyone, don't even consider it. The author may realize he made a mess, management may not. But right now the author is your best ally. Don't burn that bridge by running to management and telling them the reason it's going to be expensive to fix is because the author created a mess.
That being said, document everything, in case it comes back to bite you. You don't need to share that documentation with anyone unless necessary. It's your safety net in case the excrement strikes the oscillating unit and the author tries to blame the problems on you.
Have a private chat with the author and find out which of the two above is the reason you're there. You'll notice that in either case, he's probably very happy to have you taking over, and you should be able to easily leverage that to get his cooperation. That will make your job monumentally easier. Projects by good authors that get into this state are usually the result of inadequate planning, or a late change in requirements. The author probably had a fairly-well fleshed out plan that went south at some point, and that plan is probably not very clear to you right now. Ask about that plan, find out where the code was meant to go, why it didn't end up going there, and mosts importantly what problems did that create and how did he work around them. Those work-arounds are what's causing your grief. Knowing what they are is half the battle (that's why stuff broke when you edited), knowing why they were necessary is the other half. (THAT'S why other unrelated stuff started breaking) Get this information from the author.
At that point, you can take a very well-informed look at the project and decide if it's worth your hassle to take on. Then either take it or leave it. If you decide to bail, you can look back on your documentation and decide how much of that is necessary to justify your decision and get some compensation for your trouble. If you do decide to take on the project, discuss the issue again with the author and get their input on how to explain the maintenance costs. Even if it has to come down to "this is going to be expensive because Bob created a mess", giving him a chance to have some input on how this is addressed will help keep him in your corner down the road. If he's anywhere near reasonable, he'll understand that he's going to have to accept some of the responsibility for what he started.
I work for the Department of Redundancy Department.
Excellent points r.e. "real assessment"
Also, things to consider: without knowing these, all advice offered here is less focused (and hence less useful) than it could be otherwise.
1) Who are the stakeholder(s)?
1.B) What is the stakeholders' definition of "success"?
2) What is your budget - fixed bid, time & material? (if the later, do you have a max budget or is it open ended)
3) What is an ideal outcome for you personally?
4) What is the least-sucky outcome for you personally that you would accept?
Some general advice (this applies to the excellent "real assessment" mentioned above): Whatever bad news you have for your client, the SOONER you deliver it the BETTER OFF everyone will be, including yourself. If you go heads-down a pile of crap code for 6 months and end up stuck and unable to deliver anything useful enough and timely enough to satisfy the stakeholders then things will NOT end well for you.
Also... what you think may be "bad news" may be something the client is aware of and fully expects, so don't sweat it too much. Talk to them and do some brainstorming about how to rearrange things to make success possible.
Your description sounds exactly like the only thing that I've ever been paid to do in my entire career. My job is to fix broken things and make them work. It sounds like that's your job, too. If everything were working perfectly, they wouldn't have needed to hire you in the first place. If fixing the project is beyond your skill, then perhaps moving on to a different employer is a good idea.
-Glires