Live data from Hacker News

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

programmers.stackexchange.com

101–110 of 163 posts

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

#101

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 think what you're looking for is some sort of workers' cooperative.

I disagree with the philosophy of your profit distribution. For one, it overstates the value of the first employee and shits over the rest. If the first employee has been at the company ten years and the second nine, it is unlikely that the first employee is twice as valuable as the second employee. For another, I think the elimination of pensions is one of the biggest things wrong with modern corporations.

What I favor is something more like a formalized version of the traditional family farm or business. Everyone gets a share of the business proportional to how much work they put in (years worked, with some minimum to retain your shares after you quit working). Profits are divided among them, and salaries are paid to current workers before profits are calculated.

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

#102
post #30

Honest, "be slightly evil" answer: say absolutely nothing. Just work. Get done what is asked of you. When you have free time (which you often will, due to the chaos as things start to shake) use it to build skills for your next gig. People will probably lose jobs. Sometimes that will happen based on seniority and sometimes it's just random. Sometimes, that will happens to the PITAs who spoke up and happened to be rig…

With this behaviour probably you will survive this project but in the long run, you will be wasting your life and maybe miserably unhappy in the end.

I'm not saying he needs to stick with the project. I'm saying that it's, on average, bad for your career to try to save a failing project. Better to move to one that will succeed, but you don't get mobility by offending everyone around you, which is often what happens when you try to "save" people in spite of themselves.

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

#103
You should treat the project with extra effort. You have 1.5 months to go. This is what you know. You are signed on to a project. The project at hand sucks. The inner politics can not be manipulated. With you knowing all of these factors, maybe there is a way you can change the outcome of the project. At the least you gain something from this project.

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

#104
I had this issue.

I worked very hard to put the project on the right track, but the issue was the person at the very top (my boss) just wound't listen and do things his way every single time.

Twice, I worked for months on new features that we discussed and outlined only to have the project be completely re-designed (and 90% of my work scrapped) because he had a new dream or a vision about how the project should look.

I eventually quit. It's not worth my time, effort, or sleepless nights.

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

#105
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…

It makes sense if you're absolutely, positively sure that the project is doomed and there's not a slightest hope for it.

But even assuming this, choice (b) is only local optimization. One could consider instead doing (c) - to try as hard as possible to convince the management to shut down that project ASAP, and thus saving the company many man-hours of wasted work. The global gain will be much greater then. Of course if management is stubborn and you're still sure the project will fail, then you're back to option (b).

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

#106

Honest, "be slightly evil" answer: say absolutely nothing. Just work. Get done what is asked of you. When you have free time (which you often will, due to the chaos as things start to shake) use it to build skills for your next gig. People will probably lose jobs. Sometimes that will happen based on seniority and sometimes it's just random. Sometimes, that will happens to the PITAs who spoke up and happened to be rig…

Mr. Church is absolutely right, and I have a telling story from the decline and fall of Lucent to back it up:

The last project I worked on was something essential to Lucent's survival as an independent entity. Many of you have heard of sophisticated telephone switches, like the Western Electric (AT&T) then Lucent 5ESS (http://en.wikipedia.org/wiki/5ESS), a really impressive monster that's truly 5 9's reliable (or it genuinely tried to be and by and large made the grade).

The new way of doing this is (or was as of 2001) to split the functions of such a switch into a Media Gateway Controller AKA Call Agent e.g. the Lucent Softswitch, which understands things like billing, and a Media Controller which does the actual work of connecting A to B and converting as needed (e.g. POTS to VoIP). There's even a dual ITU/IETF protocol for communications between the two, Megaco AKA H.248 AKA RFC 2805.

It should be obvious that being able to offer a complete solution was essential for Lucent's future, as conventional switch sales were at least projected to plummet, and my group was part of effort to create the other half the company needed, the Media Controller. Which was a challenging thing, including that true 5 9s reliability requirement (just say no to hard disks, I was among other things the database guy in testing, and the operational database lead and I had to vet and sign off on each other's designs (mine was a data warehouse approach for storing fine grained events generated by the test system, Oracle was real fun for that sort of thing and we had a 106,000 seat license (!) from them, although headcount was going down to 35,000), and I was personally responsible for testing his system).

