Forgot your password?
typodupeerror
Programming IT Technology

Developer Stigma After a Bad Or Catastrophic Release? 223

Posted by Soulskill
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?"
This discussion has been archived. No new comments can be posted.

Developer Stigma After a Bad Or Catastrophic Release?

Comments Filter:
  • by whatthef*ck (215929) * on Saturday July 11, 2009 @12:29PM (#28660927) Homepage

    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.

    • by Brian Gordon (987471) on Saturday July 11, 2009 @12:35PM (#28660987)

      then I don't want to work for them

      Must be nice to be 5 years ago.

      • by Kjella (173770) on Saturday July 11, 2009 @12:53PM (#28661167) Homepage

        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.

        • by dublindan (1558489) on Saturday July 11, 2009 @01:58PM (#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.
          • by ultranova (717540)

            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 capitalis

            • leading to an exponential growth in wealth differences

              What's the variable on the x axis? Couldn't you just use "big"?

              • by nbauman (624611)
                It's his way of saying that y(n)=a(n)e^bx) has different values of b for different values of n.
            • Re: (Score:3, Interesting)

              by ThePhilips (752041)

              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 t

          • Re: (Score:2, Insightful)

            by BitZtream (692029)

            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.

      • by JAlexoi (1085785)
        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.
    • by DerekLyons (302214) <fairwater@gmail. c o m> on Saturday July 11, 2009 @12:57PM (#28661205) Homepage

      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.

      • by The End Of Days (1243248) on Saturday July 11, 2009 @01:22PM (#28661403)

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

      • Re: (Score:3, Insightful)

        by Bogtha (906264)

        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 know

        • by Savage-Rabbit (308260) on Saturday July 11, 2009 @02:30PM (#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.

          • by John Hasler (414242) on Saturday July 11, 2009 @02:58PM (#28662127) Homepage

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

          • by Bogtha (906264) on Saturday July 11, 2009 @03:03PM (#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.

            • Exactly. Even if the developers were the second most retarded bunch of 'tards to ever lick the windows of a short bus, an even more retarded bunch started the problem by hiring them.
          • 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.

            Yes, you can.

            Sure, it's the senior design staff that is responsible for making poor design decisions ... but it's management that made the decision to hire those particular individuals in the first place! It's management that didn't put into place the proper processes to assure success. Truth is, a well-thought-out design process won't allow major disasters to happen very often, but that costs money and time. Yes, mistakes sometimes slip by, but if you have proper review and testing procedures in place y

      • Re: (Score:3, Interesting)

        by Hurricane78 (562437)

        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 j

        • Re: (Score:3, Interesting)

          by cerberusss (660701)

          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 he

      • by rakslice (90330)

        Maybe... In the trenches you can learn from your co-workers, and you can learn from your mistakes. But it's often lonely at the top, "White boy welfare" [scripting.com] makes even the latter difficult.

    • Re: (Score:3, Interesting)

      by fooslacker (961470)

      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 sof

    • by wrook (134116)

      I've worked on some flops in my time too. At subsequent interviews I'm pretty candid about what went wrong. For example on one project it became clear that we were building a product that nobody would want to use. Eventually the project was canned because it was simply stupid. I'm invariably asked what I would do differently in those situations.

      I respond that when I see a potential problem, I discuss it with my manager. I point out possible solutions and indicate the cost of remedial action. I try to

  • by rlp (11898) on Saturday July 11, 2009 @12:33PM (#28660965)

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

  • by flyingfsck (986395) on Saturday July 11, 2009 @12:36PM (#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.
    • by Guysmiley777 (880063) on Saturday July 11, 2009 @01:05PM (#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.
      • by Quothz (683368) on Saturday July 11, 2009 @01:28PM (#28661451) Journal

        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.

      • by DeVilla (4563)

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

    • by TheMCP (121589)

      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.

    • by ryen (684684)

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

      There, fixed that for you.

  • by voss (52565) on Saturday July 11, 2009 @12:44PM (#28661053)

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

    • by Herkum01 (592704)

      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.

    • by Bigjeff5 (1143585)

      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 deve

  • Because who would want to hire the last few software engineers who stayed there through to the last?
  • A solution (Score:5, Funny)

    by bunyip (17018) on Saturday July 11, 2009 @12:54PM (#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. :-)

  • by Anonymous Coward

    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 st

    • Re: (Score:2, Insightful)

      by darpo (5213)
      I really can't buy this. Given that companies have no loyalty to workers these days, I believe workers should treat companies the same way. I'm sure in your current role you'd *like* people to be committed and all that. But the reality is that we go to work for money, not out of the goodness of our hearts. Workers need to protect themselves, including by jumping from a sinking ship if necessary, because they have no guarantee that the employer would take care of *them* if situations were reversed (i.e. when
  • by nahdude812 (88157) * on Saturday July 11, 2009 @01:02PM (#28661247) Homepage

    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.

    • 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 (Score:2, Insightful)

    by Gorobei (127755)

    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 cle

    • by JAlexoi (1085785)
      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?
      • by Gorobei (127755)

        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.

        • by JAlexoi (1085785)
          There are some people that are in IT not for the paycheck. And sometimes sticking to the project till the absolute end is a very good experience.
          And a lot of times, the projects fail because of the third parties involvement, or lack of involvement. In those cases nothing a developer can suggest will help the project.
          • by Gorobei (127755)

            ok, so stick to the end once just to see what a pointless, soul-draining waste of time it is. Then never do it again.

            Learn to fail fast: give it 100% effort, try to make it work, but never lose sight of the big picture. If it is destined to fail, try to fix it. If you can't fix it, go find something you can make a difference on.

    • by TheMCP (121589)

      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 unrealis

    • Re: (Score:2, Insightful)

      by lemur666 (313121)

      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,

    • Re:Just quit (Score:4, Insightful)

      by SirLurksAlot (1169039) on Saturday July 11, 2009 @03:14PM (#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.

      • by Gorobei (127755)

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

        • by JAlexoi (1085785)

          I've dumped clients when what they want is absurd

          I sense a major client expectation management problem in your character. Not good...
          If you do not know what a client requests upon project start, it's usually a failed project to start. Fire your sales/contract negotiator/project manager.

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

          Apparently you could care less.

          • by Gorobei (127755)

            If you do not know what a client requests upon project start, it's usually a failed project to start. Fire your sales/contract negotiator/project manager.

            I don't think we're philosophically far apart here. Project start is the best place to have a go/no-go decision.

            I don't much use sales/contract negotiators, etc: just have an expert (senior programmer or whatever) flesh our the rough details with the client, report on the general situation (size, hardness, and sanity,) and we can make a decision in a fe

      • Re:Just quit (Score:4, Insightful)

        by Kjella (173770) on Saturday July 11, 2009 @08:32PM (#28664543) Homepage

        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.

  • by holophrastic (221104) on Saturday July 11, 2009 @01:08PM (#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: (Score:3, Insightful)

      by PPH (736903)

      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

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

    • - a project that takes three years to become profitable

      This notion worries me a little. Because it suggests you are satisfied with picking the low-hanging fruit. The company with deep pockets and long term goals can be a brutally effective competitor - one that just might sweep up the best features of your niche product and weave them into his own before you can gain any traction.

      • That's not what I meant. I meant that the executive able to execute the same project in less time, is the more valuable executive. If a project is going to fail anyway, the better executive will make it fail faster.

  • by ddt (14627) <ddt@davetaylor.name> on Saturday July 11, 2009 @01:10PM (#28661329) Homepage

    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: (Score:2, Informative)

      by sigmabody (1099541)

      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 t

    • Re: (Score:3, Insightful)

      by JAlexoi (1085785)
      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 lit
  • Not a problem (Score:3, Informative)

    by PPH (736903) on Saturday July 11, 2009 @01:35PM (#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.

  • by Sadsfae (242195)

    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 enha

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

  • It is that programmers will ALWAYS fall on their feet, and office space wouldn't be lying would it?
  • 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,

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

  • 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

  • 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

  • by curmudgeon99 (1040054) <curmudgeon99 AT gmail DOT com> on Saturday July 11, 2009 @02:44PM (#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.)

    • 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.
      • 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
  • "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.
  • 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.
  • Have they ever become unhireable?

    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)

In every non-trivial program there is at least one bug.

Working...