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

81–90 of 163 posts

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

#81

Post by smackay »

ctdonath wrote: post #24
smackay wrote: post #9

I'd be hesitant to raise concerns, on what appears to be a relatively small project, in case you become the scapegoat and a way for either the manager or your colleagues to point the finger at you for not being a team member and hence the reason the project failed. Since it's only 6 weeks to the deadline it is probably worth pitching in and trying to make it work. If failure is going to be a big deal then you'll all…

The rats are first to know what's going to happen because they're deep in the bowels of the system - dirty, dank, ugly, but know the real story. Looking for and taking an exit can be the smart move if you know the boat is going to sink. Being upset at being labeled a "rat" means you're alive. This pervasive "don't raise concerns or you'll get targeted" is all too often WHY projects fail: people keep telling the decis…

I completely agree. It is the short timescale that makes toughing it out worth considering. If the project had several months to go and not just six weeks then speaking up or getting out would be the correct courses of action. From the problems described in the OP it seems unlikely any fixes can be applied to avert disaster.

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

#82

Post by bjourne »

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…

> 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.

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

#84

Post by josso »

maarten-pi wrote: post #75
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…

I agree, that the previous comment sounds extreme, there often is a middle ground. People can be reasoned with, otherwise the company you're working for doesn't sound like a good place to be. Taking a better job is fine, but halfway a project it might kill the project when some of the top guys decide to leave. It might even be worse when the architect of the legacy-system decides to leave with knowledge of all the un…

> Taking a better job is fine, but halfway a project it might kill the project when some of the top guys decide to leave. It might even be worse when the architect of the legacy-system decides to leave with knowledge of all the undocumented business rules.

Exactly. The world is pretty small and you shouldn't step on somebody's toes unless you absolutely don't see another way out.

The sensitive thing to do here, is to make sure you've got your ass covered and if this is a persisting problem or you feel like you can't work there anymore, then you quit after the current job is done. And hopefully you can leave with a good recommendation.

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

#85

Post by levosmetalo »

ap22213 wrote: post #65
levosmetalo wrote: post #61

Earlier quoted context omitted.

The guy clearly said he is a developer. While your advice is sound, it is something that only the manager has authority and responsibility to do. It is just impossible it almost any organization that a developer can turn project and project methodologies upside down like suggested here. > However, in the end, it is also completely ok to walk away, especially if there's no incentive to continue.

I don't quite agree. I agree it can be difficult. But, if there's sufficient respect between the management and developers, then it's totally possible. The manager wants to succeed, and most are pretty reasonable to ideas, especially when put into a tight spot.

I agree that it's how it should be, but the author of the original question seemed pretty upset exactly because in this particular case it was not like that.

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

#86

Post by larsberg »

One other possibility is that this developer is experiencing schedule chicken. I'd recommend reporting your time estimates to your lead, giving it the old college try, but going home at reasonable times and not pushing the clock too hard.

In some large organizations (I've seen this previously where I worked), the first group to claim that the schedule was unreasonable became the scapegoat for slashing of features. So, everybody would look around and try to get a sense of who was furthest beyond making it and not say anything unless their team was the long pole, since you'd "benefit" from the increased schedule time anyway without the high-visibility hit for failing to deliver.

Yes, totally dysfunctional. But, in some orgs, it may be the most realistic (or at least typical) way to save the scope of the project.

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

#87

Post by jdavid »

ap22213 wrote: post #46

I've picked up so many of these types of projects, it's sort of become my specialty. The first thing to do is to ask oneself if it's worth completing the project at all. All stakeholders _will_ have to be ready to make some sacrifices; is it worth it? Also, like others have said, communication is key. If the team can't have open conversations up-front, it may be best to walk. But, if the team can communicate openly a…

As a Developer, I would buy a book or pay for a class on a topic covering how do you improve team dynamics and strive for success. Most of my schooling and knowledge is from the perspective of building a 'thing' and it would be great to learn how to rebuild a team when management is lackluster. Out here in Silicon Valley there are a lot of inexperienced managers working on good or great products, and as an engineer you might recognize the problems, but not know how to help them, or nudge them in the right direction.

It would be nice to learn from the experience of others rather than having to learn on your own each time.

Maybe this is something to talk about at FAILCON?

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

#89

Post by elorant »

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…

70% of projects fail. According to your options you're either burned out pretty fast by going the extra mile, or you change jobs every couple of years.

IMHO the best thing to do is to express your concerns and from there on just do your job without investing any extra effort. You can't be reluctant cause this will be received as not caring, neither invest the extra effort because usually the reason projects fail is not incompetent programmers but wrong specifications. Let someone else take the blame.

Post reply on HN