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

121–130 of 163 posts

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

#121

Post by LarryMade2 »

One, own the project, think of what is the best approach - maybe a rewrite...

Fess up, let them know what is wrong (since you aren't the one that created the mess, offer to be the one than can fix it... if you can do...). Do triage examples on what is there, offer solutions to potential problem points, give examples of a more perfect world. Make sure to point out things that worked good ideas (you are going to hurt feelings, but never tell them the whole concept was idiotic. Show there was good effort and value created in the current system - probably the analysis was spot on, and that's when a lot of the problems were realized and now it needs a rework.

An excuse wont look good on a resume.

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

#122

Post by orangethirty »

This one hits me straight to the heart. On January of this year I was involved on a big project. The company needed to have a piece of software written with their own custom ReST framework. The framework was/is undocumented, and was still under heavy development. The software I had to build had some requirements, but the actual design was not set in stone. I was given a "technical document" and told to build it as is. Turns out, the document was wrong, and did not follow their conventions of even architecture. I talked with the person in charge and we changed the architecture to have it fit correctly.

But the client was asking for ridiculous terms. They were using Python/Gevent to handlea lot of connections at the same time. They had already achieved 3K connectionns in testing, and wanted my software to handle 30K per second. Ten times what they had achieved, in two months. Yeah right!

I knew the writing was on the wall. But out of loyalty I decided to stay. I got fucked when the project was cancelled, because I wasn't paid for a months work. I really didnt pursue it because I just wanted to move on from it. And was in a good enough financial situation where that money really wouldnt make a big difference. I did learn a lot from it, and will now cancel a project if it shows signs of too much drama. There is nothing to gain in sacrificing yourself for others who dont appreciate it.

The team who hired me? They tried to blame it on me. But their company is so fucked up that they were even the focus of a mayor PR incident during the past months. So much about being a great company to work for.

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

#123

Post by raldenhoven »

I don't get why there are so manny comments on the blame game.

FIRST! If the project fails, you all fail. Every member is responsible for the succes of the project.

SECOND! You're career, you decide at which level you participate. Choosing a carreer path as a developer is great, most of the time you are the last person to work on the final product. This means that most of the time you are directly linked to the final quality, do you want to be known as the person who makes crappy quality? If not don't deliver crappy quality.

They might seem very harsh, but there are very few clients who actually understand what you are doing as a developer. They don't hire you for you're code, but because you are part of their solution to their problem. For myself I set a certain level for the endresult, being a developer we are the final ones to touch a product. This means we have to be sharp on every single deliverable someone before us made, if it doesn't meet my quality I am responsible to get it at my desired level.

When reading the post it seems like all grip on the client is lost, before doing anything you're team has to regain control. If the client had the knowledge to solve his problem, he would not need you're team.

Second you already know you won't be able to finish te product before the deadline (and maybe never, because of the legacy). Not loosing any more money on it might be the biggest success available, development is just one part you are losing at this point and in my experience other roles (like interaction/design/frontend/concept/sales/project management) are also part of the solution (and are able to take more then 60% of a budget).

So be part of the solution...otherwise you're part of the problem.

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

#124

Post by Domenic_S »

sillysaurus wrote: post #57
PaulHoule wrote: post #29

Earlier quoted context omitted.

"...There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks" These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of t…

These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality. Well, I've done it. I've developed complete solutions to business problems that the company was trying to solve. I did it without waiting for permission or for my design to be ap…

GP said the weekend. You did your thing in a quarter.

Maybe I've been lucky, but in nearly a decade of technology work I have never been penalized for 'overstepping my bounds' by improving something important. I think improving important things is within everyone's bounds, tbh.

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

#126

Post by kvnn »

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…

In this landscape, that can be a lucrative specialty to have. Do you actively market yourself as such?

> Sometimes it's better to cut the team down from 5 to maybe 2-3 instead of adding more people

Tried and true.

> If there isn't one, stand up an automated test harness with as many tests as possible

What do you think about adding on another developer to just do testing? What about a full-time QA person, so that you don't have to build automated tests?

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

#127

Post by onemorepassword »

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…

How about, sit back, watch what happens and learn.

Even if one of us calls it right, which is sheer luck with so little information, the OP clearly has most to gain from experience.

That is the only way to learn to correctly identify problems, and perhaps more importantly, what is the best way to deal with for you personally.

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

#128

Post by vidarh »

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.

Did you actually read what I wrote? Including the sentence you quoted?

He busted his ass to deliver something un-asked for that didn't meet more than maybe 5% of our requirements and didn't improve the product in any way, rather than doing the job he was paid to do, because he decided he knew a better solution without knowing or understanding what the full requirements were.

Had he come to me and asked if he could do an experiment to see if he could rebuild part of the system simpler, we would have discussed the idea with him. If he gave me reason to believe he could meet the full requirements rather than what he thought the requirements were, we would certainly have entertained the idea of giving him time to prototype something.

But he didn't. He made a ton of assumptions that were mostly wrong about what the system needed to do, because he was not privy to e.g. the strategy discussions the board and executive team had, and the discussions we'd had with investors.

That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots. While doubtless sometimes they are, a lot of the time they simply have more information than you.

Post reply on HN