ADDED: going off the Yourdon Death March chart included in OP comments, this was a "mission impossible" project, high happiness (fun, challenging project), at least a decent chance of success initially (e.g. we were working with the 5ESS people, who taught us a lot of neat stuff about real 5 9s.)

Anyway, at a certain point, completely insanely a company wide headcount cull was applied to this effort, and I'm pretty sure it was sufficient to kill the project (my testing area was gutted, going from "maybe, just maybe we can get this work done in time" to one engineer plus a little outside help, with one manager, a failed programmer so she wasn't of much if any help).

One of the things that really stood out was the layoff of a pretty famous person in the company, a jack of all trades who e.g. had the energy and skill to take the chosen (Linux based) RTOS from the vendor and get it up and running in our environments, kick the tires and minimally validate it, etc. Don't know if he was a PITA like I was in part, but it's hard to imagine he wasn't at least a bit, he was the sort of guy who was in a position to say "This won't work because I just tried it".

The managers flaunted his layoff like a badge of honor, an implicit "If this guy can get fired no one is safe", and blatantly lied about the grounds. They claimed he was "inflexible" about what he'd work on, when it was a very visible matter of written record that he'd very productively work on just about anything. I never even talked to this guy, I just learned of his background and merits from the written progress reports and mention of him in an occasional conference call meeting, he was perhaps the most visible "exceptional" employee in this make or break project.

And yet he was purged.

(As was I, although that was by abuse from an envious boss and may not have even been part of the headcount cull; while I wasn't hardly so visible, I was the only serious software engineer on the testing effort, and there was no way the company could build the new test system without someone of my caliber. And you'll never create a true 5 9s system without serious testing.)

And as many of you know, the bottom line is that Lucent was bought by Alcetel and is a shade of its former self, including Bell Labs, e.g. http://en.wikipedia.org/wiki/Bell_Labs#2000s:

"As of July 2008, however, only four scientists remained in physics basic research, according to a report by the scientific journal Nature.

On August 28, 2008, Alcatel-Lucent announced it was pulling out of basic science, material physics, and semiconductor research, and it will instead focus on more immediately marketable areas, including networking, high-speed electronics, wireless networks, nanotechnology and software."

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

#108
post #30

Earlier quoted context omitted.

With this behaviour probably you will survive this project but in the long run, you will be wasting your life and maybe miserably unhappy in the end.

"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 don't think michaelochurch is saying that. Rather, sometimes you look out for #1, which involves doing your best and setting yourself up for long term success.

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

#109
post #30

Earlier quoted context omitted.

With this behaviour probably you will survive this project but in the long run, you will be wasting your life and maybe miserably unhappy in the end.

I'm not saying he needs to stick with the project. I'm saying that it's, on average, bad for your career to try to save a failing project. Better to move to one that will succeed, but you don't get mobility by offending everyone around you, which is often what happens when you try to "save" people in spite of themselves.

Exactly; I have a bad habit of saving failing projects, generally of companies that had to have them succeed, and very seldom got any thanks from it, even when I was explicitly hired to do just that (sometimes was even purged when technical success was achieved but not cemented, causing the company to later crater). If there is a gentle way of doing this it was beyond my limited interpersonal skills, and I agree with everything Mr. Church is saying here, if you can pull it off (I can't): keep your mouth shut while you pull the ejection handle.

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

#110
post #82
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.

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

No, he wasted valuable time and company resources attempting to do something that wasn't needed, or asked for, and provided no value (arguably negative value) to his team in doing so. Of course people work hard and aren't rewarded for it, but it sounds like it's the case here that this cowboy was trying to outwit the system and ended up hurting the team a lot with his irresponsibility.

Post reply on HN