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?"
Quitting is often worse than completing (Score:2, Interesting)
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.
Re:What I'd do (Score:2, Interesting)
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.
Release? That's nothing (Score:1, Interesting)
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.
Re:In my experience, no. (Score:3, Interesting)
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.
The Punishment Should Fit the Crime (Score:3, Interesting)
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:In my experience, no. (Score:3, Interesting)
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.
Re:In my experience, no. (Score:3, Interesting)
I very much doubt that. Because other than for us, they do not get punished for it. They usually get large compensations
They, they, they. It all sounds very black-and-white.
I've seen a project go wrong. The project manager clamored for support but not in the right way. She also did not get it due to an inexperienced division manager. Whatever the reasons, the combination turned out bad. She saw the problems coming, felt she didn't get support and asked to be moved elsewhere. Someone else took over.
Some time later, she told me a potential career movement had been obstructed because someone in the management team remembered her from that bad project. I have not heard about the division manager his career, or the replacement project manager.
My point is that I find your view "zOMG they PROFITS!!" pretty unrealistic. There are lots of sides to stories on failed projects.
Re:What I'd do (Score:3, Interesting)
"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."
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
I thought about what is different between the message you're giving and the GP his version of the message. Both basically say the same, but your version is better.
GP says: "They did such-and-such, which I suggested they fix. But they just kept doing it. So I threatened with this-and-that, then took off before they could blame me." Lots of THEY in that sentence, says basically: blames other people, not in control.
Then I realized your version is better because it is said from the first-person. In other words: "I wanted such-and-such, but I felt this-and-that, so I did action-such." It shows that you knew to listen to your instincts, and did what was in your power.
Something to be learned from that.
Re:What I'd do (Score:3, Interesting)
The answer depends a lot on how much adversity you intend to dump on them.
Sitch1: tiny amounts of adversity. Those who can't handle it in small, necessary amounts clearly have problems with their own sense of entitlement, and should be avoided.
Sitch2: moderate amounts of adversity. Different people will have different tolerances. Some will thrive under pressure, others will just muddle through, and some will fall by the wayside.
Sitch3: crank the pain up to 11 and rip off the knob. At this point, all that's left are the kids who haven't yet realized that there are better jobs out there, and the depressed mole people who will cling to the job because they don't think themselves fit to be in the industry at all. But they'll still be resentful, and will plot your demise.
There must be balance in all things.
Re:What I'd do (Score:3, Interesting)
Well, it's very interesting, how things were in Luxemburg some years ago.
Luxemburg is a tiny country. With 480,000 people living there. And over 30% are foreigners.
The country is so rich, that people do not want or have to work. So we had the apparently rare situation, that there were much more job offerings than actual people wanting to work.
So people did not have to fight for jobs, but companies had to fight for employees.
This meaned that potential employees could make demands, just like bosses do "usually". So Christmas bonus? Ok, then I'll go to the competition.
So even fathers got parental leave for I think one year. Etc.
I can tell you that it was great to be an employee in Luxemburg. 1200 was the minimum salary per month, by law. You had all that you wished for.
The only problem was, that people started to demand unrealistic shit, so that businesses themselves suffered. And some spineless companies who had to get new employees now, or go under, bought into these demands. Which forced the rest to do the same.
So what I learned, is that no matter if it's bosses, employees, clients or companies: There is always an idiot who will do it for less. He may not be able to live from what he gets. But that is why he's called an idiot in the first place. ;)
So he drags the standard to a new low for everyone else too, making the whole situation worse in general. This is true for markets where a company offers too cheap prices. For employees working for ridiculously low salaries. Clients letting companies rip them off. And bosses hiring even more incompetent employees.
But I have yet to find a solution, other than just accepting that such people exist, and standing by your own self-value and feeling of what you see as a fair deal.
Re:In my experience, no. (Score:3, Interesting)
Only if they have money to spend.
Hey! I've in the situation like that.
Management quickly realized that crisis is coming (.Com buble) to our niche market. And their decision was questionable (and actually job threatening to me) but in the end saved the company: they pumped production of cheap offering (making it even cheaper), expecting that manageable higher-end expensive systems wouldn't sell at all (for which I was writing control software). And there was period of 13 month when no higher-end systems were sold. Yet, company managed to survive by cutting off only contractors - not a single full-time employee were fired.
Now to the point. When I spoke to management about the crisis and their handling of it, they simply told that industry wouldn't stop working - they would need equipment, but they will not have money to buy something new or expensive.
In the end that strategy played off: there were much less sales and support/maintenance something like doubled (can't buy -> but have to do work -> better maintain existing equipment).
P.S. A sort of hypocrisy in behavior of public companies also showed itself. Most were banned by shareholders from buying anything. Yet, several such clients forked us for maintenance quite a big buck - which would have allowed them otherwise to buy a completely new equipment.