×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Ask Slashdot: What Do You Do If You're Given a Broken Project?

samzenpus posted about a year ago | from the cleaning-up-the-mess dept.

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

Sorry! There are no comments related to the filter you selected.

Does the Tin Man have a sheet metal cock? (-1, Troll)

Anonymous Coward | about a year ago | (#46140361)

That's what everybody wants to know.

Re:Does the Tin Man have a sheet metal cock? (0)

Anonymous Coward | about a year ago | (#46141083)

Some of us already know. You just lack courage, coward.

Enjoy your Death March (5, Informative)

pegr (46683) | about a year ago | (#46140363)

Re:Enjoy your Death March (2)

Agares (1890982) | about a year ago | (#46140589)

I wish I had points to mod you up. I have seen this way to often.

I know which broken project we are talking about.. (5, Informative)

recoiledsnake (879048) | about a year ago | (#46140629)

Re:Enjoy your Death March (5, Insightful)

0p7imu5_P2im3 (973979) | about a year ago | (#46140743)

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 (5, Insightful)

Anonymous Coward | about a year ago | (#46140977)

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?

Short answer: Run. (4, Funny)

korbulon (2792438) | about a year ago | (#46140379)

Long answer: Run real fast.

Re:Short answer: Run. (1)

jones_supa (887896) | about a year ago | (#46140405)

He says in the summary that quitting does not "feel right".

Re:Short answer: Run. (3, Insightful)

mrchaotica (681592) | about a year ago | (#46140421)

Get over it?

Re:Short answer: Run. (4, Insightful)

TWiTfan (2887093) | about a year ago | (#46140469)

It's going to feel a lot less right when the project collapses and everyone points the finger at the fall-guy contractor.

Re:Short answer: Run. (4, Insightful)

TWX (665546) | about a year ago | (#46140707)

And worse, that could directly impact the contractor's future work prospects, if they cite how bad a job the contractor has done, even though it wasn't his fault in the first place.

You don't work for that company directly. Your decline to take on their project will probably have more positive effect for that company, in the long run, than your attempting to salvage it and shooting your foot off. They'll be forced to either make the existing employee work on it or will be forced to scrap it and ask hard questions of the existing employee in the process.

Re:Short answer: Run. (3, Insightful)

korbulon (2792438) | about a year ago | (#46140623)

He says in the summary that quitting does not "feel right".

If I conducted my business based on what I deemed to "feel right", I would probably never leave my house.

Re:Short answer: Run. (1)

TWiTfan (2887093) | about a year ago | (#46140455)

Agreed. Run, Forrest, Run!!

Re:Short answer: Run. (0)

Anonymous Coward | about a year ago | (#46140667)

As always we can look to the doctor for advise

Message follows. "Run. For God's sake, run. No way is safe. The Library has sealed itself, we can't... Oh, they're here. Arg. Slarg. Snick." Message ends.

Re:Short answer: Run. (5, Insightful)

Anonymous Coward | about a year ago | (#46140665)

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.

Re:Short answer: Run. (2)

dreamchaser (49529) | about a year ago | (#46140711)

That plus some advice. Do your due diligence first. Blindly accepting a coding project without at least taking a cursory look at the code isn't very wise.

Re:Short answer: Run. (2)

JoeMerchant (803320) | about a year ago | (#46140987)

Recode from the ground up, congratulate the well respected member of the permanent team on taking the app as far as he did - explain the time required to add the requested functionality - if they don't like your time estimates, find another job.

If you add your signature to the broken code, the steaming pile becomes your legacy, not his.

If you provide a good replacement without trumpeting what an incompetent ass the previous author was, nobody is really going to know or care that you ditched all his code and replaced it.

Run, Run For Your Life (0)

Anonymous Coward | about a year ago | (#46140383)

Seriously, don't step on that landmine. Just run away and let some other sucker be the sacrificial offering (and scapegoat).

You were not hired to finish the project (5, Informative)

EmagGeek (574360) | about a year ago | (#46140385)

You were hired to be the scapegoat.

Re:You were not hired to finish the project (1, Interesting)

janeuner (815461) | about a year ago | (#46140473)

Or, perhaps, you were hired to find a scapegoat. Honestly, who cares; they need the project to work, so make it work.

The project is yours. Guess a rewrite timeline, send it to your boss, and get to work. While they bicker on it, send them updates. If you are going to get fired, it was going to happen anyway; you can still do good work in the meantime.

Re:You were not hired to finish the project (4, Insightful)

TWiTfan (2887093) | about a year ago | (#46140545)

If he makes it work, the original "respected" designer will jump in and claim all the credit.

If he doesn't, he, as the scapegoat contractor, will get all the blame.

No-win situation. Leave now.

Re:You were not hired to finish the project (-1, Redundant)

Loether (769074) | about a year ago | (#46140765)

As a contractor, your job is to make the project work. If you can make an employee look good, all the better. As far as your concern for misplaced congratulations... I quote Don Draper, "That's what the money is for!"

Don't show weakness (-1)

Anonymous Coward | about a year ago | (#46140931)

No. It's not time to run. This is where you start the email trail with your manager "This is going to fail; we need to pick a fall guy." Then you go and in person pick the fall guy. Hire a contractor who doesn't have a good reputation anyway and pin the blame on them. Plan to fix it after the contractor is blamed, and make damn sure you execute on that; you want to be the rockstar, not collateral damage. Your boss will like this too, as it keeps him from being blamed.

Re:You were not hired to finish the project (1)

SQLGuru (980662) | about a year ago | (#46140573)

I'd be more inclined to go this route...if hired as a contractor, then self-evaluate whether your contract lasts longer than it would take to rewrite. If it takes longer to rewrite, communicate the problems and just triage as best you can unless they offer to extend the contract. If you have the time, refactor as you enhance so that you balance a rewrite with getting features completed.

Re:You were not hired to finish the project (3, Insightful)

JaredOfEuropa (526365) | about a year ago | (#46140543)

Perhaps, and in that case you're damned if you do (stay) and damned if you don't (quit and run). In either case you could be looking at reputation damage.

It might be worth doing some digging around the company, though. What relation does your boss have with this app and with the previous developer? What is the history of the development of this app? If this is a doomed but high profile app, the scapegoat theory would seem to hold. But if your boss wants the app to succeed and has no reason to be afraid to potentially piss of this darling developer, then it's worth talking to him, especially if he knows a bit about software development. Explain the problem and provide estimates on what it takes to turn this thing around. That's what I would expect a contractor to tell me if I hired him with honest intentions.

Re:You were not hired to finish the project (2)

funwithBSD (245349) | about a year ago | (#46140841)

Yes, and present as a "go -no go" choice and let him make the call.

If he says no go, you can move on with no consequences. If it is "go" and it fails, you documented why it was in trouble and what the risks were.

Re:You were not hired to finish the project (0)

Anonymous Coward | about a year ago | (#46140621)

Exactly. So why on earth would you continue? Unless the pay is amazing, go find a different job. You're a contractor, why on earth would you show dying loyalty to this company?

Re:You were not hired to finish the project (1)

PPH (736903) | about a year ago | (#46140767)

Maybe. Maybe you were hired because you are disconnected from the company politics and culture. Talk to the customer and the previous developer (really bad sign if they discourage the latter). Get an idea what went wrong and negotiate your terms based upon avoiding the same pitfalls.

Some of the most interesting projects I've worked have been ones that the locals couldn't solve because they had to live there after the dust settled (see sig line).

One reason companies hire contractors for jobs like this is visibility. You represent an actual cash outlay and (unless they are swimming in contractors like a Microsoft) upper management wants to know why. Some middle management PHB fuckup can't hide you like they could a direct employee.

Or, this guy is the problem. (1)

Anonymous Coward | about a year ago | (#46141049)

Maybe THIS guy is the problem.

Maybe the app is breaking because he doesn't understand how it works.

Everyone here is assuming that because he's picking up the project that he is the expert.

Many times companies hire the contractor to do the minor things that the employee doesn't have tme to do.

This has happened to me. I wrote a bunch of code that worked perfectly and the new guy came, slammed some code in without understanding how it worked and broke it - and I got the blame for being an idiot. I had to debug it and find the error - putting me BEHIND on my own projects just to find out I was being blamed for another's incompetence.

God I hate this industry!

apologies to rumsfeld (5, Insightful)

Anonymous Coward | about a year ago | (#46140397)

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)

Re:apologies to rumsfeld (1)

CFBMoo1 (157453) | about a year ago | (#46140579)

I like you, you appear to create documentation. Since I don't have mod points I'll give you a +1 awesome for a willingness to make documentation.

Cover your ass and vote for a IT union (2)

Joe_Dragon (2206452) | about a year ago | (#46140401)

now as a contractor it's easy for them to drop the blame on you even when it's some PHB who let things get to the point that they are at.

Maybe even call your staffing agency and tell them what is up before you get a black mark

The fault (2)

glennrrr (592457) | about a year ago | (#46140403)

The fault, dear Brutus, is not in our stars, but in ourselves.

I just (0)

Anonymous Coward | about a year ago | (#46140411)

scroll to the bottom and switch back to Slashdot Classic

Re:I just (0)

Anonymous Coward | about a year ago | (#46140577)

scroll to the bottom and switch back to Slashdot Classic

Absolutely not related to the topic at hand but damn! I've been looking for that button for over a month now!

Re:I just (0)

Anonymous Coward | about a year ago | (#46140881)

Log in, asswipe. I'm still on D1.

Write tests. Write more tests. (5, Insightful)

Anonymous Coward | about a year ago | (#46140415)

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.

Run to the hills! (0)

Anonymous Coward | about a year ago | (#46140425)

Run fooorrrrrr yourrr lifeeeeee!

Also post really bad code to dailyWTF, need some more fun shit there.

Make a real assesment (5, Insightful)

gearloos (816828) | about a year ago | (#46140427)

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.

Re:Make a real assesment (2)

phmadore (1391487) | about a year ago | (#46140483)

Why you mods harsh on this guy? Can't see how this got -1.

Re:Make a real assesment (3, Informative)

mknewman (557587) | about a year ago | (#46140783)

I agree with this assessment. Be honest. If management doesn't believe you, quit and go somewhere else. Usually when you try to quit they will freak out and realize you were serious and try to keep you, on your terms.

Also.... Re:Make a real assesment (5, Insightful)

Fubari (196373) | about a year ago | (#46140861)

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.

Suck it up (4, Informative)

CokoBWare (584686) | about a year ago | (#46140433)

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.

Re:Suck it up (0)

TWiTfan (2887093) | about a year ago | (#46140501)

He's been hired as a fall-guy. The respected developer realized his project was failing and bought himself a sap, a contractor that he can now blame for his screw-up.

Re:Suck it up (1)

CokoBWare (584686) | about a year ago | (#46140795)

There is no evidence to support this hypothesis. Unless the OP had explained this to be true, I would not jump to this conclusion.

Re:Suck it up (2)

gstoddart (321705) | about a year ago | (#46140917)

You know, I question if that's the case.

I've seen several instances where someone throws together a proof-of-concept and then says "see, solved problem, the rest is an exercise for the reader". In fact, I once got something thrown at me by a VP who had knocked something together with some cheap hacks, string and tin-foil. In practice, what he'd done worked on a single demo system but couldn't remotely be made to work in a real system.

Then you get into the problem and discover that so many naive assumptions have been made that it's not really possible to do it as envisioned. Essentially whoever did it ignored all of the real considerations as not important, and then just punts it to someone else to discover all of the underlying flaws.

So, while it's possible the developer realized it was a turd and wanted to get out from under it -- it's also possible it was seen as well-defined enough to be an app for a contract coder to finalize.

We once had a developer who could crank out reams of unintelligible, un-maintainable code as a demo/customization for a customer ... but which was brittle, sketchy, and completely not robust. Someone then asked that it be turned into a general solution, only to discover that it barely handled the specific solution because it made unsupportable assumptions, and completely neglected all of the other issues you needed to consider.

Never underestimate how much trouble can be caused by someone who merely believes they've come up with something brilliant, but which on closer inspection is blatantly garbage.

I quit (1)

TempleOS (3394245) | about a year ago | (#46140451)

I got assigned fucked-up backwater projects twice and quit.

Depends (1)

phmadore (1391487) | about a year ago | (#46140465)

Depending if I'm hourly or, as a contractor getting a single payment for the job, I'd either start from scratch (hourly) or quit (single payment). If I started from scratch, I'd make sure to document the several hundred lines which of erroneous code which led me to do so, explaining that, in my hands, the only way to do it was the way I did it.

If the "well respected guy" is still there (5, Informative)

MillerHighLife21 (876240) | about a year ago | (#46140467)

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.

Re:If the "well respected guy" is still there (4, Insightful)

Dan East (318230) | about a year ago | (#46140693)

Further, if it's case 1 (a quick "get it done" job to just get it over with really fast and move on), then you need to take the proper tone to set up an environment for you to complete the task you were brought in to do. What I'm talking about is portray the software in a positive light - that it is efficient, single-purpose, quickly developed, etc. However, for those reasons it isn't very extensible, and you're going to need to lay some groundwork and framework to facilitate the enhancements they require. What I'm presuming you're lamenting is you don't have the time or bid too low for the amount of work required. You need to communicate to them that you will have to reorganize a significant amount of the existing code in the process. Be sure and state the advantages (IE what they're getting for their extra money), which will be streamlined future enhancements, and importantly, more efficient maintenance of the software from here on out.

I've been in this situation a number of times, and every time the higher-ups had an appreciation for the extra work required to lay a good groundwork and I was able to proceed in the manner I recommended even if it took more time. Another way to explain it to a non-technical person is that software is often built very incrementally and piecemeal, and that can result in a hodgepodge of code over the years, and every now and then it requires a good reorganization and consolidation of redundant parts into reusable libraries. Usually they understand that general concept, because it's true of most physical, real-world assets as well.

Re:If the "well respected guy" is still there (2)

swillden (191260) | about a year ago | (#46140775)

+1

The right answer is almost always to communicate and then communicate some more. Use both informal and formal channels, staring with the informal ones so no one is blindsided, but with the formal communication ready to go (so whoever you talk to doesn't have an opportunity to blindside you). In the informal communication, be clear that you are going through formal channels as well, in fact it's probably a good idea to approach the original dev and whoever else is appropriate with something "I have written up this analysis of my findings, but before I submit it I wanted to see if you can help me correct anything I may have misunderstood or if you have any suggestions." That way you're engaging them positively, but setting the expectation that you are going to take it through channels. Be positive and professional, not critical, but be forthright and clear about what you're seeing and your best estimate of what it will take to get to end of job.

If backstabbing and scapegoating is the nature of the company culture, this communication will end badly. But in that case it's going to end badly regardless, and this way at least anyone who looks honestly at what happened will not think less of you. If there's a modicum of honesty and rationality around, you'll come out fine -- and much better than if you just quietly toil away and then fail. You should probably be able to look around and get a pretty good idea in advance which way this is going to go.

Also, make sure you have something else lined up.

Re:If the "well respected guy" is still there (1)

King_TJ (85913) | about a year ago | (#46140781)

Not a software developer myself, but I worked closely with a group of them for years....

I'd say MillerHighLife21 is absolutely right. Any developer who actually has *some* level of pride in his/her work will usually be happy to explain the code to you, if you've taken on working on their original project.

Someone else posted that you "can't win" because even if you fix it completely, it's the original author who will come back and take all the credit. That could well be true, but let's face it.... you're a contractor, not a full-time employee. IMO, that's part of the deal with working as a contractor. You're often paid to make somebody else look good. Your end of the bargain is a decent paycheck, at an hourly rate often as much as 2x or more what the full-time staff gets paid.

If that's an issue for you, then I'd have to ask why you aren't pursuing full-time employment, where the company has more of a vested interest in you (and you in them)?

I think you can accomplish this goal with the help of some communication with the original developer, and a tactful approach where you're not insinuating the problems with the code have anything to do with his/her lacking in coding abilities. (Maybe it does and maybe it doesn't -- but either way, the situation is what now affords you the opportunity to get paid to work on it!)

Re:If the "well respected guy" is still there (0)

Anonymous Coward | about a year ago | (#46140939)

Treat it as a terminally I'll cancer patient, and just try to make it comfortable till the EOL. Which may destroy you, but really first and foremost do no harm, document what you can do, then do what you need. Pretty soon you'll find yourself doing the impossible.

Re:If the "well respected guy" is still there (0)

Anonymous Coward | about a year ago | (#46141043)

Document what you need to do, then do what you can! Pretty soon you'll be finding yourself doing the impossible- is the correct chore of action

Write a comprehensive dossier on the situation (1)

Thanshin (1188877) | about a year ago | (#46140479)

Explain, with factual data, examples and clear descriptions without embellishment, the current situation of the project. Add a detailed (factual, true, sincere) description of what will happen if the problem is ignored.

Then, you need the professional maturity to know whether you are the correct person to solve the problem:
If you are, present plan with the different possibilities:
-- Restart the project.
-- Abandon the project.
-- Accept the losses and put another team to correct the project.
-- etc...
If you aren't, explain that there's a need for someone able to construct a plan with those different possibilities.

And, above all, make an effort to believe that the best solution could be to do nothing, to accept the bugs and the losses.

Prove that the code is not workable (0)

Anonymous Coward | about a year ago | (#46140485)

Gather metadata like cyclomatic complexity and prepare a few examples where changing things shows how brittle the code is. Propose structural changes and asses how much time they would take. Let them decide if they believe you and what needs to be done. The original creator will probably admit the project was rushed.

Re:Prove that the code is not workable (1)

jetkust (596906) | about a year ago | (#46140587)

Sounds like a lot of work.

Don't take the fall (3, Insightful)

SirGarlon (845873) | about a year ago | (#46140489)

The phrase that comes to mind is "set up for failure." Don't be a fool: they dumped this job on a contractor because they knew the project was doomed from the outset. I've been there.

Which is worse: to walk off a job when you find out you've been tricked, or to stay on for the death march all the way to failure, and then get fired? (or, in your case, "contract not renewed," which is the same thing.)

My advice is to get out while you can, and be more circumspect about accepting projects next time.

If your sense of duty requires, you can discuss with your project manager why the job does not look doable any more, and see if he/she is open to major re-planning. But you should be prepared to quit the job on the spot if that meeting does not go your way.

Plan and proposal (1)

z4ce (67861) | about a year ago | (#46140505)

If you think the code needs to be refactored, come up with a plan and a proposal to do that.

It could be this individual is well respect for their ability to come up with ideas and realize through prototypes and not necessarily create long-term maintainable code.

First, tell the person who's paying you (0)

Anonymous Coward | about a year ago | (#46140517)

The earlier the better!

They need to balance features vs quality vs money (aka time), and so will need to chose between a bunch of alternatives.
If you want to not look dumb, know the alternatives and be prepared to receooend one:

  • Spend the time/money (but they'll need to re-estimate, based on how much slower you found yourself being)
  • Cut the deliverables (again, after re-estimating)
  • Allow poorer reliability for the beta (if it's a customer priority)

plus combinations.

--davecb (from a work computer)

Glass is half-full (0)

Anonymous Coward | about a year ago | (#46140529)

A broken project is an opportunity. An opportunity personally and for your career. Analyze the issues, understand them and attack. Yes, you may have to work harder, but you will always have an ace up your sleeve in your next interview.

Professionalism (1)

GerryHattrick (1037764) | about a year ago | (#46140537)

It's hard, but if you are a real Pro, you will know how to fix it, and (more important) how to fix the situation that led to the failure. Then walk away, and your reputation will most certainly follow and reward you.

Re:Professionalism (1)

polar red (215081) | about a year ago | (#46140605)

... or : the original dev, or a manager in the company scoops it up as their win ?

Programming is hard (0)

jetkust (596906) | about a year ago | (#46140541)

If you're a good programmer, finish the project. Otherwise, quit.

Like Any Other Project (3, Informative)

azadrozny (576352) | about a year ago | (#46140549)

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.

Re:Like Any Other Project (0)

Anonymous Coward | about a year ago | (#46140727)

yes.

everyone should know you're having problems. the guy who hired you, the guy who wrote the code.

it doesn't have anything to do with your level of skill, or his level of sloppiness.

its a project, and if the schedule is going to be blown because the foundation isn't right,
then best to discuss that early

if you are both reasonable, then you find a way to proceed to your mutual satisfaction. and even
though its not what they wanted, the client can see you're doing good work.

if they aren't, then you can feel just fine about walking

Simple, (0)

Anonymous Coward | about a year ago | (#46140583)

Shut up, suck it up, sit down, do the work, get paid by the hour

Step one, do not criticize. Step 2, document. (3, Informative)

Stolpskott (2422670) | about a year ago | (#46140591)

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.

Nice cloak post (5, Funny)

andyring (100627) | about a year ago | (#46140599)

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

Re:Nice cloak post (0)

Anonymous Coward | about a year ago | (#46140965)

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

Ah, thought he is talking about one of my apps

Re:Nice cloak post (1)

HnT (306652) | about a year ago | (#46140979)

Simple: just upgrade to the IntelliLink Centurion package!

All Programs Are Like That (5, Insightful)

Greyfox (87712) | about a year ago | (#46140615)

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.

The very first steps... (1)

Anonymous Coward | about a year ago | (#46140625)

1. request the project documentation.... and send it to the managing supervisor AND the former worker on the project... and send it to anyone else that MIGHT know of the project...

2. when that fails, request the specifications for the applications from the same list of people...

3. when that fails, issue a bill for services rendered... :) and offer a proposal to fix the thing (and NOT a fixed cost proposal).

Restate the objectives (1)

clinko (232501) | about a year ago | (#46140631)

Don't tear into the guy before you. Just say, "I'm sure this was built with an initial objective in mind. And it served the purpose well. The firm is doing well and expanding. I would like to know the best approach to make this product grow with it."

Then, ask the firm to define the objectives/requirements again now that you've found a *few* issues.

1.) Do you want the project to be re-built for _stability_?
2.) Do you want me to improve the _time to market_?
3.) Would you like me to leave it as is?, but be aware that extra QA will be needed.

Good Luck!

A broken project is like a broken heart (1)

Chrisq (894406) | about a year ago | (#46140633)

A broken project is like a broken heart. Sometimes you just have to move on.

Don't break it (0)

Lije Baley (88936) | about a year ago | (#46140639)

In today's "speed of business" world, sometimes even good programmers write brittle code. And sometimes we have to deal with it. It sounds like you need to get a better understanding of this code, otherwise you wouldn't have broken it. Then you can band-aid and duct tape it, or come with a plan for rewriting, but which approach is appropriate may depend more on business than technical considerations sometimes.

No Easy Answer (1)

Akratist (1080775) | about a year ago | (#46140657)

A lot of it depends on where you are at in your career and what your long-term goals are. A paycheck is a paycheck is a paycheck. Few of us get to work on our ideal sorts of projects, and even those jobs eventually go away as the company and market changes. Part of the issue is that you really don't "own" the code, in the sense that you're not familiar with it and weren't there for a lot of the decisions that went into creating it. On my old project, I could tell nearly to the line where the problem areas were and how to fix them. On my current project (which is a large, fragile, and poorly engineering Frankenstein app that I walked into), I'm kinda in the same boat as the OP. I can see a dozen places where the architecture needs to be changed and updated, but it won't happen because of budgets and a resistance to change here. Anyway, once you've spent some time with it, you'll get to understand it better, in spite of yourself. You do have to ask yourself what you're trying to achieve, though...career advancement into an architect/lead job, or just passing time until the next coding gig. I show up, do quality work, and go home to pursue my side projects at the end of the day, as I've gone probably as far as I'll go in terms of advancement. Outside of keeping my skills current and being one step ahead of the obsolescence curve, I don't care all that much what I work on during the day...so, if I were you, my big concern would be whether or not I'm falling into a code rut -- is this old tech and old approaches, or newer stuff that is still in demand? If it's something old, learn what you can, then plan an exit. If it's newer stuff, get some good experience and move on when you feel like you've left things in a good place.

Car maintenance price list: (3, Insightful)

Ihlosi (895663) | about a year ago | (#46140679)

Fixing your car: $40/hr
You want to watch? $50/hr
You want to help? $80/hr
You tried fixing it first? $150/hr

I hope you realized which kind of software work this was going to be and priced it accordingly.

#1: Ask for a raise (1)

stevegee58 (1179505) | about a year ago | (#46140683)

#2: Use it as leverage at review time

Things like this are opportunities, not burdens.

Constructively: Good Luck and God Bless (1)

Anonymous Coward | about a year ago | (#46140689)

Development Approach:

* Make sure the source is in source control.
* Pick a semantic version number (semver.org) if there's not one already (MAJOR.MINOR.PATCH[...])
* File things in a ticket/issue system
* Link commits to tickets/issues
    * Maybe even go so far as to require #[\d]+ in all commit messages.
* Explain the problem in the ticket system (DRY: Don't Repeat Yourself)
* Have links to reputable resources which describe the problems you've discovered.
    * http://cwe.mitre.org/top25/
    * https://en.wikipedia.org/wiki/Code_smell
    * https://en.wikipedia.org/wiki/Anti-pattern#Software_engineering
* Have links to reputable resources for learning about doing good software development.
    * https://en.wikipedia.org/wiki/Continuous_integration#Principles
    * http://class-central.com/subjects/cs
    * https://en.wikipedia.org/wiki/Technical_debt
* Write tests for existing functionality and then for all new features.
    * If something is 'broken', it should be demonstrably so.
    * There's no need to argue about tester competency.
    * Either the test is good and passes, or it isn't.
* Pick a coding standard / style guide and stick to it. Link to it.
* Develop standards for documentation to make it easier to train new people.
* In addition to complexity/difficulty/time estimates, it can be helpful to estimate risk.
* Plan for the "Hit By A Bus" scenario.

Organizationally:

* Consider advocating for software development standards and certifications.
* Work with HR to improve hiring practices
    * There are lots of great online coding interview resources.
    * Require interviewees to write code in interviews.
* For isolating root cause, blame can be more wasteful than helpful.
* Make sure you notify a senior person about your concerns and intent, so that it is on file.

Decide what you're getting out of it (1)

quietwalker (969769) | about a year ago | (#46140695)

Is it about the money? Is it about maintaining a professional relationship? Having a steady job? Completing a challenging assignment? Learning a new skill? Working on an app that will eventually be released as a finished product instead of a never-ending series of bugs or rolling feature updates from an agile process with no end or sense of accomplishment?

Figure out what you want out of it, and then take the steps to achieve that.

That aside, I personally don't place a lot of value in seniority for the sake of seniority. That someone 'respected' worked on it means nothing at all if the product is crap.

At one workplace, I acquired a project much like you did; our three architects had all worked on it personally, over a 10 month period. It took me 2 weeks to get it running on my own machine locally - so much had been hardcoded; pathnames, machines, pre-existing sql connections with expired logins on machines only accessible from within a cluster. It had unimaginable complexity, built so that they could 'throw it over the fence' to the ops team, and supposedly let them own it, and update it for when our software changed in the future. They would only need to learn java, sql, our internal table structure (undocumented and continually changing) and SSIS too. It didn't help that the software still didn't work yet. It'd run for 2 days and then drop a 40+ gig coredump.

Yeah, I complained, and complained, and everyone just said 'make it work', so I talked to the end users and product owners, collected requirements, and wrote the whole thing from scratch as a command-line tool in about 4 hours. I had to spend 2 days making a power point presentation to demonstrate how it was functionally superior (cpu, memory, bandwidth, throughput), easier to use (2 pages of documentation), well commented and structured, had no 3'd party dependencies (so no extra $$$ for database licenses and such), and how it followed the company statement and policy (one of which was explicit; 'Do not just "throw it over the fence"').

I got a lot of positive attention from that. If recognition is your thing, that may be the way to go.

When I eventually quit that job they remembered that I got stuff done, and done well. So now I work for them in my spare time, making 3x my previous salary, on discrete projects where I call the shots and they just need something that works well without dealing with months of crap in between. So, I eventually got money and responsibility too.

Of course, your results may vary.

mercy killing (1)

prgrmr (568806) | about a year ago | (#46140725)

Find reasons, both technical and financial, to make the most professional recommendation that you can to kill the project. This means just the facts, and no name calling (actual or implied), no editorializing about the lack of quality or organization of the project's goals, parameters, or guidelines or lack thereof--although anything obviously absent should be noted. Take a moral stand, if necessary, about your resolve to not take money under false pretenses, and that continuing the project would be just that. Implying that anyone else taking money for the project, contractor or employee, would be equally doing so falsely, may be either the exact needed thing to do, or the exact most wrong thing to do, depending upon your audience.

Work with Management (0)

Anonymous Coward | about a year ago | (#46140729)

Be honest, work with the management and keep your opinion out of it.

And welcome to the real world.

Developers are like dentists (1)

ljw1004 (764174) | about a year ago | (#46140761)

Developers are like dentists.

Every time you switch to a new dentist, he or she looks over your mouth and declares that they teeth are all in terrible shape, that the previous dentist did poor work, and it will all have to be redone properly.

Software developers are the same. They see a legacy piece of code, see only the ugly cruft and hacks, think they can do better by rewriting from scratch, but their rewrite ends up with all of its new cruft and hacks as well.Oh, and the subtle "long tail" bug fixes that had previously been fixed in the legacy codebase? None of those make it into the rewrite... instead it comes with its own fresh long tail of bugs.

Been on that contract (2)

Oligonicella (659917) | about a year ago | (#46140793)

Got a contract a STL phone companyl to examine a system with much the same setup; a billing system purposely avoiding all standards (naming constants "Literal-R" because literals weren't acceptable), no performs, only jumps (not spaghetti, Ramen), etc. I decrypted it's function and what it was supposed to do as well as what it did, wrote a very detailed report on what was wrong and why it was so and turned it in. I spent the last four months of the contract sitting and studying pretty much what I wanted because Mr Silver was a golden, do not touch, boy. Meh, paid very well.

Problem? What problem? (1)

swm (171547) | about a year ago | (#46140815)

If you are a contractor, and "there's plenty of jobs you can take", then you really don't have a problem here. Let's take it by cases.

1. You just don't want to deal with this app/code base/company/assignment
Then leave for one of those other jobs. That's part of what being a contractor is all about: being able to drop clients that you don't want to deal with.

You don't have to be rude or snarky about it. Give notice, complete whatever term or notice period is specified in your contract, and move on. If they ask why, tell them simply and honestly. Providing such information (if asked) is part of your service to them.

2. You are willing and able to do the work
Great! You've got a good gig, and from the sound of it, it could keep you in peanut butter and iPhones for a long time.

If the code base is a horrid mess--that's their problem, not yours.
If everything takes 2, or 5, or 10 times a long as it "should"--that's their problem, not yours.
If every time you fix a bug, the app breaks in two other places--that's their problem, not yours.

If they ask for schedules, give them your best estimates, based on what you know about the code base.
If they demand to know why everything takes so long, give them your best (diplomatic) explanation of the problems with the app. Speak only in terms of the code as it stands. The history of who wrote it and how it got that way is irrelevant.
If they decide you are incompetent and dismiss you, then you are back to case 1, above.
If they decide to cancel the whole project and terminate your contract, then you are back to case 1, above.

Part of what a company gets when they hire contractors is the ability to dump scut work on them (so that the "well respected" people don't have to do it), and the ability to dismiss them when circumstances change (w/o paying unemployment, etc.) If you're OK with that deal--the work, the scut, being low man on the totem pole, no job security--then give them the best 8 hours of your working day, cash their checks, and sleep soundly. The day you're not OK with it--the day you wake up thinking, "I *just* *can't* do this any more"--that's the day you give notice and move on.

Doh! (0)

Anonymous Coward | about a year ago | (#46140819)

1. Make up story
2. Restore from backup
3. Checkout
4. Wash; rince; repeat

Three options: run, coast or double down (1)

H0p313ss (811249) | about a year ago | (#46140821)

1. Run: Quit, don't let someone else's failure become a black mark on your record.
  i.e. You're a coward, not up to the challenge, nobody should hire you.

2. Coast: Just survive and let the waves wash over you.
  i.e. You're a lazy fuck, nobody should hire you.

3. Double Down: It's not a problem, it's an opportunity. Tell your boss there's a major issue, but show them that you're on top of it. Make a full written analysis of the code base you've inherited; document it's strengths and weaknesses and what needs to be done to address them. Provide a task list and a schedule.
  i.e. You're exactly the person people want to hire.

find out why you were hired (4, Insightful)

v1 (525388) | about a year ago | (#46140835)

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.

Relax. (1)

Anonymous Coward | about a year ago | (#46140851)

You can still work at it, but given an already pre-boned project, you cannot make it fail even worse. So anything you DO manage to get out of it is just gravy.

The worst ones are the "nearly boned" projects. Jobs that are *probably* broken but with luck and hard work could work. THOSE have you sweating bullets so that it isn't failing because you're not good enough.

This is why poeple call their jobs "work" (5, Insightful)

Glires (200409) | about a year ago | (#46140865)

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.

Depends on how critical it is (0)

Anonymous Coward | about a year ago | (#46140919)

I had one like this once. An electrical engineer, who was no longer with the company, wrote the original program. It was used in a manufacturing company to set registers on safety equipment the company sold. The code checked in to source control would not compile because the original "programmer" had checked in source haphazardly. There was no way to figure out which code was in the running binaries. The catch here was the change was critical. The longer this took to fix the more likely someone would die.

Decompile. Edit. Recompile. Test. Lather. Rinse. Repeat.

We made it work, and it sucked. I sat down with my boss and explained the situation and the associated risk to the company and asked for the opportunity to rewrite the app. It took a year before we started the rewrite, and I had to go through the same process two more times. Each time I reminded my boss of the issues and risks. But sometimes you have to do what you have to do. On the plus side, I got a nice promotion just before the rewrite.

When you don't have a choice, just do it. Then explain to your boss (and possibly his boss) the problem and risk to the company in language they can understand. If the app is critical or costly enough they'll eventually get around correcting the problem if you're persistent and patient. And chances are they'll remember you saving their sorry behinds when it's time for review/promotions. If they don't, move on.

Two points (1)

advid.net (595837) | about a year ago | (#46140941)

1- Document every bug encountered, corrected or not.
2- Put emphasis on this project property: terrible cascading effects when anything is changed.

Whatever decision you make later, this won't hurt you and will likely help you.

It doesn't "feel right"? (1)

DogDude (805747) | about a year ago | (#46140969)

Who cares if it "feels right" or not? What a silly question. If one is an contractor, paid hourly, then why should it matter if the project "feels right"? Unless the subject of the project is something like child porn or genocide, then just do the damn work and take the pay.

When I was a developer (and a contractor), and I saw a project that was a mess, I'd think, "Oh good, this project is going to require a lot of work. I should be able to make a lot of money from this contract." My "feelings" about the quality of the code were irrelevant.

May not feel right, but it's the right thing to do (1)

Opportunist (166417) | about a year ago | (#46141015)

To be blunt, this smells like you're supposed to be a scapegoat. If a well respected individual of a company hands off a project to a contractor, something is odd. If you then notice that the project is in the process of crashing and burning, the most likely explanation is that that "respected individual" noticed that it's going to blow and that he wanted to jump ship before it's too late, i.e. before there's no way he could pin the blame on someone else. In this case, you.

Get out. Now. Explain the reasons, and that you didn't think it was necessary to check out the code because it was handed to you by such a respected and renowned engineer, who clearly must have taken over the project himself because he could never deliver such a shoddy work, and that you feel you do not have the necessary background inside the company that you could turn it into a successful product.

Get out. Now. While you still can without irreparable damage to your reputation.

Instrument the code (2)

rover42 (2606651) | about a year ago | (#46141017)

As others have suggested, talk to the original developer, document the problems and keep your boss informed. If you are a contractor being supplied by one firm to another, keep the appropriate people at both companies informed. Also, look for ways to measure the problems. First, can you run the code through lint(1) or crank the compiler options up to reveal problems? Then can you add runtime error checking or data validation code? This may help you fix things and/or be useful as documentation. Once, when working as a tech writer, I wrote a half a dozen little scripts to inspect 600,000 lines of C from a dozen programmers. Hmmm. Less than 5% of switch() statements had a default: case for error-checking. Less than 20 uses of the assert() macro in the whole code base. And so on. The programmers mostly came from a Pascal-like environment so almost none were using C idioms like if( (p = fopen(...)) == NULL) for error checking. That is OK but I found dozens of cases where they were allocating memory, starting processes or opening files, sockets or pipes with no error checking at all.

Rebuild it from scratch (0)

holophrastic (221104) | about a year ago | (#46141061)

Well respected means that they've got other things to do, which is why they aren't working on it anymore, and why you were brought in to the job in the first place. There's a very likely chance that this isn't his best-effort project, but rather was done as a quick-fix, or a really-fast effort. He probably never thought it would last beyond phase 1, which is why it isn't stellar code in the first place. Hey, if a contractor can stick with it, so much the better. But since you can't, and it's not your fault that you can't, it's time to rebuild it.

And contractors are perfect for rebuilding things that already exist. No need for a spec, nor for supervision. Just rebuild it. Ask for the time, and you'll get it. Ask for a quick meeting to discuss possible-future features so you build it properly this time. You'll get that too.

Enjoy.

Clone it. (0)

Anonymous Coward | about a year ago | (#46141067)

Make an entirely new greenfield system with "many" of the features and benefits of the vaporware project, and to some degree make it extensible. Deliver it. Now offer consulting fee level services to maintain and extend it.

Simple.

Debug, document, add tests, refactor (1)

Cheburator-2 (260358) | about a year ago | (#46141081)

Recently I had a very similar, but mirror experience. I've written a piece of complex code. Then a new guy came, looked at my code (he needed to fix a couple of things there) and decided that it's a piece of shit that could and should be rewritten from scratch in a couple of days. He failed. It's not that my code wasn't a piece of shit (it was), but there was a reason for it: that code was responsible for a very complex task and there was a severe time constraint. Most likely you have a similar code. My advice: don't blame the author. Instead, try to understand why his code is so complex. Study it, debug it, document it. Add high level tests for all possible situations. Then try to refactor the code to make it more robust and easier to understand. Good luck!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?