Live data from Hacker News

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

programmers.stackexchange.com

141–150 of 163 posts

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

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

Do not understand someone else code, is a valid issue, if the project was development for a few month. Then team got switched around this is a huge RED flag by itself. Big question is why this happened. Staring at a large code base with 1.5month to finish it, no tests, probably zero documentation and manager who used to manage the previous team.. RUN not walk away from this

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

#142
post #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 i…

"...and patent trolling." (FTFY)

http://arstechnica.com/tech-policy/2013/05/newegg-nukes-corp...

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

#143

Earlier quoted context omitted.

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

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

#144
post #126
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…

I haven't really thought of marketing myself that way, but that is a great idea, Thanks.

I guess I've never thought about it because I'd imagined that it'd be such a niche skill that it would be difficult to build a consulting practice around it. People are always looking to build new things. But, they're maybe not as welcoming to talk about their failing projects.

Anyway, I have probably (inadvertently) turned around a good 12-15 projects that way. So, I definitely have results. But, the results aren't typically super pretty. That is, it gets people to the next step, to the next set of funding, to the horizon, at least. Some of these projects and companies that I've helped have been sold, and resold, because of these types of efforts, though.

As for adding a developer to the testing role - it is an interesting idea; I've never tried it. Typically, at this point people are scraping the bottom of what they have left to spend. So, it may be a hard sell. I could try it.

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

#145
post #142
post #106

Earlier quoted context omitted.

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 i…

"...and patent trolling." (FTFY) http://arstechnica.com/tech-policy/2013/05/newegg-nukes-corp...

Oh, yeah, how the mighty have fallen. They are both practicing (they do make real stuff) and patent trolling in areas where they aren't practicing.

"Sleazy" is not, I gather, a word that typically used to be associated with Alcatel, and certainly not the pre-breakup AT&T.

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

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

I do a fair bit of failed-project-rescuing myself, and I concur with most of this. It's good advice. The only thing I'd quibble with is this: Don't think about the sunk costs. ... not because I think it's bad advice (it isn't), but because if you're a developer it doesn't really matter what you think about the sunk costs. What matters is what management thinks about them. And even though management are supposed to be…

Echoing both ap22213 about reorgs, and you, after that threshold of official first try failure has been reached, one thing I learned the hard way is that that if the people responsible for the mess are not completely removed from the effort they'll tend to do everything they can to make the new effort fail, since only its failure validates their failure.

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

#147

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…

I definitely agree with michaelochurch to avoid being a PITA, being right that project will fail isn't productive professionally or personally. Being the person to tell a smoker that they are likely to get cancer isn't helpful to them or you.

If you're going to stay around pick something that you think is the most important function/feature and make sure that it is amazing. There is almost always some smart people around and some new things to learn.

Taking responsibility for things over which you have no authority will make you miserable and crazy. Find out where your authority stretches and make the most of that area leads to amazing developments. I can predict that the education system will continue to suck tomorrow and there isn't much I can do about it but tutoring a few students at my local school can really make a difference in their lives.

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

#148
post #128
post #82

Earlier quoted context omitted.

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

Do you honestly not see how someone that takes an initiative like that could be an incredible boon to a company? When you punish people like that, what you're left with is an office full of drones that does exactly what they are told, nothing more nothing less.

The situation you're describing is a management failure of epic proportions. Failed to communicate future planned features to dev team. Failed to exploit someones willingness to take responsibility. Failed to get input from the programmers (obviously at least one of them thought the code base was a mess).

Oh, and hiring someone who believed making a good product was more important than following chain of command. Big mistake there.

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

Even construction workers always knows what they are working on and why their work is important. If management is unable to communicate to the developers what purpose their work serves to the company then that is incompetent beyond belief.

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

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

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

What? That is the one thing that stands out as being an obvious "this person has no idea what they are doing" red flag. It doesn't need defended. Having 100 tables is not a problem, in any way. Thinking that having a correct database is bad speaks very poorly for the quality of the developer in question.

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

#150
post #138

Earlier quoted context omitted.

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?

> 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? Maybe it's my lack of imagination, but I can't think how you'd create a design with hundreds of tables by hand - it would surely involve generating tables from some other source. For different types of data I'd lean more for a javascripty-style meta-table with key-values, si…

Have you never worked on a reasonable sized application before? 100 tables is entirely ordinary and expected.
Post reply on HN