Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Developer Stigma After a Bad Or Catastrophic Release?

Soulskill posted more than 5 years ago | from the don't-call-us-we'll-call-you dept.

Programming 223

An anonymous reader writes "We hear in the news all the time about how executives can drive a company into the ground and yet somehow become more desirable to other big companies. What we don't hear about are the grunts who implemented those decisions, and whether or not they end up resume-stained or blacklisted. Since we've got so many developers with lots of time in the trenches, I thought I would appeal to their experience. When disaster looms and sales starts pushing for development that has little chance but to end in disaster, what happens to the programmer who decides he needs his job enough to follow orders? Have they ever become unhireable?"

cancel ×

223 comments

Sorry! There are no comments related to the filter you selected.

In my experience, no. (5, Insightful)

whatthef*ck (215929) | more than 5 years ago | (#28660927)

I've been part of two large, high-profile projects that cratered spectacularly (as I knew they would) and I consider it some of the most valuable experience of my career as a software developer. I've told that to interviewers a number of times. If they don't get it, then I don't want to work for them.

Re:In my experience, no. (5, Funny)

Brian Gordon (987471) | more than 5 years ago | (#28660987)

then I don't want to work for them

Must be nice to be 5 years ago.

Re:In my experience, no. (4, Informative)

Kjella (173770) | more than 5 years ago | (#28661167)

Sseriously, even in the worst of times there are businesses that are growing. Those that do are well aware of the situation and know that in this market they can hire high quality workers at reasonable prices, even the kind of employees no sane employer would normally lay off that they'd normally have to headhunt with huge paychecks. So yeah, many people are in the "nod, smile and say yes if offered a job" mode you shouldn't assume it's that way for everyone.

Re:In my experience, no. (5, Insightful)

dublindan (1558489) | more than 5 years ago | (#28661669)

Agreed. The company I'm working for is doing better than ever. In bad economic times, any company that sells products which will save the customer money in the long run is going to do well. People will spend a lot of money if it will help them save more in the long run.

Re:In my experience, no. (1)

ultranova (717540) | more than 5 years ago | (#28662189)

In bad economic times, any company that sells products which will save the customer money in the long run is going to do well. People will spend a lot of money if it will help them save more in the long run.

Only if they have money to spend. If they don't and are struggling to survive they have little choice but to go with the cheapest option, even if it'll end up costing more in the long run. That's one of the reasons why our society is becoming increasingly stratified, and the basic problem with capitalism: you have to have capital in order to make capital, leading to an exponential growth in wealth differences, and all the social and economical problems that brings.

Re:In my experience, no. (1)

JAlexoi (1085785) | more than 5 years ago | (#28661975)

5 years ago you could be payed for doing nothing. Now the people that are actually valuable get payed well, in spite of the bad economic situation. Value is value, in any economic situation.

Re:In my experience, no. (5, Insightful)

DerekLyons (302214) | more than 5 years ago | (#28661205)

I've been part of two large, high-profile projects that cratered spectacularly (as I knew they would) and I consider it some of the most valuable experience of my career as a software developer.

Yep, and the same thing applies to the executives the questioner slams.

Re:In my experience, no. (5, Funny)

The End Of Days (1243248) | more than 5 years ago | (#28661403)

Class warfare is pretty much the only way the Slashdot team can bring any class to this site.

Re:In my experience, no. (2, Insightful)

Bogtha (906264) | more than 5 years ago | (#28661619)

Not really. If a project is a catastrophe, then that's usually attributable to executive decisions. If the output of the developers caused the catastrophe, then it's usually because the project was mismanaged - not assigning any resources to QA, ignoring risks, handling change requests badly, allowing feature creep, setting unrealistic deadlines, and so on. It's rare that developers are actually to blame for a project going pear-shaped, and when they are, management are often complicit because they knowingly hired cheap developers without experience. The developers are there to write code, it's the managers' jobs to ensure that the project succeeds.

Re:In my experience, no. (3, Insightful)

Savage-Rabbit (308260) | more than 5 years ago | (#28661889)

It's rare that developers are actually to blame for a project going pear-shaped, and when they are, management are often complicit because they knowingly hired cheap developers without experience. The developers are there to write code, it's the managers' jobs to ensure that the project succeeds.

You assume that most developers write good code, which isn't nearly always the case. I have seen projects run into major problems necessitating extensive rewrites because of fundamental mistakes in low level programming and design decisions that were taken by developers, not a bunch of weaselly managers and marketing creeps. You can completely screw up a project by taking the ad-hoc approach to designing an API or a protocol in a way that can be very expensive to fix. I agree that management (or marketing for that matter) usually makes it's contributions to such disasters as well but you can't just absolve the coders, especially the senior techies that do the design work. In the end coders must also live up to a minimal level of competence.

Re:In my experience, no. (4, Insightful)

John Hasler (414242) | more than 5 years ago | (#28662127)

> I have seen projects run into major problems necessitating extensive rewrites because of
> fundamental mistakes in low level programming and design decisions that were taken by
> developers, not a bunch of weaselly managers and marketing creeps.

An executive who doesn't notice until too late that his developers are screwing up is screwing up.

Re:In my experience, no. (5, Insightful)

Bogtha (906264) | more than 5 years ago | (#28662177)

You assume that most developers write good code

No, I don't.

I have seen projects run into major problems necessitating extensive rewrites because of fundamental mistakes in low level programming and design decisions that were taken by developers, not a bunch of weaselly managers and marketing creeps.

But the question is how did the project manage to get into such a state without anybody stopping this? Is there no oversight? That's a managerial problem. Is there nobody competent to speak up? That's a managerial problem. Are the competent people not listened to? That's a managerial problem. Are the competent people so overworked that they aren't aware of what the rest of the team is doing? That's a managerial problem.

When developers screw up, the fault lies with the developers. When developers are allowed to screw up over the entire course of a project, irrevocably damaging the project, the fault lies with the managers.

In the end coders must also live up to a minimal level of competence.

Agreed, but my point is that if an organisation has no such competence in its development team, this is not a problem any developer can take responsibility for; it's a problem with how the organisation is run.

This problem is out of my skillset (1)

symbolset (646467) | more than 5 years ago | (#28662831)

I'm an engineer. This problem requires the skills of someone trained in Human Resources.

Re:In my experience, no. (1)

inotocracy (762166) | more than 5 years ago | (#28662409)

Some of that can be attributed to unrealistic deadlines, pushing the programmers to hard and/or not providing a large enough window to properly spec a project. ..grumble..

Re:In my experience, no. (2, Interesting)

Hurricane78 (562437) | more than 5 years ago | (#28661923)

I very much doubt that. Because other than for us, they do not get punished for it. They usually get large compensations, and leave with a nice reference, shortly before everything crashes. Usually, all the blame then goes to the "end game" manager, who "ran this successful business down so quickly". That "end game" manager usually is a promoted straw-man from a lower level.

So they learn the opposite of what we developers learn. They learn that you can make good money with it, and apply for an even bigger job in the next company. :)
I've seen it myself many times. I always hoped that I just had bad luck with my jobs. But I was not the only one with stories like this. And after all, Dilbert wasn't such a big success in our circles for nothing. ;)

Re:In my experience, no. (2, Interesting)

fooslacker (961470) | more than 5 years ago | (#28662155)

I've been part of two large, high-profile projects that cratered spectacularly (as I knew they would) and I consider it some of the most valuable experience of my career as a software developer. I've told that to interviewers a number of times. If they don't get it, then I don't want to work for them.

Developers blame the project management and architects, architects blame the project management and developers, project management blames the architects and developers and everyone blames politics. All the posts about how much you learned or how valuable the experience was is nice but the truth of the matter is that very few individuals have the introspection skills necessary or the broad view to see what true convergence of horrific behaviors and decisions led to the smoking crater that is the massive software project failure.

The good thing is that with all this confusing and complexity it's extremely rare that anyone ever gets blamed for even their part in the failure much less the whole thing and while some folks might be blacklisted in a small enough company it's almost unheard of for anyone leadership through grunts to be blacklisted in an entire industry or even a big company.

The bad news is that we rarely learn from our mistakes and large software projects continue to fail or succeed when the right random mix of situations and behaviors occur. My first advice would be try to steer clear of massive big bang delivery waterfall type projects, they're ripe for breeding a convergence of bad things that lead to failure and while you won't be blacklisted but you'll still experience the suffering and frustration of a failing project.

More practical advice for those of you who can't or don't want to avoid these situations is when one of these monstrosities fails be realistic. You're working in a high risk environment for this type of failure. A huge project with a team with more than 20 or worse 100 (or even worse 1000) people is courting failure. When you experience failure certainly look at what other people did wrong but more importantly ask yourself, "given this high risk of failure environment what did I do that contributed to it". We tend to see what other did to contribute and place an inordinate amount of blame on their behaviors and mistakes when in truth it is the convergence of a massive number of little mistakes that most often causes failure. Any one of the problems alone wouldn't doom the project but the whole of their destructiveness is greater than the sum of the parts in this case. If you can at least not contribute to that swirl of chaos you'll have done the best you can to help avert disaster. Beyond that just prepare to be disappointed because these types of projects are hard and risky and they fail far too often.

Back up about 2 steps (-1, Troll)

BadAnalogyGuy (945258) | more than 5 years ago | (#28660937)

Before we can answer your question, two questions for you.

Who do you work for?
Describe the project you're currently working on.

Bonus question: What is your name and the names of your teammates?

Don't Worry! (4, Funny)

rlp (11898) | more than 5 years ago | (#28660965)

I'm sure Windows 7 developers will still be employable after the October release.

Re:Don't Worry! (5, Informative)

westlake (615356) | more than 5 years ago | (#28661093)

I'm sure Windows 7 developers will still be employable after the October release.

In the W3Schools stats the Win 7 RC has half the desktop share of Linux.

Re:Don't Worry! (1)

mysidia (191772) | more than 5 years ago | (#28661125)

Yes, but the project managers who made all the decisions about what Vista would be may not be in for such luck.

Not everyone on a development team is equally to blame for a project's overall failure.

e.g. Development members basically have to rely on other teams and co-workers on their own team to do their jobs correctly.

You may be assigned to do X. But when the overall project is completed, X and Y need to be combined in some manner.

If X's design handed down by the architecture team is horrible, or Y's code is a piece of junk, developers of X can't help that, the best they can do is implement the vision and assignments handed down by the project leadership as correctly and effectively as possible.

I won't blame the team who built the new start menu programming in Vista for the Aero team's poor choice of theme changes.

I won't blame the theme designers for the poor choices of changes to 'control panel', and how, you need 7 clicks now, through non-obvious choices, to assign a static IP to a NIC.

For the most part, no individual developer is responsible for the disaster, except the leadership of the project, and the people who actually had input or opportunity to provide input into the major decisions that made Vista so undesirable.

Re:Don't Worry! (1)

Kjella (173770) | more than 5 years ago | (#28661229)

I'm sure Windows 7 developers will still be employable after the October release.

I don't know, can we have a show of hands for Windows ME developers that are still employed in IT?

Re:Don't Worry! (1, Funny)

Anonymous Coward | more than 5 years ago | (#28661603)

iare of Mellenium guy. Me nmaed it ME after me. i many gude peeple skil

Re:Don't Worry! (0)

Anonymous Coward | more than 5 years ago | (#28662317)

Does janitorial work near the machine room count?
If so, I think we might have a few still employed in IT.

Re:Don't Worry! (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28662387)

I'd assume they're still working on Vista.

People change jobs all the time (3, Insightful)

flyingfsck (986395) | more than 5 years ago | (#28660991)

Bad programmers move on to do other things. A guy may suck at programming and be perfectly fine in IT doing maintenance, or in an over priced big box electronics store selling some new electronic pieces of shit.

Re:People change jobs all the time (5, Insightful)

Guysmiley777 (880063) | more than 5 years ago | (#28661285)

Big box electronics store don't want anyone who has technical knowledge on the sales floor. They want people with used car salesman skills to shovel their rip-off extended warranties to rubes. Being able to spout techobabble bingo may help, but only as a smokescreen. An actual techie might tell customers the truth. That would be entirely unacceptable.

Re:People change jobs all the time (4, Funny)

Quothz (683368) | more than 5 years ago | (#28661451)

They want people with used car salesman skills to shovel their rip-off extended warranties to rubes. Being able to spout techobabble bingo may help, but only as a smokescreen. An actual techie might tell customers the truth. That would be entirely unacceptable.

Obligatory: You know the difference between a used car salesman and a computer salesman? A car salesman knows when he's lying.

Re:People change jobs all the time (1)

wonkavader (605434) | more than 5 years ago | (#28661897)

I thought you were going to say that the car salesman knows how to drive.

Re:People change jobs all the time (1)

DeVilla (4563) | more than 5 years ago | (#28662711)

This is true. I know a fellow who got a job selling cars, not based on his knowledge of cars, (though he is knowledgeable and was actually applying to be a mechanic) but based on his ability to perform a simple act requested by the interviewer. "Here, try to sell me this pen."

Re:People change jobs all the time (1)

TheMCP (121589) | more than 5 years ago | (#28661919)

Bad programmers move on to do other things.

Except when they don't. I've seen bad programmers who simply move from job to job, doing incompetent work until their employer catches on and gets rid of them.

What I'd do (0, Troll)

ILuvRamen (1026668) | more than 5 years ago | (#28661001)

First of all, if you say at your next job interview "I worked on _____" they won't know what the hell you're talking about. Even IT people don't know about every single software solution ever made and how it performed. The odds that they'll have any idea what you're talking about is non-existant unless you worked on Vista or something.
But if you are working on some super high profile project like for Microsoft or Facebook or something, you'll definitely want to quit BEFORE the project is even close to done. If you know it's idiotic and as soon as it's done it's a disaster and the execs all blame you for their own stupid idea and fire you, well then you're out of a job anyway. So beat them to it and quit! But before you do, tell the higher ups that you refuse to work on a project that pointless and wrong because of what it'll do to your career. Tell them if they don't let you make the major changes you know it needs or cancel the project, you quit. Usually they'll just tell you to quit but who knows, it might get you somewhere.

Re:What I'd do (5, Insightful)

Anonymous Coward | more than 5 years ago | (#28661077)

Wow. That's horrible advice.

Burning bridges is stupid. You may very well need a job at that same company some time down the road and the same "clueless" manager is going to be the one hiring you back. A much more pragmatic approach is to simply say that you have opportunities elsewhere and wish them luck on their current project. Being positive, even as you're leaving, is always the correct strategy.

Re:What I'd do (4, Insightful)

Kell Bengal (711123) | more than 5 years ago | (#28661123)

I agree - definitely jump ship before the the shit-fan interface, but don't burn your bridges. Just tell them you 'need a change' or that you're seeking new challenges. People understand; it might even make you look smarter in their eyes because you saw the writing on the wall early.

Re:What I'd do (3, Insightful)

Hurricane78 (562437) | more than 5 years ago | (#28662091)

Guess what. I burned the bridges in my last company too. In a way that let a 500 people company still talk about it one year later!
And one year after that, I got a job offering from them. Begging for me to come back. I said no thanks, and that I will buy them for an apple and an egg. (Is it really "for a song" in english? Sounds strange.)
Two years later, they closed the whole shop. Trying to sell the business shortly before it. For that apple and that egg (or that song if you want). :)

I'm not going to play that crooky lie of "ok, everything is ok". Because I will rather die than come back, begging for anything.

Sadly, lack of pride is a big problem nowadays. Which creates many slavery-like jobs for many people in the first place.

After all, managers *learn* that everything is ok with what they did.

Just like in a relationship with someone. *Actually talk to them and state the problem*. :)

Re:What I'd do (2, Insightful)

Kell Bengal (711123) | more than 5 years ago | (#28662389)

You raise an interesting point - do managers 'learn' that spineless people will just smile and nod to keep their jobs, or is it the attitude of people who get into that line of work? I wonder if things would really be any different if people were more proactive about job mobility.

Re:What I'd do (3, Insightful)

johnlcallaway (165670) | more than 5 years ago | (#28661201)

Burning bridges is always a bad idea. I'm just turning 50, and it has surprised me the people that I used to know that pop up. In fact, past antagonists gained new respect from me in later jobs as they learned from their mistakes and matured.

That doesn't mean one can't offer advice, one just needs to word it diplomatically instead of calling everyone dumb shits.

Re:What I'd do (0)

Hurricane78 (562437) | more than 5 years ago | (#28662017)

You have your views, and I accept that. But I, for one, am sick and disgusted of people who always want to play nice to everyone, no matter what that asshole did on said, because "some time in the future, you may need him".

I proudly "burn those bridges". And then I live with it. Because there are tons of other opportunities. Other cities, jobs and countries to go. And even in the same city, with the same job, you still got enough choice.

Besides: Why do you see it this way around? I see it the healthy way around:
He burned the bridge. He killed it. He was the idiot. And most importantly:
He is the one, who now has to live without my skills.
So if he continues to do that, he soon will be alone, knocking on my door. And I will be the one telling him that he should have done a better job in the past.

Stop seeing yourselves as "lower" than your previous "boss". You are on the same level. Yes he got the money. But you got the skills. Let's see him try to build a program out of paychecks.
Yes there are others with such skills. But just like that, there are others with that kind of money.

If you're good, he will apply for a job below you in 5-10 years. :)

Maybe I will go broke, when that usually never happening event happens, that an old boss is my only hope left. But at least I will still be able to have some pride, instead of being someone who buckles when he has to face that type of egocentric person.

Re:What I'd do (5, Insightful)

Brian Gordon (987471) | more than 5 years ago | (#28661109)

How is being able to tell your interviewer "I quit in the middle of projects I don't think will succeed, because it's good for my career" good for your career?

Re:What I'd do (4, Funny)

Kjella (173770) | more than 5 years ago | (#28661197)

How is being able to tell your interviewer "I quit in the middle of projects I don't think will succeed, because it's good for my career" good for your career?

Well, you are taking advice from a guy with the nick "ILuvRamen" - maybe there's a connection?

Re:What I'd do (0, Redundant)

Anonymous Coward | more than 5 years ago | (#28661233)

Tell that to Sarah Palin.

Re:What I'd do (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#28661387)

I'm not sure. Ask Sarah Palin.

Re:What I'd do (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#28661395)

Just ask Sarah Palin.

Re:What I'd do (5, Insightful)

avilliers (1158273) | more than 5 years ago | (#28661759)

How is being able to tell your interviewer "I quit in the middle of projects I don't think will succeed, because it's good for my career" good for your career?

"I wanted to work on a project that was going to be successful, and I left when I became convinced that I couldn't contribute effectively given the current set up."

Showing you know the difference between a good project and bad project, especially ahead of time, is a plus in an interview. Showing you care enough about the end result, and not just a paycheck, is a plus. You should be able to communicate both of these things pretty convincingly if you left a high-profile disaster ahead of time. Make sure you're professional enough to talk about these things without badmouthing co-workers or sounding like a legend-in-your-own-mind, but other than that you're fine

Even if a project was successful, interviewees should be able to explain what they learned from the things that didn't work well. If it was unsuccessful, they should have a long list of mistakes that they now recognize first hand--and if you're going to claim you recognized all these things at the time they were happening, why did you stay?

I'd be just as interested in hearing the answer to that question. It's not like either situation would make you start with a presumptive strike against you--both should be pretty easy to explain. But there should be some level of awareness demonstrated, shouldn't there? If someone's attitude is "I did what I was told, my section worked fine," you know (at best) you're dealing with someone who has a pure grunt mentality and will never take responsibility for the overall product quality. I'd find working on a project like that very frustrating, and would be suspicious people who didn't.

Re:What I'd do (0)

Anonymous Coward | more than 5 years ago | (#28662053)

It's not ideal for your career but if you've come into a company where a very bad decision was made shortly before you came in and the project continually slides down the drain because any with talent gets fed up with being ignored then you do find it hard to stay on board.

It is nice to see how far you can shine the turd and make the best of a bad situation but being out numbered by idiots makes it hard to see things through.

Re:What I'd do (1)

TheMCP (121589) | more than 5 years ago | (#28662103)

You're telling your interviewer "I quit in the middle of organizational failure, and I'm smart enough to cover my ass by jumping when things are obviously wrong, rather than stupidly going down with the sinking ship."

Re:What I'd do (1)

nahdude812 (88157) | more than 5 years ago | (#28662521)

Employers don't want to hear, "I don't like XYZ, so I quit," they want to hear, "I don't like XYZ, here are the problems, and here is a better way to do it."

I understand that sometimes it doesn't matter how good your proposed replacement plan is and how bad things are; some companies are simply not going to hear what you're saying. But an interviewer wants to hear you say what the specific problems were, and what steps you took to try to address them before you gave up. If you tell them you quit because the project was failing, they're going to want you to convince you that you're 1) not a quitter, 2) can critically analyze the gaps, 3) can offer a meaningful and workable solution, and 4) that you can articulate it and be convincing without sounding whiny, angry, annoyed, hotheaded, smug, or any other such negative emotion.

Quitting a project because it's failing is giving up. If you're taking that stance, you'd better be prepared to convince your interviewer that there was no reasonable alternative. I sure don't want to hire you onto my team only to find out that when it gets thick, you split (right when I need you most).

Re:What I'd do (0)

Anonymous Coward | more than 5 years ago | (#28661155)

That's an incredibly dumb thing to do. Projects fail, yes, but for many different reasons which may or may not be an individual programmer's fault.

Bad overall vision for the project.

Poor marketing.

Bad user interface.

Competition from bigger and more powerful companies.

If your programming chops are as good as you think they are, you will walk away from a disaster unscathed. There is a difference between a piece of shit and a finely-engineered piece of shit.

Re:What I'd do (1)

emandres (857332) | more than 5 years ago | (#28661165)

tell the higher ups that you refuse to work on a project that pointless and wrong because of what it'll do to your career

I guarantee that if you go into your boss and refuse to do work you'll get fired for insubordination. In addition, bringing up your "career" is bound to send a pretty strong signal to your boss that you don't plan on working there very far into the future. If the place sucks to work at, polish your resume/CV and start making yourself known to other companies. Don't sabotage yourself by pissing off your boss, thus ensuring a negative reference from your previous employer.

Re:What I'd do (2, Interesting)

Anonymous Coward | more than 5 years ago | (#28661563)

A few years back, when I was young and foolish (now I'm just older), I joined a company in the midst of a huge project. At the end of 1 month, I sent my boss an e-mail with a few questions regarding what I thought were show-stoppers. Stupidly, my boss forwarded my e-mail on to several people, looking for answers. And my 'career' there went to hell. I discovered just how unpopular the guy who yells "But the emporer has no clothes!" can be, unless concessus swings your way.

I was out of there after a year. The project took another year to implode. On the exact points I raised. 300+ people, 3 years, half a billion dollars. But it didn't help me one bit.

My advice, in retrospect, is pretty simple: Keep your head down, offer your suggestions - as quiet, subtle suggestions - just once, and, if things don't change, start looking elsewhere.

I cant imagine Windows ME is a great career boost (2)

voss (52565) | more than 5 years ago | (#28661053)

However, learning from the mistakes of failed projects can actually increase your value, especially if the employer wants you to speak up.

Re:I cant imagine Windows ME is a great career boo (1)

Herkum01 (592704) | more than 5 years ago | (#28661367)

The question is whether they learn anything or not.

Some people will repeat the exact same mistakes if they are unable to self-evaluate. They not only have to identify mistakes but also the proper way to do something. It does not have help if they try something different at the next job and that is wrong too.

Re:I cant imagine Windows ME is a great career boo (1)

Bigjeff5 (1143585) | more than 5 years ago | (#28661683)

Only 30% of IT projects succeed in meeting their original goals of time, cost, scope, or quality. In this sense 70% are "failures".

Nobody gets a bad reputation that "fails" if the project meets the needs of the company/client. Projects that fail completely are generally run poorly, and developer's reputations are not tarnished. Frankly, only an idiot would blame the developer unless they did a piss-poor job. But if that were the case, said developer would have been canned from the project and a new developer would be brought in. THAT looks bad. Finishing a project, no matter how rediculous or terrible it seems to you the developer, rarely has a negative impact. Even if a project gets canceled, it is more likely to affect the project manager's reputation or the reputation of whoever initiated the project.

Again, developers who do a poor enough job to be assigned blame for a project - unless it is a company full of asshats - are usually canned and replaced mid-project. If that didn't happen to you, you should not have a problem, and you could even use it to your advantage in your next job interview. Blame for these types of things are generally an internal company sort of thing, they rarely spread outside the company except for a few industries.

Quitting for anything other than ethical reasons or reasons that are completely unrelated to the job itself would probably tarnish your reputation if you brought it up in an interview. In that case, you should just forget it ever happened. It shouldn't come up unless they go digging for it, and they won't be able to get anything negative relating specific to you unless you specifically made the news somehow. In that case, be honest about your role in the project and be honest about what happened. Unless of course it was your fault the whole thing failed. ;)

If executives made the bad decisions, say so (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28661055)

It is about the interview. Nobody is going to expect the grunt classifications to be making the big decisions.

Simple explanations of where you made design decisions and where you merely implemented poor design should suffice during the interview. Don't diss your previous managment. Try to remain objective in your descriptions.

In most cases, anyone with any time in the business will have gone through a litany of death marches and will completely understand your history.

Secretly an SCO thread! (1)

symbolset (646467) | more than 5 years ago | (#28661163)

Because who would want to hire the last few software engineers who stayed there through to the last?

A solution (4, Funny)

bunyip (17018) | more than 5 years ago | (#28661173)

A good friend of mine spent a couple of years on the Confirm project, which ended in a total mess almost 20 years ago. He claims that he simply put "2 years, federal prison" on his resume so that he'd have a better chance of being hired.

For those that don't know the Confirm project, they spent about $180M and about 6 weeks from the end date realized they were at least 18 months late. You can look up the rest of the details. :-)

Re:A solution (1, Informative)

Anonymous Coward | more than 5 years ago | (#28661529)

http://en.wikipedia.org/wiki/Confirm_Project

Re:A solution (4, Funny)

John Hasler (414242) | more than 5 years ago | (#28662163)

> For those that don't know the Confirm project, they spent about $180M and about 6 weeks
> from the end date realized they were at least 18 months late.

Yes, but how did it differ from the average project?

Quitting is often worse than completing (2, Interesting)

Anonymous Coward | more than 5 years ago | (#28661181)

While I work in a different industry it's also project based and the quality of the project will to some degree determine your next opportunities. What I've found both as a a worker bee and later on in management is that even though the results of the project can have some influence over getting your next contract (I work in film vfx, so if the film looked bad it's harder to find something good to show other companies) not completing the project is much, much worse. Companies want to know that you will stick with them and help them through a crisis rather than bailing on them mid-way through.

As a supervisor I take a close look at a person's end date on a project to see if they jumped ship half way through. There are good reasons to leave part way, but one such as "I didn't like the way it was going" really isn't one of them unless the person could demonstrate specifically what was wrong and how they would have made it better. In business you are paid to do the job asked of you in the best way possible. If you are asked to do something you think is wrong then it's time to start making suggestions as to how to improve the task rather than running away from the situation.

Maybe for some employers but probably not for most (3, Insightful)

nahdude812 (88157) | more than 5 years ago | (#28661247)

It's certainly possible that for some employers they'd hear you worked on Project X which failed spectacularly, and so they'd want to avoid hiring you. But I'd wager for most employers this isn't a black mark against you unless for some reason you have demonstrably substantial culpability in its failure. Maybe if you had 3 or 4 big failures I'd start to wonder if there was a pattern. But even then I'd ask you why those projects failed, and depending on your answer, this might actually make me more likely to hire you. For example, if you could give me a thoughtful analysis of what went wrong in each case, and could give good thoughts on things which might be done to avoid those mistakes in the future, maybe you have the insights necessary to help my team avoid a similar mistake in the future.

The only things I can think of that would make me not want to hire you (based on association with a specific project) is if you put on your resume that you were the lead developer, project leader, etc... or if the project failed for a very specific reason and I knew you were the cause (such as if you were successfully prosecuted for coding a back door into the project, etc).

There were a lot of excellent crew on the Titanic; the crew of the Challenger disaster were not responsible for its failure. Just because you're associated with a catastrophe doesn't mean you did anything wrong.

Re:Maybe for some employers but probably not for m (1)

TheRaven64 (641858) | more than 5 years ago | (#28661771)

Not to mention the fact that, if you saw a project fail close-up you probably learned a bit about why it failed. Hopefully that experience taught you something. If, on the other hand, you've worked on several projects that all failed then you're probably not the best bet as a new hire...

Just quit (2, Insightful)

Gorobei (127755) | more than 5 years ago | (#28661291)

You are a professional. When a project is truly doomed (i.e. the goal is pointless or no software could solve the problem,) just leave. Internal transfer, join a new firm, etc, it doesn't matter: just leave. Collecting a paycheck to support a losing project is sign you are a loser. Either fix the project or leave it.

I'm happy to hire people who have been on doomed projects, I avoid those who collected a pay-check until the final meltdown. A programmer who quits a clusterfuck is an asset: that's a clear warning sign to management that something is seriously screwed up. A keep-plugging-away-as-Rome-burns guy is a net cost: fire these guys first chance you get.

Re:Just quit (0)

Anonymous Coward | more than 5 years ago | (#28661833)

You are a professional. When a project is truly doomed (i.e. the goal is pointless or no software could solve the problem,) just leave. Internal transfer, join a new firm, etc, it doesn't matter: just leave. Collecting a paycheck to support a losing project is sign you are a loser. Either fix the project or leave it.

I'm happy to hire people who have been on doomed projects, I avoid those who collected a pay-check until the final meltdown. A programmer who quits a clusterfuck is an asset: that's a clear warning sign to management that something is seriously screwed up. A keep-plugging-away-as-Rome-burns guy is a net cost: fire these guys first chance you get.

You might pass that piece of advise on to the Washington,DC(District of Corruption) crowd.

maybe a little too stereotypical (1)

tommeke100 (755660) | more than 5 years ago | (#28662029)

This sounds a little too black and white.
I'm sure projects aren't all 1-man operations (or 3- man operations for that matter) where everyone knows everything about the project.
You could very well be part of a project where your sub-project is very successful yet other parts are the deal-breakers.
For example, you could have been working on a very efficient GUI/web-interface that you could be proud of, yet the back-end guys totally f'ed up and made it unscalable.
Or you could have been working on the database-end that kicks ass, but the business logic guys bombed. Not every developer is supposed to know the status of the whole projects, sometimes you're just asked to design by contract, and that's what you do. And this doesn't necessarely means you're just a code-monkey. Like, they could just ask you to design and implement a piece of software that exposes a certain API with a couple of constraints you need to comply to, but everything behind it is your responability. THis doesn't mean you know the overall status of the project.

If the guy has the right credentials, I would just ask what he did on the project, why he thinks it failed, etc...
a lesson lived is a lesson learned!

Re:maybe a little too stereotypical (1)

Gorobei (127755) | more than 5 years ago | (#28662281)

Quite agree on the sub-project thing. I usually just ask the people involved if what they are doing is reusable or special-case. If it's useful, go for it, but if it's gonna get lost in the noise, just get out.

Last year I got called into a meeting with a bunch of users who had somehow got five programmers lined up to write a really stupid bit of infrastructure (think bat-shit insane replication of bat-shit insane current workflow.) I cancelled it on the spot by telling the poor programmers to go find something useful to do. The users complained, but now I've got five productive, happy programmers, and those users are annoying some other boss at some other firm.

Re:Just quit (1)

JAlexoi (1085785) | more than 5 years ago | (#28662047)

Really, what about people with iron commitment, that do anything it takes to fix the project till the end? Are those kind of people bad?

Re:Just quit (1)

Gorobei (127755) | more than 5 years ago | (#28662593)

If they were good, they would fix the project. Ideally, two weeks in, they go to the boss with a plan to fix. If that doesn't work, three weeks in, they go to her boss with a plan to fix. If that doesn't work, they quit.

Re:Just quit (1)

TheMCP (121589) | more than 5 years ago | (#28662141)

I will hire people who worked on obviously doomed projects or for obviously doomed companies, and I don't mind if they stayed for the final meltdown. Heck, my dad turned off the lights and locked the door for the last time at a largeish corporation a few years ago after its meltdown. But, I will ask for and expect an explanation. If what I get is "oh it was so wonderful I don't understand how it could have gone wrong", I will be dubious about hiring the person, because it demonstrates that they are unrealistic or oblivious. If, on the other hand, I get a simple "I hadn't found a new job yet and I needed the money," I have no problem with that and would consider hiring the person.

Re:Just quit (2, Insightful)

lemur666 (313121) | more than 5 years ago | (#28662165)

Collecting a paycheck to support a losing project is sign you have a wife and two kids to support

There, I fixed it for you.

Working on a doomed project while speaking out and trying to fix it is a sign of an engineer who is a good candidate for promotion. They aren't just focused on their narrow portion and care about the project as a whole.

Generally, seeing engineers quit in the middle of a cluster-fuck project is a ding against their manager. It's up to their manager to make sure the engineers have input into the project, and can actual have their voices heard. Even if the project is a minor failure, people don't mind as much if they feel they have some stake in it. It's also a sign the project can be turned around in a later release if people at least have a voice in how to fix the processes that led to failure in the first place.

Sure some engineers are malcontents who can never be made happy, but these are pretty easy to spot in an interview. They'll talk about how the project sucked, but won't have much to say about how they'd make it better.

And even within clusterfuck projects, there can be small successes. I'm sure there are some lovely components buried deep inside Vista

So a smart interviewer is going to ask questions about your involvement in the clusterfuck.

And if the interviewer doesn't. Try answering the question without being asked. Or talk about how great your subcomponent was. And if the interviewer doesn't like that. Well, do you really want to work for/with a dumb-ass?

It also depends on experience. A smart, junior engineer shouldn't be blamed at all of a project failure. A senior engineer / manager should be asked some tough questions about their involvement.

Then there's the whole "companies with a stench of failure all over everything." Basically, I look for people with short tenures at these sorts of places. I don't want to see a 10 year veteran VP candidate from any company with reputations for "climb to the top of the meatpile" back-stabbers. Or an engineer from a place with a reputation for being insular and producing sub-par code.

Finally, the question you have to ask yourself is "Is this project really a failure?"

15 years ago I left a software company after a 3 year 'Bataan Death March'-style release of what I thought was a very disappointing, bloated, and technologically lagging project.

This product enjoys around a 65% Market share and probably a billion in sales annually.

Re:Just quit (3, Insightful)

SirLurksAlot (1169039) | more than 5 years ago | (#28662293)

You are a professional. When a project is truly doomed (i.e. the goal is pointless or no software could solve the problem,) just leave.

You're obviously a Highly Paid Consultant who could care less what happens to the project or what the client thinks. It's people like you who give developers (and consultants in particular) a bad rap.

Collecting a paycheck to support a losing project is sign you are a loser.

Or they at least have the balls to stick it out until the bitter end, which (if your post is at all accurate) can't be said for you.

I'm happy to hire people who have been on doomed projects, I avoid those who collected a pay-check until the final meltdown.

Please, what company do you work for so I know who to avoid?

A programmer who quits a clusterfuck is an asset

Or a quitter, i.e. someone I wouldn't care to work with.

It sounds like you're confusing loyalty and professionalism with laziness. Personally if I'm hired to do a job I stick it out until the job is finished. Even if the project ends in spectacular failure, as long as I did my absolute best I stay until the job is done and I expect those I work with to do the same. Everyone works, no one quits.

Re:Just quit (1)

Gorobei (127755) | more than 5 years ago | (#28662529)

You're obviously a Highly Paid Consultant who could care less what happens to the project or what the client thinks. It's people like you who give developers (and consultants in particular) a bad rap.

I'm a highly paid employee who wants a good job done. I've dumped clients when what they want is absurd: better for my guys, better for them: building stupid stuff is a waste of everyone's money and time.

Oh, and the phrase is "couldn't care less."

Project failure is not business failure (5, Insightful)

holophrastic (221104) | more than 5 years ago | (#28661309)

Keep in mind that when it comes to actual businesses, it's often better for a project to fail catastrophically in two months.

A project that is started, realized, and dead in two months costs two months of resources. Compare that with the following:
    - a project that takes a year of work to get off the ground, and then eventualyl fails after repeated attempts to make it profitable over another two years.
    - a project that takes three years to become profitable

The former is not only a waste of money, it's a waste of time too.
The latter is profitable, but when considering the opportunity cost, many businesses look for faster, simpler, and lower resource-intensive projects.

The reason business-level executives can be rewarded for a failed project is because a smooth fast failure is a good thing is high-risk projects.

Realizing failure is just as important as realizing success -- when you've got other work to do too.

As for developers knowing earlier, I call zombie bullshit. Developers know when the product isn't great. Business has always made successful projects from crummy products.

Also compare spending $N on a project over a year, versus spending the same $N on the same project over only a month. In business, the latter is better -- why waste time.

But hey, we're all science-lovers here. Look at business the way we look an scientific research. If your experiment can be done faster, at the same or even a moderately increased cost, you get to results faster, and you get to do more experiments, and you get to move through more potential filliments before finally being able to invent that working lightbulb.

Re:Project failure is not business failure (2, Insightful)

PPH (736903) | more than 5 years ago | (#28661675)

Checking it off as failure and moving on can be good .... if it saves resources. But the bean counter logic states that $N is $N regardless of whether you burned it fast and moved on or slowly and tied up assets. Your time all goes on the books the same way.

What it really boils down to is: How will the project cancellation be handed on the books? Will it appear as a charge on the annual reports? Did it reach some threshold where it must be revealed as material information to the stockholders?

I worked on a project to replace a crippled DB at one outfit into which the company had tossed a quarter of a billion dollars. It took us (5 developers) under a year to build the successful replacement. But the dinosaur still lives on. As an application with drastically reduced functionality, hosted on a system in some corner. But from the point of view of the bean counters, its still operational and may be depreciated over its lifetime instead of charged against income in the quarter the plug is pulled. So they can keep $250 million in fuckup off the books by spreading it over 10 or more years. Needless to say, the old project's management is long gone. Our management always labored under the threat of having to declare that it is time to unplug the old one. Because all the BOD will see is the crippled balance sheet with our boss's name on the memo.

Re:Project failure is not business failure (1)

holophrastic (221104) | more than 5 years ago | (#28661799)

yeah, but that's the bean-counter world of accounting, not the .c.e.o. world of growing the business and finding the next big thing (for that company). And in the end, the bean counters rarely hire the .c.e.o. (unless there's a .c.f.o.)

Lame Project Survival Kit (5, Insightful)

ddt (14627) | more than 5 years ago | (#28661329)

I've been in this position a few times because in game development, there are lots of bad games out there that are rushed to completion to sync them up with the release of a film, for example, or to hit Christmas, or because a publisher is trying to make its quarter or because a developer is running out of money.

Here's your lame project survival kit:

1. Stick close to the most talented folks on the team, and treat them as your real boss. Pretty soon, they're going to leave. Make sure they have fond memories of you, so that they can recommend you where they end up, and make sure you get their personal email addresses. Everybody loves a good, helpful coder. This is by far and away the most useful thing you can do for both your soul and the long-term health of your career.

2. Drop the project from your resume. Mention the company but explain that you worked on various projects there.

3. Take responsibility for turning the project around, find a scapegoat in sales, gather evidence, and pin it on him (never in writing) when it goes down in flames. This will make you part evil and is a big part of how people fail upwards, but lots of folks have had made lucrative careers using this approach.

4. Lame projects typically have poor direction and allow people to get away with doing whatever they want without being fired, as long as they look busy. So invent a task that or sub-project that results in a short, flashy demo or video that makes you look good to your next employer.

5. Flatter the slimiest, most inept manager in the group. They typically crave this because no one recognizes their true "genius". They also often pick option 3. and end up attached to some new project to fuck up, which can buy time while you're looking for a new job. They work hard to surround themselves with loyal useful people who say nice things about them.

6. Start humbly asking to buy the CEO lunch and start picking his brain on executive management or anything he knows lots about and seems to be passionate about discussing. Never let him pay for lunch, because you consider it too educational. You may or may not be interested in what he has to say, but the key thing is face time. When things go to poo, it'll be harder for him to fire you.

7. Stop being lazy about your future. Look hard for another job. Put 1-2 hours into it every day after you come home from work. Lame projects blacken and destroy souls.

Re:Lame Project Survival Kit (1)

Sadsfae (242195) | more than 5 years ago | (#28661573)

I've been in this position a few times because in game development, there are lots of bad games out there that are rushed to completion to sync them up with the release of a film

You mean like E.T. for Atari?

http://en.wikipedia.org/wiki/E.T._the_Extra-Terrestrial_(video_game) [wikipedia.org]

Re:Lame Project Survival Kit (2, Informative)

sigmabody (1099541) | more than 5 years ago | (#28662003)

This is great advice, IMHO, #1 especially. As a senior developer who has both switched companies a few times, and been responsible for trying to find other developers to hire, I have pulled in friends and colleges on many occasions, and I could get a good developer I knew from a previous company a job pretty easily (even today). The problem for people with other good developer friends is usually more that they don't live in the right place, and/or are already happily employed, and/or don't want to work at the particular company.

Re:Lame Project Survival Kit (2, Insightful)

JAlexoi (1085785) | more than 5 years ago | (#28662101)

Well I make my career by joining late projects and doing everything to fix them.
Whenever I see that the project will fail in any case, I quote the project as a project where I have learned "How NOT to do things".
And I can't complain about my career.
On the positive side, the late projects have actually relaxed their rules to get the project completed. So I get into an environment that needs results fast and I can push through more innovative ideas through. Whereas, on a "on schedule" project, there is little space for innovative solutions.

Re:Lame Project Survival Kit (0)

Anonymous Coward | more than 5 years ago | (#28662469)

6. Start humbly asking to buy the CEO lunch ...

I work in a fairly big company. I think I'd rather eat vomit from a shoe than have lunch with my CEO (grade "A" prick).

NT: Pfft just blame it on QA! (0)

Anonymous Coward | more than 5 years ago | (#28661445)

NT

Inside, sure; outside, not really (0)

Anonymous Coward | more than 5 years ago | (#28661483)

A project that failed due to bad executive decisions, can hurt an engineer's chances inside the same company. But other companies don't care so much.

Not a problem (2, Informative)

PPH (736903) | more than 5 years ago | (#28661511)

You can always lie on your resume and explain the last couple of years as having served time in the state penitentiary.

But seriously: I went into private practice as an engineer because of this. Not due to a single project. All of mine were quite successful, making them oddities at my old company. But the stink of that employer's reputation just won't come off a CV.

What normally happens (2, Insightful)

Sadsfae (242195) | more than 5 years ago | (#28661521)

with expensive upper management/executive types is they do rove from company to company, doing the exact same thing they did at their previous job.

The notion that it might not work at a different organization never comes up or is questioned, they want be seen making large, sweeping changes.

An example would be shoving some mandate down the pipe like an open floorplan for "collaboration" which in most cases turns into a noisy, distracting work environment that just ends up impeding efficiency rather than enhancing it.

Because this was "so successful" at their last job, the lack of effectiveness at the present can easily be blamed on staff, culture, etc.

For larger, more destructive mandates these guys are usually out the door, resume in hand before the full catastrophic effects have been fully felt or realized.

Learn how to turn a weakness into a stength (3, Insightful)

Orion Blastar (457579) | more than 5 years ago | (#28661599)

and a negative into a positive.

You could have made every mistake you can make on that job or project, but as long as you learned from it and can avoid making the same mistakes, you become a better person for it. That is because human beings learn by mistakes.

When a software project is costing more in expenses to support than revenue it brings in, it is usually because of a quality control problem. I know this from experience and I am usually the programmer taking over "legacy projects" and "legacy software" by debugging them so the quality is better and it runs faster and hardly ever crashes due to the higher quality and quality management process I go through. When I went to college and studied programming I was a student worker in a computer lab, and they had a full time debugger to help the students, when she couldn't help the students because the program was a mess or was for a computer language she didn't know they sent it to me to debug. It was one of my many jobs as I tried to learn as many computer languages as I could while in college. I applied that debugging skill to my career and I helped countless coworkers with debugging issues. How did I get to be so good at debugging? I learned from my own mistakes while writing programs for class, and then I learned from other students' mistakes doing debugging for them, and then from coworkers' mistakes in debugging their programs.

Now while I tried to teach coworkers to learn from their mistakes, they often took it the wrong way, and refused to learn from them, leaving me to always having to debug their programs. The few coworkers that did take my advice and learn from their mistakes went on to other jobs later to be promoted to high paying jobs and careers in writing quality code with quality built into the design. Those that didn't, work the same job, for almost the same pay, and keep making the same mistakes until they are fired or laid off, and then work another job making the same mistakes. I hear from them via email, asking me to help them out like I did when I was working for them, but I cannot as their employers would not want me to see the source code they are working on, so for legal reasons I have to turn them down, and then give them a few web links to debugging books or web sites that might be able to help them out.

Release? That's nothing (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28661605)

I've had the whole *company* go bankrupt, and it didn't hurt me. The former CEO of the broke company got me the lead for my next job. Sigh. Probably better to post AC.

Got Talent? (1, Troll)

gru3hunt3r (782984) | more than 5 years ago | (#28661641)

I have personally been through this. When companies (or at least the sales people in companies) aren't making their monthly quota they start to get desperate and throw every piece of trash against the wall to see what sticks. I used to think this was a bad thing so I feel a certain kinship to this author. As a developer the consequences of delivering, or attempting to deliver what they told/sold the customer causes their requests to become more and more asinine until eventually they are selling software with features only found in fairy tales.

But just because sales has started promising free elevator rides to the moon so that customers will buy your product does not give you an excuse to not build it... that is what we, as developers do. We make the impossible seem easy, we make it seem magical. That is the career path we have chosen. Alas, perhaps you're not that talented. Perhaps you should consider a job at best buy and continue the 9-5 grind.

The path I will suggest is arduous it will not be paved with roses and cupcakes. Yes, projects will crater, and the disasters will be spectacular -- with enough shrapnel flying every direction to damage everybody. Your companies reputation will become the equivalent of a "turd sandwich", and you will on some days resemble an angry hobbit screaming rants in languages long since forgotten during this age of men. You will need to bend time, and find a way to work 30 hours a day, and your body odor will, at times cause small children and virtuous women to shun you. (It helps if your office has a shower) .. But your skills through this process, they will become uber, nay.. "legendary".

Some slashdot trolls here will say that what I propose is impossible - that you cannot dodge bullets shot at you at point blank range -- but they don't realize you won't need to dodge the bullets at all.

So if you believe the force runs deep and strong in your blood young padawan, then trust it. Give yourself over to it, let it control you and guide you. You'd be amazed what you can do with the blast shield down if you just fucking try.

Oh.. and to respond to your question: True JEDI's don't apply for jobs, they choose which job they want and take it.

ps> After 7 years as CTO .. I ended up getting the CEO's job. (true story)

I'd say no (1)

NotSoHeavyD3 (1400425) | more than 5 years ago | (#28661689)

But then again I left my previous company a few weeks before the sh*t hit the fan because I was going back to school for a couple of years. I'm not sure if I would have had problems finding a job if I looked immediately after that fiasco.

If Office Space Has taught Us Anything (2, Insightful)

senorpoco (1396603) | more than 5 years ago | (#28661743)

It is that programmers will ALWAYS fall on their feet, and office space wouldn't be lying would it?

I think you got it the wrong way. (1)

Hurricane78 (562437) | more than 5 years ago | (#28661865)

I would never hire a manager of such a failed company. To me they are the archetype PHBs. ^^

A developer/designer/grunt however... I bet after the shitty time he wants nothing more, that to finally work on something where he can freely state all the errors of management, that were ignored in the old company and that were so obvious. So if I clearly state, that in my company, I hire experts because of their expertise and that I will actually listen to them, I will get someone who really cares for the project, has much expertise on the risks of failing, and is motivated to finally get something that he really loves done.

Because in the end, making each and everyone of the team love what he/she's doing because they know that their work is significant and valuable, and first getting the respect, before expecting people to follow you, is what really counts.

So I can really imagine a "low-level" guy from a failed project having learned more than one from a successful project. :)
But usually, I prefer to test this person myself, and make my own image, instead of judging him on something that I know nearly nothing about.

Madden NFL 96 (1)

EWAdams (953502) | more than 5 years ago | (#28661881)

One case in which the grunts got off better than the management.

drivers and passengers (0)

Anonymous Coward | more than 5 years ago | (#28661927)

It's all about the driver-to-passengers ratio.

Passengers - people who show up, work their "normal" hours, get stuff done but rarely take responsibility beyond their narrow remit. They probably have average/below-average technical expertise, but somehow managed to blag their way into the role anyway. They may have a tendency to ignore a problem if nobody else has noticed it. They may work on a side-project that makes people say "ooh shiney" without really helping the team meet its true goals. They probably don't care about the company/product very much and see it as a means to an end. What ends? The paycheck, the prospect of a merit badge because they happened to be on the team with some really productive people, and perhaps some day a promotion.

Drivers - people who combine considerable skill, talent and flair to deliver consistently. If they fall behind (which may not be measured in any official capacity, but by their own personal barometer of progress), they will work extra hard to get stuff completed. If they're in a management role, they will be willing to make hard decisions and change the team or objectives around. If they're in a worker role, they will either be willing to "fix it" or to be honest with managers about the true state of affairs and will come up with alternative solutions.

If you mix too many passengers, you're in for trouble. If your leadership is dominated by passengers, you're in for a LOT of trouble. The dynamics of the team are also a factor, one team's passenger might be much more effective on another team.

Back to the original point... (1)

techsoldaten (309296) | more than 5 years ago | (#28661931)

Back to the original point, I have had to hire a lot of developers in my career. I ask detailed technical questions about the projects they have been involved in, and look for failures as an example of lessons learned.

But you actually have to learn those lessons and change your ways. Stigma can follow you after the failure of a project especially if someone knows what went wrong. One person interviewed with me, he was a senior developer involved in the roll out of the original Toys-R-Us.com. For those that don't remember, it was launched in 1997-ish and had some serious performance and security problems. He seemed to be pretty straight up about the experience and explained what he would have done differently.

After taking a look at some of the projects he had worked on since, I could see that many of the original issues were still part of his developer MO. There was another e-commerce portal where he was a senior architect, I was able to view some details of other user accounts via a hack also worked on the old Toys-R-Us site. The moment I saw that I became a lot more critical and just ripped into his work. I was able to slow his sites down by just reloading pages a few thousand times. Looking at the actual markup on some pages that just failed, I noticed he had it set up to dump Oracle errors into comments on production web pages. There were issues with the quality of the images, there were these big uncompressed JPG files that were like 120 pixels square and 40k.

He claimed this was people at his agency not doing their jobs and blamed developers and designers who worked on his teams. For senior level positions, no one buys the argument that other people are causing the same problems over and over again.

M

impossible (1)

farble1670 (803356) | more than 5 years ago | (#28661965)

it's impossible to attribute the failure of a project to individual contributors. they might have been a contributor to the failure, or just a victim of circumstance. you won't know until you interview them, just like anyone else.

as you go up the chain, i think there's more reason to blame. it's up to a manager to assemble the right team to perform a task. if they aren't doing that, there's some fault. and on up, if the manager isn't given the authority to assemble the right team ... etc.

it's quite backward that execs carry little or no blame for failures. if there's any blame at all, it should be on them. they have ultimate authority to make whatever changes are necessary to make things work. why do failed execs make out like bandits with payoffs and future opportunities? it's called an OLD BOYS' CLUB. they protect each other, or scratch each others' backs so to say.

as a person that hires people... (1)

pjr.cc (760528) | more than 5 years ago | (#28661997)

I work for a reasonably small company, but i've also been asked by several of our clients (from small to mammoth) to help with the interview process for technical types. (Im in AU by the way, so may not be pertinent outside Australia).

The fact you may have come from a catastrophic failure really doesn't matter... There maybe some idle curiosity as to how it was "at the end", but in reality nothing matters as much as being able prove that:

1) you have the skill to do the job
2) you have the right attitude
3) other people are willing to say good things about you (i.e. references) and they are believable.

There's often very little you can assume/find out about a single persons involvement in a catastrophe. If they were there to the bitter end its either because they couldn't find a new job quick enough or because they were hoping to save the company (which are opposite ends of the spectrum in terms of an employee - but it could be a million other reasons too). The point im trying to make it that its impossible to know (from an employer perspective) what the reasons might have been and they rarely give much insight anyway. To some extent, the size of the company that folded can make it easier to figure out some facts, but its rarely a developers fault. Its often management/business decisions that result in the doom of a company.

All that aside, there are some things in the industry which are "more is better" and experience is probably the prime candidate. If you've been around for the end of a company, well thats something you have to your advantage as its an experience you have that perhaps alot of your possible competitors for a job may not. Simply put, as an employer if I had someone on my team that lost their job cause of a company collapse i'd certainly like to hear his views on where my company is heading (from a developers perspective).

Thats just my humble opinion, keep in mind almost all employers have different views on almost any subject. some may view your involvement in a catastrophe as a bad thing, but i personally don't know any.

The Punishment Should Fit the Crime (2, Interesting)

curmudgeon99 (1040054) | more than 5 years ago | (#28662005)

Over the years, I have worked on hundreds of IT projects. I encountered many flawed processes.

I worked for a company that had just decided to use UML and so we were forced to spend months constructing UML diagrams that mostly were a waste of time. Eventually, we made our business folks master the verbal-only [no stick men] use case model and that worked.

I worked on another project where the business people were so involved they made technology decisons and were even standing over the backs of developers ordering 'for' or 'while' loops. (Not to me, thankfully).

I've also worked on perfectly tuned agile teams that had a tight PM daily accountability in standups, and that was stressful but also tremendously productive.

Let The Punishment Fit the Crime

Project fails because business interfered? Hold the head of the business team responsible.

Project fails because the software is buggy? Hold the head of QA accountable. Also maybe the architect or lead developer, who of course will be only too glad to point out the sloppy developer who did the work.

Project fails because the design is stupid or flawed in some other way? Hold the designers accountable.

So, I hope you see my point: if you were part of a project or product that became infamous--your punishment should fit your crime. If you were only a grunt developer implementing a design blessed by the architect and tech lead and designed by the business folks--then hell no, you should not also be accountable. You were doing your job. The junior developer can honestly say that but only if that developer's superiors are being held accountable.

So, if you're the original developer of AIG's Credit-Default Swap software, I would not hold you accountable for the damage done by those "financial instruments" (another name for a stick you would use to dig peanuts out of shit). The architects of this software and the business folks who designed it should be held accountable.)

Re:The Punishment Should Fit the Crime (1)

farble1670 (803356) | more than 5 years ago | (#28662175)

it's hard enough to prove guilt in a court of law. suggesting that project failure is going to fit neatly into one of the categories you mentioned is silly, let alone that you will be able to arrive at some objective truth about the reasons.

Re:The Punishment Should Fit the Crime (1)

curmudgeon99 (1040054) | more than 5 years ago | (#28662891)

Who said anything about proof? No manager needs proof of anything to fire someone. A manager just needs suspicion. But really, I was explaining why it was ludicrous for any junior developer to stand up, among an ocean of peers and say, "I'm the one. I wrote the Credit-Default-Swap logic that became the standard, and I didn't know what the hell I was doing." Unlikely as such a confession is, the confession of guilt is misguided. In this case, it seems clear to me that no authority equals no guilt. Only those in positions of authority deserve to have their careers destroyed, lives ruined, their images burned in effigy, students in college programming classes hearing about it, making that junior CDS coder into a little Satan in his or her cubicle. I think the architect should wear the red suit, horns and pointy tail.

Access Your Position, Not Your History (1)

LifesABeach (234436) | more than 5 years ago | (#28662291)

"You can only negotiate from a power position." Were the words told to me by another senior level programmer when I naively ask the same question. Sometimes it's is better to be known for other things than your job history.

i worked on amiga os 2.0 (1)

ifeelswine (1546221) | more than 5 years ago | (#28662547)

and it has haunted me to this day. i do not go outside for fear that someone will recognize me.

Don't worry ... (1)

damn_registrars (1103043) | more than 5 years ago | (#28662741)

Bad programming isn't always punished. And if you look at how this place is running, one might conclude bad programming is seldom, if ever, punished.

Re:Don't worry ... (0)

Anonymous Coward | more than 5 years ago | (#28662965)

You got that right brother.

Why can I not find a comments page with all comments listed with a single click, and not having to manually expand compressed/hidden comments, or go to page x, y, z - page 49 to save them? I often want to grab them to read on a plane, and the user interface is so lame on all sites (political, paid subscriber, etc.) - is it some website conspiracy by their contractors?

One-click - all comments - there, easy to read, and I just put prior art into the patent-seeking companies.

Man, even the bot-detection scheme confused me with letters on other lines confusing normal text training in, say, the US, or Japan. Dumb, Dumber, Dumbest.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>