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?"

Comments

Enjoy your Death March

[pegr]

http://en.wikipedia.org/wiki/D...

Re:Enjoy your Death March

[0p7imu5_P2im3]

It's not that bad. Results are more important than intraoffice politics, if your superiors enjoy making money.

I have been in this specific situation. In my case, the ultimate answer was to rewrite the portion of the program that was worst, mostly from scratch. We had some proprietary libraries for which we had obtained the source code. Going through said source showed that the flaws (in this case, performance drag) were well entrenched, so I decided it would be necessary to write our own code from scratch to replace it. There were no political ramifications because we no longer had a business relationship with the original company, as it had gone bankrupt, and the original code was now owned by our customer. It was on my head to succeed, and succeed I did. The performance of our software went well into the useful range and I had impressed my superiors immensely. Not only that, but about two weeks later, the other customer of our software had canceled their project, so this project that I had just brought to fruition was now the only project using our software. I saved 20+ jobs and was now in charge of our group's only project. I was a hero.

That's when politics begin to matter. Another group in the company had lost all it's customers at the same time as our group lost our other customer. That group's manager needed a project at which to work, so after arranging a public shaming of my group's manager and taking over my group, he had me moved to the basement in another building... literally... He had to replace me with 3 managers and 2 programmers and 4 operators, but then, he was able to charge the customer for 9 employees' time instead of just 1 employee's time. Now he looked like the hero and I was looking for another job. If not for charging time spent to the customer, he probably would have lost that fight.

The moral of the story is: Do your absolute best and, if money is more important in your company than politics, you will be rewarded.

Re:Enjoy your Death March

[Anonymous Coward]

So you were demoted to a basement position and someone else, who had no part in the software you wrote, reaped the benefits and became the company hero for your work. How exactly were you rewarded?

You were not hired to finish the project

[EmagGeek]

You were hired to be the scapegoat.

apologies to rumsfeld

[Anonymous Coward]

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)

Write tests. Write more tests.

[Anonymous Coward]

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.

Make a real assesment

[gearloos]

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.

If the "well respected guy" is still there

[MillerHighLife21]

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.

Nice cloak post

[andyring]

It seems the OP is actually asking about the ObamaCare web site.

All Programs Are Like That

[Greyfox]

In 20+ years in the industry I haven't seen a single well-designed piece of code. The problems are twofold; the project itself most likely evolved out of a need. Frequently they start out small in scope, perform tasks that nothing else does better than anything else the company had, and grew out of necessity. They weren't so much designed as taped together based on needs that were not clearly enumerated and are poorly documented if they're documented at all. Second, you probably don't understand the business process at the company. I've found it generally takes about a year to really start to understand the processes behind the code. Until then things that look like side effects or bugs probably have a very good reason. One you won't discover until you "fix" them.

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 know which broken project we are talking about..

[recoiledsnake]

http://beta.slashdot.org/

Re:Short answer: Run.

[Anonymous Coward]

If you're not going to wimp out and run, then man up, confront the situation, and fix it. Regardless of whether the original author is well-respected, you need to expose the problem. You don't have to be an ass about it, just go to the original author and ask him why its in the state that it is, more often than not he was under deadline to get it finished and cut corners. Worst case scenario, he thinks he's a rock star and can't believe they hired a dunce (you) to replace a genius (him). Or just tell your boss that the existing state of the code is hindering progress and things need to change, don't even mention the original author. Figure out what you have, what it needs to be, and plot a course to make he necessary changes to get it there. Inflate estimates to adjust for the added complexity and if anyone questions your estimates, tell them exactly why it will take you that long (which may include "I haven't touched that code yet and am not familiar with the potential side-effects" or "the architecture is so fubar'd that I'm going to have to refactor").

But whatever you do, absolutely *do not* bitch and whine about it. No one likes a whiner and it will just make you look like an amateur. Always remember, the problems of writing and maintaining software are hard and not always technical, you're paid to solve them. There are already too many amateurs making good money to create more problems than they solve, don't be one of them. And always remember that no matter how smarter you are than everyone that came before you, cleaning up their shit is ultimately your job. Deal with it.

Also.... Re:Make a real assesment

[Fubari]

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.

This is why poeple call their jobs "work"

[Glires]

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.

Re:Short answer: Run.

[Anonymous Coward]

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.