Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How should I behave as a developer in a project that's headed for failure?

programmers.stackexchange.com

Post reply on HN
Print view View original

111–120 of 163 posts

Re: How should I behave as a developer in a project that's headed for failure?

#111

Post by brudgers »

VLM wrote: post #69
brudgers wrote: post #50

Earlier quoted context omitted.

Right on. Working conscientiously when easy excuses for doing otherwise are in season is the essence of professionalism. Providing one's best given the circumstances is the core character trait. Deadlines move, budgets expand, requirements shift and staff move on (including managers). All are beyond the line worker's control. Sometimes, life includes a deathmarch. You still gotta' throw strikes when trailing by thirt…

"All are beyond the line worker's control." This is probably the most important piece of advice in the whole discussion. Getting all worked up about someone else's responsibility. Another interesting side issue not explored yet... I believe its a distorting factor that he has semi-privileged information and opinions about his own area of expertise. If he had semi-privileged information and opinions about the supply o…

Real businesses can be messy and inefficient and petty and stupid and still turn a handsome profit. They usually don't participate much in our Platonic ideal of one.

One of the tracks of the discussion here and on Stack Exchange is to elevate the situation to a plane requiring moral decisions. And it just ain't so. A line worker does not have fiduciary responsibility, and as you rightly point out, this doesn't entail issues of life safety, public health, or economic exploitation.

It's just normal muddling through.

The biggest hazard to the person posting the question on StackOverflow is erroneously assuming they are the smartest person in the room, or in its most common form, that everyone else is an idiot. Trains are big loud whistling contraptions with bright lights. Unless distracted, few people fail to see and hear them coming.

Re: How should I behave as a developer in a project that's headed for failure?

#112

Post by rikacomet »

Approach A: The more stenous one, which requires a lot of willpower, moral, positive attitude, and undying zeal.. is to point out the mistakes being done, in a respectable and proper manner on proper stage, where everyone can take it in a non-hostile way. This approach assumes that the current leadership is not capable of steering the team out of the wrong path, and since you can see the problem, you are more than ready to take the baton in your hand.

Approach B: Stay back, perform at 110% but not 120%, if asked, then give your opinion on mistakes being done, do what is your duty, but don't go '"way" out of your way'. Since people might become hostile to you, and don't care if the ship lives or dies. This requires a cold heart, professional and non-positive. But we have to do this a lot of times, due to the behavior mismatch between co-workers. Sounds bad, but deal with it! That's how it is.

Re: How should I behave as a developer in a project that's headed for failure?

#113

Post by zenlikethat »

rquirk wrote: post #33

Thing is... a lot of projects seem this way when you're in the thick of it, but towards the end the mess can untangle itself and provide a useful tool/product for someone. > Application is unstable and very difficult to use. Could be that there are a couple of "killer bugs", fix them and it might not seem so bad. Difficult to use is also subjective, people get use to stuff. > System is very convoluted, code very hard…

Interesting take, in fact recently I was working on a project that I was convinced was going to be a huge mess but in the end out clients seemed fairly happy with it, and understanding on inevitable roadbumps.

> OK, this one I can't defend :-P

I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data?

Re: How should I behave as a developer in a project that's headed for failure?

#115

Post by [deleted] »

Yourfags wrote: post #70
addandsubtract wrote: post #47

Earlier quoted context omitted.

"Do as you're told" and "Don't talk back" are probably the worst "rules" I've been taught in US grade school. Following that mentality will net you exactly this: a miserable and close-minded life. DO voice your opinion and professional expertise. DO make recommendations as to how to salvage or improve a project. Not doing so will not get you anywhere.

I love how this idealism is so accepted here, sure it works, but there is plenty of good in "staying until the job is done", you just don't believe it.

[deleted]

Re: How should I behave as a developer in a project that's headed for failure?

#116

Post by PaulHoule »

edw519 wrote: post #3

Choose from 2 extreme alternatives: a. Treat this project as if it were your sick child on life support. b. Treat this project as if it were a gazelle being ripped apart by a pride of lions. If you choose (a), do anything and everything you can to save it. Be open and sincere and stop at nothing. If you choose (b), prepare a resume and run the other way. No sense risking your own well-being on a lost cause. The worst…

There's a good idea here, to manage your level of commitment, but it's lost in the idea that it's a binary decision.

To get high performance without burnout it is necessary to switch from complete engagement to complete disengagement every few hours.

The Serenity Prayer from Alcoholics Anonymous is asking for the right thing here, even if you aren't religious.

"God grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference."

