Hacker News Reader

Comment by Spooky23 | Hacker News Reader

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 thinking. If a failed project is inextricably linked to your personal well-being, you're in the wrong business.

View on HN

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-pointing" and "paper trail". When you find yourself in a situation where that becomes important, it's time to consider leaving and it's always better to leave on your own terms.

Unless you're deeply invested in that project or that company, it's usually better to start looking for a place where projects fail more gracefully than this.

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.

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

First: why is that? Are there good reasons for this, and does this happen for those reasons?

Now, knowing nothing about the company, if I learn that every other project suffer a change of team before going into maintenance (officially and actually), then it's substantial evidence that something is wrong with management.

Whether one should quit of course depends on how wrong.

That percentage is about right for all organizational change. The data also suggest that implementation, not bad ideas, is generally to blame. Possible solution: change the situation where you do have the influence. Work across all the dimensions of people, tech, & org process to find how you might make a suggestion that will stick. I gave that advice to 40 folks just yesterday in class (I teach org design & innovation management at Santa Clara Univ).

I wonder if a company culture that is heavy on blame when things go poorly is conversely liberal with praise/rewards when things go well? Might not be that bad of a place to work if so.

In what universe would this hypothetical company exist? There are plenty of companies organized solely around blame and finger-pointing. They are terrible companies that no software developer should tolerate.

Dreams are free. In the real world, management will typically take all the credit if things go well, for the same reasons as they'll blame-shift and arse-cover if things don't.

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 undocumented business rules.

It's so important, that a project is well managed, because a lot of the aspects of building something new are extremely satisfying to work on. However with mismanagement it's easy to demoralize the team.

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

Reply on news.ycombinator.com