Developer Stigma After a Bad Or Catastrophic Release? 223
Posted
by
Soulskill
from the don't-call-us-we'll-call-you dept.
from the don't-call-us-we'll-call-you dept.
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?"
In my experience, no. (Score:5, Insightful)
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.
People change jobs all the time (Score:4, Insightful)
If executives made the bad decisions, say so (Score:1, Insightful)
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.
Re:What I'd do (Score:5, Insightful)
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 (Score:5, Insightful)
Re:What I'd do (Score:5, Insightful)
Re:What I'd do (Score:4, Insightful)
That doesn't mean one can't offer advice, one just needs to word it diplomatically instead of calling everyone dumb shits.
Re:In my experience, no. (Score:5, Insightful)
Yep, and the same thing applies to the executives the questioner slams.
Maybe for some employers but probably not for most (Score:4, Insightful)
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:People change jobs all the time (Score:5, Insightful)
Just quit (Score:2, Insightful)
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.
Project failure is not business failure (Score:5, Insightful)
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.
Lame Project Survival Kit (Score:5, Insightful)
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.
What normally happens (Score:2, Insightful)
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 (Score:4, Insightful)
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.
Re:In my experience, no. (Score:3, Insightful)
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. (Score:4, Insightful)
Re:Project failure is not business failure (Score:3, Insightful)
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.
If Office Space Has taught Us Anything (Score:2, Insightful)
Re:What I'd do (Score:5, Insightful)
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:In my experience, no. (Score:4, Insightful)
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:What I'd do (Score:4, Insightful)
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:Lame Project Survival Kit (Score:3, Insightful)
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:In my experience, no. (Score:5, Insightful)
> 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:Just quit (Score:2, Insightful)
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:In my experience, no. (Score:5, Insightful)
No, I don't.
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.
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.
Re:Just quit (Score:4, Insightful)
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.
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.
Please, what company do you work for so I know who to avoid?
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:What I'd do (Score:3, Insightful)
Re:In my experience, no. (Score:2, Insightful)
In tough economic times the only companies that suffer are the ones that weren't doing well or weren't needed to begin with.
Show me one well managed company that provides an essential service thats anywhere close to failure.
The only companies suffering are the ones that were riding on the over inflated economy. I say this full well knowing that the company I work for, on the verge of going out of business falls squarely into both categories.
Re:What I'd do (Score:3, Insightful)
On what planet? In the interviewer's mind, that translates into: "Given the doomed projects coming up, this guy is going to quit within three months. No Hire."
You may need to work on your interviewer mind melding skills.
Just ask yourself it that's what you'd think as a manager interviewing an employee. "I have two candidates, one who will understand what's going on in the workplace around him, and one who won't. I obviously need to hire the clueless one, since the smart one will recognize that I am an incompetent who will do nothing but feed him projects are destined to fail." I imagine probably not? Then why do you think anyone else would think that way?
You may be confusing a candidate's being able to distinguish good and bad projects with a candidate who's just a prima donna. The guy who projects a sense of entitlement, who will only want to work on the central aspects of high-profile projects, yeah, he's not going to get an offer. As I said in my grandparent post, you want to make sure you're not coming off that way. Explain why the project failed. Don't explain why it was "beneath you."
Also, this is distinct from concerns about someone being overqualified. Overqualified (ie, should be running a team on paper but is applying for a grunt job) is a concern. Then you're worried that they might leave; but you're also worried that they're apparent "underperforming" is because actually quite incompetent, so exuding cluelessness will not help.
Unhireable?, Haha, they get promoted... (Score:2, Insightful)
Not at all. Instead, they move on to become development leads or even project managers, ruining even more projects and companies!
(my ex was in HR, and basically, US law forbids your old job from saying anything negative to your new employer)
And nobody is listening.. (Score:1, Insightful)
I am experiencing the same in my company. A new guy is hired and he is on the mission to build the entire system in two weeks...we tried that before and it failed miserably. So I tried communicating it to this talented soul [who is hired without any technical interview - anyways] - and he went on shooting a few missiles my way. Now, I don't understand why people don't want to listen.
Like re-designing entire production database because they want to use a specific ORM technology or love something brand new. In my opinion - strategy based on "technology looking for a requirement" is a recipe for the disaster. Many a time we as a developer or a group either commit the same mistake or take a passive stand so we can save our own job [ I am doing the same now] - I got my small project going on [1 man army - me myself working on it], but some where in the near distance a team is going on the path that will take them to the cliff...and nobody is listening..
Re:Quitting is often worse than completing (Score:2, Insightful)
Re:Just quit (Score:4, Insightful)
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.
For me you sound like two extremes on a scale and I think you're both wrong. Yes, if you quit the first time a project you're in is in trouble then you're a quitter. But if it's a huge project or it's a repeated problem, why do you want to inflict a death march project of on yourself? You know the kind where you know the project will be a failure even if your part is flawless. That kind of thing is just a soul-destroyer of morale, making you feel like you live in a Dilbert strip. If the company is just too stupid to cut their losses, are you supposed to loyally and blindly follow their stupidity? Draining every last paycheck before the project burns isn't exactly building confidence in the consultants that either, then you're just blamed for bleeding them dry and leaving them with crap. In fact, I'm quite sure I've heard more accusations of that than the opposite. Of all the reaosns a project fails, "horrible internal project mismanagement" is always the very last option if you got noone else to blame. Try to guide them through the rough waters, but if they insist on heading full speed like Titanic against the ice berg, then I say abandon ship. The honor of going down with the ship may gladly be left to the captain, not the crew.
Re:Got Talent? (Score:5, Insightful)
Is this the spiel you give your developers? "We will pile on the stupid and expect you to turn it into gold?"
Your admonitions won't improve anyone's geek-fu. Quite the contrary, it gets them into a mindset where, if it compiles, it's good, and if it runs, it's perfect.
It also teaches them that 90 hour work weeks are not just to be expected, but are in fact a gift from the coding gods, an opportunity to temper your skills on the field of battle. Which may work for a while. Until their marriage fails, or until they realize that they hate working "Jedi hours" for a lousy fifty grand a year. Then, because they've swallowed your Kool-aid, and convinced themselves that "real coders" are supposed to thrive under constant stress and hammer out six impossible algorithms before breakfast, they start looking not for a more laid back coding job, but for a shift at Best Buy.
There is only one use for the crap you're peddling: to get a horde of young coders working long hours at substandard wages. As you mentioned that you're the CEO of your company, this fact doesn't surprise me in the least.
Re:In my experience, no. (Score:1, Insightful)
An executive who doesn't notice until too late that his developers are screwing up is screwing up.
What kind of retarded statement is that. Do you really expect executives to know every detail about how to do every job of the people underneath them. Unless you're a hardcore software company, I don't expect executives to know shit about computers in general. Banks run on mission critical software but I don't expect bank execs to know the first thing about programming. Even if they have a CTO, he's probably more of an ex-accenture implementation guy which is a far harder job to get right than coding (if it weren't why would there be so many implementation screwups). In addition when things go wrong, they usually go wrong at the end, when its by definition too late.
Just people you'll never make it to the top doesn't mean you have to be pissed at the people already there.
Re:Got Talent? (Score:3, Insightful)
I'd say you're the troll, or you're well on your way to failure already.
What turd sandwich is this you're allegedly running? You're not proud enough of it to put it in your profile or anything. How many employees does it have, and how many belong to the order Rodentia and work for cheese?