It's great to be passionate but it's also important to be detached about things you can't control.

One detail that is missing from this story is the nature of the deadline. Lateness is endemic in software development, and successful projects often get delivered years after they were promised. Late doesn't necessarily mean "failed."

You can't go wrong learning more about project management so you can have a more correct understanding of the situation.

Whatever you do, keep your honor. Being ambiguous about wanting the job gives you the unique freedom to refuse any order that you truly don't want to carry out.

Re: How should I behave as a developer in a project that's headed for failure?

#117

Post by PaulHoule »

CodeMage wrote: post #94
Spooky23 wrote: post #64

Earlier quoted context omitted.

So do a death march or quit? Very extreme. Unless you're in a tiny company that will literally go out of business if the project isn't complete, there is a valid middle ground: cover your ass to avoid blame, pitch to the PM to get the schedule extended, salvage as much as you can, and move on and do better next time. In the meantime, take a better job if one turns up. But don't be lured into extreme action by magical…

Maybe it sounds extreme, but I agree with @edw519: you don't want to work at a place that lets a project fail as badly as the OP described it. I've been in situations like that too often and I've learned that particular lesson too well. Like @angdis said elsewhere in this discussion, projects "fail" all the time, but the OP is talking about a specific kind of failure. Notice how many commenters mention "finger-pointi…

I think that level of "failure" isn't exceptional in the field.

It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B".

"Team B" usually finds many deficiencies at work in the code. For instance, people frequently bungle the design of 10-table databases, so perhaps there are dragons in the 100s of tables.

"Team B" sometimes delivers the product, usually late. Sometimes it doesn't.

That's life. The Gartner Group says that 2/3 of all IT projects fail and I think that's about par for the course.

Re: How should I behave as a developer in a project that's headed for failure?

#118

Post by 6d0debc071 »

vidarh wrote: post #48
sillysaurus wrote: post #15

Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not try to impose your conclusion on them. Management must always have the choice of what to do, but it is your job to assess and communicate the situation. Use email, so as to leave a paper trail when things go south. I hope future historians will be astonished that all of us chose…

I've had employees try to the "build a better solution" approach behind my back. The big problem with it is that it assumes the person actually has the full picture. In a small project, that may be the case. But often it isn't. In the case I have in mind, said employee delivered a solution that did in fact do most of what our current solution did very well with little complexity. But it utterly failed to account for…

> Often the direction is set by managers for good reason: Sharing every bit of detail would paralyse even relatively small organisations.

Sure, if you sat everyone down and gave them a briefing on every aspect of everything it would be a pointless waste of time. However, increasing the ease with which information can be pulled down seems fairly simple. If dependencies being complicated is the reason for management setting direction, that seems like a coms problem, the sort of thing that's perhaps best addressed with a project management software than a human manager.

Re: How should I behave as a developer in a project that's headed for failure?

#119

Post by jaredsohn »

One thing learned the hard way is that if you are working for a contractor on a project managed by civil servants (especially where the lead civil servant used to work for the contractor), "success" isn't necessarily completing the project on time.

Re: How should I behave as a developer in a project that's headed for failure?

#120

Post by btilly »

bjourne wrote: post #82
vidarh wrote: post #48

Earlier quoted context omitted.

I've had employees try to the "build a better solution" approach behind my back. The big problem with it is that it assumes the person actually has the full picture. In a small project, that may be the case. But often it isn't. In the case I have in mind, said employee delivered a solution that did in fact do most of what our current solution did very well with little complexity. But it utterly failed to account for…

> But it utterly failed to account for the strategies that were in place for future functionality, that placed very different requirements on the platform. In other words, he pissed management off. He busted his as off trying to improve the product and was rewarded by being treated like shit. It really sounds more like he was railroaded by company politics by stepping on the wrong peoples toes.

I've watched this scenario play out on multiple occasions, in different variations.

In one memorable case, the developer missed some pretty important requirements that mattered a lot to management but did not matter to him. The developer certainly felt that he was railroaded by politics. But I, as an independent observer at the same level, could easily see that management was right to want what they wanted, and that the developer was too emotionally invested to see what he was missing.

Same company, same team, same developer, a different project, not too long earlier. He went off and developed something that really did meet the needs we had, and got rewarded for it. The difference is that he actually understood the requirements and nailed them.

Drive, ambition, technical chops, and an unwillingness to listen first can get a lot done, very quickly. The same characteristics can create a lot of conflict very quickly as well. It is hit or miss which happens in any particular case. And on the misses, management is easy to blame but they are not really to blame.

Post reply on HN