How to deal with someone else completely ruining a project?

Question

For the company I currently work for, I've written a quick prototype to add some stuff to an instant messenger. Because it had no public APIs, I had to work on a really low level stuff using both C and inline assembly. It's interfacing with an undocumented DLL, which is pretty picky about it's input, and although I've spent a great deal of disassembling it, there are still some concepts that I don't fully understand.

Recently, a new version of the IM app was released, and changed a lot in that internal library (as was to be expected). Naturally I'd taken some precaution for changes like this, but they made one huge change that I hadn't anticipated. Fixing this prototype myself would probably take about a week, and would probably take a near complete rewrite. The problem is, I'm swamped. My contract runs for another month, and they are expecting me to finish two other small projects before that time, and I'm not sure I'll make that.

Naturally my boss wants to give it a try, but he's completely under qualified. He has no knowledge of C or ASM, has never actually disassembled anything, and only really has experience with C# and (claims to) SQL. He's done some C code in the past, but the main reason they employed me for this was basically because their low-level code crashed... a lot...

How on earth should I deal with this? I've spent about an hour trying to explain the current prototype to him, but I have the feeling that he doesn't grasp any of it. To me it seems I have only three options, neither of which sound very appealing:

• Don't interfere at all, which will likely have him fail the project miserably, or deliver something that will be full of memory leaks (remember: this is something that runs in-process with the IM program, if it crashes, the IM app is going with it)
  Another downside to this would be that he'd probably be asking me a *lot* of questions, keeping me from my own work.
• Try to cram the project in my already cramped schedule: doesn't look very good for my stress levels
• Hold his hand through it hoping he'll learn from it (will probably take longer than doing it myself)

Basically: I'm currently the only one in the company that knows any of this. I don't have time to work on it myself, and I don't actually have time to educate someone else about this. Obviously I don't want to leave the company with a crippled product, but I'm also not very fond of doing all-nighters to save them from it... (I'm already making way more hours than mentioned in my contract, even though I'm paid on a monthly basis)

Answer 1

Don't be bullied into unachievable deadlines.

You obviously have a good handle on what the problems are. Put them in an email to your boss. It would also be good to say what your preferred solution is. Let's assume for the moment, it's another 6 month contract where you do the work properly.

At the moment, it sounds like you're being played. Either stand up to it, or run away as fast as possible. Otherwise, you'll leave the job with a horrid taste in your mouth.

Just my $0.02.

Answer 2

human problems are so difficult.

be straight-forward. don't tell your boss that s/he's an incompetent boob of a coder, but do be up front about your concerns about hours and such. if the boss decides to do it, then realize that you can't control everything. sometimes other people need to be allowed to make their own mistakes and do it their way. help all you can, as graciously as possible, and be sure to police yourself to make sure it doesn't make those hours worse. if it does, call him/her on it.

Answer 3

Forget about it and let your boss get on with it, and concentrate on the other projects more important to you right now. Try to distance yourself from what he's doing, explain to him you have to prioritise what you're doing elsewhere. Experience will help him to better find out ... than any help you can give him.

Answer 4

In a no-win situation, you should err on the side of self-interest.

Answer 5

Stop caring. I know it's hard cause essentially we end up with "babies" when we create or seriously fix code and can start to adopt a paternal attitude towards the state of that software.

However look at this child. This is a reverse-engineered bastard child that should never have been and requires and will continue to require a huge amount of maintenance due to it's nature (as an undocumented plug in).

The people who want this child to exist are not extending your time or even paying you by the hour so they do not seem to appreciate the difficulty of raising this kid effectively. In such a case you have to cut your paternal ties and stop caring as you are probably not even the legal guardian, just the carer.

I would suggest explaining your concerns, offering to do the work IF you get paid by the hour and with generous overtime rate and if that is not accepted then let them go ahead and mess it up themselves.

Answer 6

Repeat after me:

The project is not my baby.

@Quarrelsome said the rest of what this post would be much better than I can.

Answer 7

1. Can you pawn off the two smaller projects on your boss to allow you to focus on the bigger one?
2. Can the bigger project be done, if some style and structure is .... lost?
3. Can the bigger project be done if you incorporate some quick hacks to speed up your progress?

Contracts are interesting. If I am an employee, then I work my alloted hours, and do the best I can without over exerting myself.

If I am directly contracted, I promised X on this deadline, I undershot, I have to make it up.

Hope I help a little. Sorry your in such a bummer situation.

Answer 8

Its all about learning how to manage your manager, setting expectations and controlling perceptions.

1) Make sure your boss knows exactly what it is: a horrible hack. Explain all the reasons why it is unmaintainable and the sort of problems associated with it going forward.

2) Be honest with your boss about him maintaining it. Explain that all this requires a great deal of programming knowledge and one wrong move can cause the whole thing to be unstable and unusable. AND that you're concerned it will be a huge time-sink for both of you.

3) In the worst case - he goes ahead and hacks on it - when he bugs you for help, make him choose between slipping the schedule of what you are currently working on and helping him with the Frankenstein. Say, "Yeah, I would be happy to help you, but it would push out what I am working on by xyz amount of time. Is that what you want?" Communicate that any schedule slippage was a result of him asking you to work on this other stuff.

Answer 9

I would reccommend that they don't install the upgrade to the IM if they want to continue using the "prototype".

Then, I would appologize profusely for doing such an unproffessional and unsupportable hack to an existing application and offer to investigate how to implement that functionality in a simpler and more sustainable way (other IM clients with extendable architectures for example) - on your own time.

As a contract developer you should hold yourself to higher standards than if you are a regular employee, because everything you do is most definately going to need to be supported and maintained by someone else.

Ron

Answer 10

Your boss isn't an option, you know the reasons why, you wrote them down.

I would argue for not using the new version of the IM application, but shipping your system with the old version, on time, without doing extra work. The underlying infrastructure changes sound too massive. It's only a prototype, don't do more than is necessary. If the client wants to take the full implementation forward based upon the prototype, fine, give a reasonable quotation and indeed contact the IM application company itself and enquire about stable APIs for your needs.