Ethical dilema?

Ok heres an interesting scruples question:

You are in a software development job, comfortably paid but in a stressful environment on a project that ultimately is doomed to failure. One of the many problems with the project is VERY high staff turnover.

High staff turnover has led to an almost impossible to understand architecture, very poor documentation and low understanding and skills all round.

You suspect that with each attempt to meet various functional requirements your work is actually degrading the quality of the overall project further (rather than moving it toward completion). This is primarily due to a lack of understanding of any of the system architecture (if there is any coherent architecture) and an awareness that 'getting things done' means complying with various worst-practice anti-patterns and generally insufficient motivation to learn.

You know a new job elsewhere is on the horizon having discussed informally with your future employer all sorts of details so its only a matter of time before you get to leave the sh*t behind (accelerating the general attitude of ambivalence).

Which is the ethically correct path to take:
a) Work as little as possible so you introduce as little of your 'toxic' code as possible into the project
b) Work to achieve as many functional requirements as possible and to hell with best-practice.
c) Spend weeks learning the architecture in an attempt to try and re-architect some kind of an improvment knowing full well you'll probably leave before you get anywhere.

It would be better to document your understanding of system architecture for the next person to learn and then attempt to add other functional features, following bets practices and refer them as prototypes for next developer. That sounds like a better plan to me...

At least have a proper process in place moving foraward.

Sound like a Death March.

Ethically speaking, I'd do the best I could to make the project as workable as possible, including suggestions on how to make it more workable, even though it's apparent they'll be ignored.

I draw the line at letting employers kill me - doomed project or not - but playing the game out is only fair.

I prefer to do:

1. Work as much as possible with best quality of code with out disturbing the existing code and future developers should not have problem with my code.
2. Document everything that I understood related to project like the architecture, domain knowledge etc.,
3. Also I will document my findings regarding the areas that we can improve.

I just went through that situation.

I struggled for three years to get proper processes in place, but management wanted quantity over quality. During that time I did my best to do quality work and encourage my team to follow best practices even though it created many battles I had to fight.

When I finally became frustrated enough to find a new job, I took choice (B) for my last few weeks. It is what management had asked me to do all along and there was no reason to start any more battles at that point. I gave them what they wanted for a few weeks and left as quietly as possible.

What goes around comes around. Been my experience thus far.

I strongly encourage you to read "Death March" as Tim recommended.

When possible, I would raise these issues with your boss--but only if you're certain (100% certain) you have an exit strategy and won't be fired and left without a parachute.

I think you should always do what's best for the project. This could be interpreted as

1) talking to your superiors about the problem (again, if you'll get fired for it, it doesn't help, so don't do it in that case)
2) doing what you think is the right thing to do in terms of technical decisions (e.g. producing better quality code)
3) following the procedure set forth by company policy, even if it means poorer quality code (e.g. the PM said skip all testing, we just need to get features done, eve if they're buggy--he may have valid reasons for making this call and you just need to trust him)

There are probably other interpretations as well but I would feel comfortable with any of the above (generally, in a specific case some may be preferable to others).

--Mark

Originally posted by Mark Herschberg:
(...snip...)
I strongly encourage you to read "Death March" as Tim recommended.

I have a experience ( not in programming - just generally ) with the issue to which the cited title applies it's efforts. I glanced at it on a cakewalk at bn. I put it back.

That, exactly that - and no other is why I position myself as not worried about my reputation. It is not that I do not care, nor is it that I steel myself from the pressures therein. It is just that at some point, like Marines, there is only one true path.

This is one of those situations.

No it's not ethical dilemma.If your ethics really pinches you then just continue with your current job and give your best. (pinched?)

I agree with Tim. It's really a Death March. I haven't read this book but the title and cover page tells much.

Practically, What you can do is, during the knowledge transfer period you can give most information to the new comer. Let him aware about the wrong things (though it won't help anyway). As you mentioned they haven't followed any design patterns and coded very badly.
In this case what best he can do? He can implement good logic. But the way project has been developed, he can't change that one.
For example, if they haven't followed any framework Or view layer and the DB layer are tightly coupled. So it's better to code it from scratch rather than making root level modification.

As it's an ongoing project, the company will have to cope up as soon as possible otherwise only client knows what he can do.
It's all about company's reputation. In this much pressure how can we expect that that new comer will even think to make it better. All he will do is continue with that ugly code implementation and finish it as early as possible. That's why it's called a DEATH March.

Ultimately, the company loots the client.(bit harsh).

By the way when do you join your new company,Alan?

Originally posted by Vishal Pandya:
Ultimately, the company loots the client.(bit harsh).

By the way when do you join your new company,Alan?

No "Company/Client" relationship here - I'm contracting direct to a government department... Project has been going for years and has consistently failed to have a development team to fill the planned 'resources'. People leave faster than they can recruit new people and the rapidly revolving door has created a spectacularly low quality code-base! I've been here for a little over 3 months and am one of the longest serving members of a 12 strong team (with project plan based on 18 resources) on a project thats been in development since 2003! By the end of May its likely that 3 more developers will have left including me and that the longest serving developer will have been here for 8 weeks...

This particuilar government department is already all over the press for IT crew-ups on other projects and its quite possible that at some stage this project will be canned as bean-counters realise that its a bottomless pit of spending!

I havent actually cemented the deal on my next job yet (although its very much a friendly handshake 'nod and a wink' recruitment process rather than a traditional job application since I know the people involved, they know me love the idea of me me coming on board). I expect we'll get it sorted out in the next couple of days and I'll probably be out of here in less than 2 weeks.

I recognize this situation well, get the hell outa dodge.

I had the same situation in my previous company. I have no choice other than changing the job. I changed my job and joined a new company. I did documentation for whatever I know/found wrong. I did knowledge transfer to the new comers as much as I could.

Unfortunately, I was involved in that project for about 8 months and the time allocated to me for knowledge transfer was only 3 days. I saw newly joined people sleeping during the knowledge transfer especially in the post lunch sessions. I woke them up and gave them a tea and starting giving knowledge. I don't think they grabbed everything in 3 days.

This project was doomed because of poor management. Our manager used accept whatever client says over the phone at any moment. Mostly phone conversations used to take place between manager and client and none of us aware of those discussions. Those discussions were not even documented for later reference. Developers were forced to change their implementation at a very later stage even just before the delivery. I tried to introduce iterative development concept (I am a fan of Agile) and my manager (PMP certified? ) looked at me as if I am a fool.

So, I gave up and jumped

Originally posted by Sai Surya:
... I saw newly joined people sleeping during the knowledge transfer especially in the post lunch sessions. I woke them up and gave them a tea and starting giving knowledge.

Originally posted by Sai Surya:
I don't think they grabbed everything in 3 days.

I don't think they grabbed anything in 3 days.

Originally posted by Sai Surya:
I tried to introduce iterative development concept (I am a fan of Agile) and my manager (PMP certified? ) looked at me as if I am a fool.

Could be because of inferiority complex or corporate politics (upper level pressure)