• (cs) in reply to zerzerzedfsfqsazerzerazeraazer
    zerzerzedfsfqsazerzerazeraazer:
    snoofle:
    The problem is the management doesn't realize that this is mostly a software shop. And never will. WTF-Inc will crash and burn within 6 months, and MegaCorp, upon investigation, will clean house and start over.
    Out of curiositiy: where is MegaCorp in all this? Are they aware of this and/or what is their opionion about the 'stupid'
    From personal experience I know this story is pure fabrication: If it were true, it would be about WTF-Inc's problems with the mandatory migration to MegaCorp's systems, not further expansion of WTF-Inc's systems.
  • zaerzaerazerazerzezerzerzerzer (unregistered) in reply to snoofle
    snoofle:
    @Where is Mega Corp in all this? Blissfully unaware

    That's a bit unfortunate.. it would be intresting to know their take on this.. (given that they - at least occasionally - displayed some common sense)

  • (cs)

    Surely TRWTF is JMS?

    I can't really claim expertise in this, but all those design-by-committee technologies just scream "1990s" to me. Java EE, JNDI, JMS, EJB, CORBA, JWTF. Bloated, overengineered cruft designed for ancient versions of Java by people who tried to please everyone but ended up pleasing no one.

  • (cs) in reply to C_K
    C_K:
    That sounds better than the process here.

    Gather requirements: 15 min verbal Functional design: on the fly Detailed design: you already did "design" Developer ramp up: why aren't you typing yet? Coding: You'd be done if you didn't waste time on design and research. Developer testing: Just stop making mistakes. QA testing: We can't afford to hire people to just sit around testing things. Integration testing: Throw it live and see what happens. Stress testing: Take an Excedrin. Acceptance testing: Why is this @#$% broken?

    Hey! I used to work there! How's it going at (insert name of Fortune 500 company)?
  • (cs) in reply to locallunatic
    locallunatic:
    Steve The Cynic:
    The Legendary SNOOFLE:
    It was my own fault for thinking that I could fix "stupid".
    No, sorry, you can't fix "stupid".
    Yes you can fix stupid; you fix it for everyone else with method of choice, a shovel, and empty rural block of land.
    The people who say this have never tried to dig in an empty rural block of land.

    Very difficult. Lots of roots. Farmland better.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    Because you can't fix stupid and dilligent.

    Kurt von Hammerstein-Equord:
    I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief.
  • (cs) in reply to DrPepper
    Matt Westwood:
    Hunt down and kill all the children, and make sure they never spawn again.

    <Tiny Tina voice> BURN ALL THE BABIES!

    DrPepper:
    Old 30-year veteran:
    FAIL. You're a consultant (or employee). Offer your opinion (if asked), then implement their way. When it fails, fix it. If it incurs massive technical debt, who cares? You're making money to fix it!
    If you're a WTF programmer, that works -- charge them money to do it wrong, then charge them money to do it right. But some of us have higher standards -- we feel bad when we do it wrong. We'd rather leave than continue to do it wrong.

    Correct. Some of us, like snoofle, take pride in our work.

  • (cs)

    I know of few things more dangerous than a management-type learning about Agile. They'll round-peg that square hole until either you're doing Frankenstein waterfall (which, as someone else pointed out, happened here), or your boss starts assigning blame because you aren't building software any faster (which the Agile manifesto technically does not promise, but what almost all Agile evangelists interpret "working software" to mean).

  • (cs) in reply to Some Damn Yank
    Some Damn Yank:
    locallunatic:
    Steve The Cynic:
    The Legendary SNOOFLE:
    It was my own fault for thinking that I could fix "stupid".
    No, sorry, you can't fix "stupid".
    Yes you can fix stupid; you fix it for everyone else with method of choice, a shovel, and empty rural block of land.
    The people who say this have never tried to dig in an empty rural block of land.

    Very difficult. Lots of roots. Farmland better.

    Well yeah, but if you are going to do proper disposal meat grinders, amonia and/or bleach (but not at the same time!), and a drain is the proper way to get rid of human waste.

  • programmerj (unregistered) in reply to Jeremy

    As a "25 year veteran" I take slight offense to your generalization of older developers. I take pride in continuous self-education...we aren't all dinosaurs.

    Now get the hell off my lawn!

  • (cs)

    Shouldn't Snoofle be bolded instead of Manoj?

  • C_K (unregistered) in reply to Some Damn Yank
    Some Damn Yank:
    C_K:
    That sounds better than the process here.
    Hey! I used to work there! How's it going at (insert name of Fortune 500 company)?

    Actually, it's a three man shop. The CEO finds investors, the marketing director is my direct boss and I am tasked with development and system admin.

  • (cs) in reply to zaerzaerazerazerzezerzerzerzer
    zaerzaerazerazerzezerzerzerzer:
    snoofle:
    @Where is Mega Corp in all this? Blissfully unaware

    That's a bit unfortunate.. it would be intresting to know their take on this.. (given that they - at least occasionally - displayed some common sense)

    Mega Corp does not have any systems even remotely like those of WTF-Inc. They bought WTF-Inc to jump in and catch up to the rest of the industry. Just after the buyout, we were mandated to migrate everything, which turned out to be a logistical nightmare, given the wtf-state-of-things here. As such, it was dialed back to: just restrict facility access, db access, encrypt passwords, and similar things. However, nothing has been migrated to big-corp type "process".

    I just came from a meeting with some higher ups at Mega Corp to turn in my final code-audit reports, and let them know I was leaving. Naturally, they asked Why? I laid it all out for them. They were not happy. Apparently, they had me penciled in for leading that charge down the road. It's going to hit the fan in the next week or so; unfortunately, I won't be here to see what happens, so there's no way to let you guys know...

  • n+1 (unregistered)

    "JWTF"

    LOL.

  • (cs) in reply to DrPepper
    DrPepper:
    eViLegion:
    "Half a person", or "1 or 2 people"?
    One person, half-time. For those of you who are counting: We went from 1 local QA plus 20 off-site QA to 1.5 local QA. And they expect the same amount of testing to get done.

    If you include that added testing of your patience, they're probably right.

  • Kevin (unregistered)

    The waterfall development cycle broken down into 2-week "Agile Iterations" cracked me up!

  • (cs) in reply to Some Damn Yank
    Some Damn Yank:
    The people who say this have never tried to dig in an empty rural block of land.

    Very difficult. Lots of roots. Farmland better.

    Clearly you make the stupid do the digging. Are you stupid or something?

  • Jay (unregistered)
    Gather customer requirements - 2 weeks Functional Design - 2 weeks Detailed Design - 2 weeks Developer Ramp Up - 2 weeks (familiarizing themselves with the specific code to be modified, new libraries, etc) Coding - 2 weeks Developer Testing - 2 weeks QA Testing - 2 weeks Integration Testing - 2 weeks Stress Testing - 2 weeks Customer acceptance testing - 2 weeks

    There are so many flaws to this schedule that I hardly know where to begin. Not that I doubt that someone came up with this schedule. I've had very similar ones imposed on me. But it's insane.

    1. As you say, coding squeezed in as a mere 10% of the total project.

    2. Supposing you can get customer requirements in only 2 weeks. This is only possible for the most trivial of projects. It's hard to even manage to schedule a meeting for all relevant people within 2 weeks, never mind get them to agree on the requirements.

    3. No time provided to fix problems that come out of testing. The result of testing is almost never, "yup, everything works as expected". It's almost always, "Here's a long list of all the bugs. And here's an even longer list of all the things that, now that we've seen what we asked for in operation, we realize that what we asked for isn't what we really need."

  • (cs)

    Just an observation:

    Why is it that every new software methodology is touted as the cure-all for not delivering on time. Then when it doesn't work, another more modern methodology pops up and the PHBs want to go that route.

    Every time, there is a WTF in waiting as the old methodologies fail, and the new ones with great excitement wander down the blissful road to the next failure.

    The same can be said of some software languages to some extent.

    So, when you get the directive from "higher up" that they have found the next great thing, treat it with a grain of salt.

  • Jay (unregistered)

    On my very first IT job, 30 years or so ago, someone had a poster of the REAL systems development life cycle. It went something like this (recreating from memory):

    1. Collection of user requirements
    2. Coding
    3. Testing
    4. Collection of real user requirements
    5. Growing panic
    6. Search for the guilty
    7. Punishment of the innocent
    8. Bonuses and promotions for the non-participants
  • Jay (unregistered) in reply to herby
    herby:
    Just an observation:

    Why is it that every new software methodology is touted as the cure-all for not delivering on time. Then when it doesn't work, another more modern methodology pops up and the PHBs want to go that route.

    Every time, there is a WTF in waiting as the old methodologies fail, and the new ones with great excitement wander down the blissful road to the next failure.

    The same can be said of some software languages to some extent.

    So, when you get the directive from "higher up" that they have found the next great thing, treat it with a grain of salt.

    Ditto.

    When I started in this business in 1980 (yes, there were computers then), all the industry experts were pushing "structured programming". This was apparently successful enough that people started calling every new thing "structured": "structured design" (which had nothing to do with structured programming), "structured testing", etc.

    But for some mysterious reason, this did not solve all of our problems. So the next big thing was "top-down design".

    A few years later there was "modular programming", which in practice was pretty much the opposite of top-down design. Funny how that worked: X didn't solve all of our problems, so let's try anti-X.

    Then came "object-oriented programming".

    Then a few years back we got a rush of new scheduling methodologies: agile, test-driven development, etc.

    Each new thing is always touted as the solution to all of our problems. I have fond memories of hearing over an over how if we just use the new methodology, it will no longer matter if our programmers are inexperienced or unskilled, somehow the magic of the new methodology will bring the project so a successful conclusion. A couple of times I've asked how this could possibly be true, and of course it is explained to me how I am just not understanding how the new system works if I could possibly ask such a foolish question. Maybe next time I'll ask why, if the skill level of the programmers doesn't matter, why do we need programmers at all? Why not just hire some people who couldn't qualify for fast food jobs? Why not just rent some monkeys from the zoo?

    Oh, don't get me wrong, some of these new methodologies have good ideas in them. But I have yet to see one that really solves all of our problems. Most are small steps in the right direction. Some are steps in the wrong direction. Many could be debated endlessly.

  • Anomaly (unregistered) in reply to Jay
    Jay:
    herby:
    Just an observation:

    Why is it that every new software methodology is touted as the cure-all for not delivering on time. Then when it doesn't work, another more modern methodology pops up and the PHBs want to go that route.

    Every time, there is a WTF in waiting as the old methodologies fail, and the new ones with great excitement wander down the blissful road to the next failure.

    The same can be said of some software languages to some extent.

    So, when you get the directive from "higher up" that they have found the next great thing, treat it with a grain of salt.

    Ditto.

    When I started in this business in 1980 (yes, there were computers then), all the industry experts were pushing "structured programming". This was apparently successful enough that people started calling every new thing "structured": "structured design" (which had nothing to do with structured programming), "structured testing", etc.

    But for some mysterious reason, this did not solve all of our problems. So the next big thing was "top-down design".

    A few years later there was "modular programming", which in practice was pretty much the opposite of top-down design. Funny how that worked: X didn't solve all of our problems, so let's try anti-X.

    Then came "object-oriented programming".

    Then a few years back we got a rush of new scheduling methodologies: agile, test-driven development, etc.

    Each new thing is always touted as the solution to all of our problems. I have fond memories of hearing over an over how if we just use the new methodology, it will no longer matter if our programmers are inexperienced or unskilled, somehow the magic of the new methodology will bring the project so a successful conclusion. A couple of times I've asked how this could possibly be true, and of course it is explained to me how I am just not understanding how the new system works if I could possibly ask such a foolish question. Maybe next time I'll ask why, if the skill level of the programmers doesn't matter, why do we need programmers at all? Why not just hire some people who couldn't qualify for fast food jobs? Why not just rent some monkeys from the zoo?

    Oh, don't get me wrong, some of these new methodologies have good ideas in them. But I have yet to see one that really solves all of our problems. Most are small steps in the right direction. Some are steps in the wrong direction. Many could be debated endlessly.

    So we could munge them all together to create the first enterprisey methodology. Schedules are released in XML, Requirements collected in an access database, coders, designers and other personnel managed through excel spreadsheets.

    IT WILL BE THE NEW GOLDEN STANDARD.

    Captcha: persto - And persto! All the problems are solved.

  • nqdenise (unregistered)

    Am I reading this correctly? So they came up with a plan where every sprint is the next phase of waterfall development? That is incredibly entertaining!

  • (cs)

    It never seems to occur to most managers that "just getting on with it" is actually a pretty efficient way of getting stuff done.

    Though, to be fair, I've never actually been managed by those managers, so possibly I'm making that shit up.

  • (cs) in reply to eViLegion
    eViLegion:
    Some Damn Yank:
    The people who say this have never tried to dig in an empty rural block of land.

    Very difficult. Lots of roots. Farmland better.

    Clearly you make the stupid do the digging. Are you stupid or something?
    When I dispose of bodies I try to minimize the witnesses. That means digging the shallow graves myself.

  • Paul Neumann (unregistered) in reply to Some Damn Yank
    Some Damn Yank:
    When I dispose of bodies I try to minimize the witnesses. That means digging the shallow graves myself.
    They dig, you fill. *headpalm*
  • (cs) in reply to Paul Neumann
    Paul Neumann:
    Some Damn Yank:
    When I dispose of bodies I try to minimize the witnesses. That means digging the shallow graves myself.
    They dig, you fill. *headpalm*
    Sorry, but I don't have an army of minions (yet). The only people I could get to dig a grave for me would be friends or relatives, and I don't have enough of either to squander.
  • (cs) in reply to Some Damn Yank
    Some Damn Yank:
    Paul Neumann:
    Some Damn Yank:
    When I dispose of bodies I try to minimize the witnesses. That means digging the shallow graves myself.
    They dig, you fill. *headpalm*
    Sorry, but I don't have an army of minions (yet). The only people I could get to dig a grave for me would be friends or relatives, and I don't have enough of either to squander.
    Maybe a demonstration is in order.

    Here's a shovel. Start digging.

    Don't worry, I will dispose of the witnesses when you're finished.

  • s73v3r (unregistered) in reply to Old 30-year veteran
    Old 30-year veteran:
    Naturally, after reviewing all the changes we've made, he wants to undo everything to put it back to the way he designed it.

    I resisted and pushed it up to senior management...

    FAIL. You're a consultant (or employee). Offer your opinion (if asked), then implement their way. When it fails, fix it. If it incurs massive technical debt, who cares? You're making money to fix it!

    Or he's going to be the one blamed when shit goes pear-shaped. Do you honestly think they're going to listen to a contractor over the word of someone that they promoted and then put in charge?

    CAPTCHA: Causa - Despite the deficiencies in the design, they're gonna say the causa of the problem is the contractor.

  • s73v3r (unregistered) in reply to Popeye
    Popeye:
    The 20 week Sprint is awesome. I'm a contractor and if I sat on my ass for 20 weeks to produce 2 weeks of product I'd be thrown out on my ass and run over by a bus. You gotta love those G-jobs. Great for a contractor and you can line up 3 at a time and triple bill the shit outta them.

    This one isn't a G-job. This is private sector. Once again proving that government or private doesn't matter, as any organization of sufficient size can be run by incompetent people.

  • s73v3r (unregistered) in reply to eViLegion
    eViLegion:
    Some Damn Yank:
    The people who say this have never tried to dig in an empty rural block of land.

    Very difficult. Lots of roots. Farmland better.

    Clearly you make the stupid do the digging. Are you stupid or something?

    I've not really understood how this works. Unless the person about to be executed was stalling for time, why would you dig? What're they gonna do, shoot you?

  • Apeiron (unregistered) in reply to s73v3r
    s73v3r:
    eViLegion:
    Some Damn Yank:
    The people who say this have never tried to dig in an empty rural block of land.

    Very difficult. Lots of roots. Farmland better.

    Clearly you make the stupid do the digging. Are you stupid or something?

    I've not really understood how this works. Unless the person about to be executed was stalling for time, why would you dig? What're they gonna do, shoot you?

    Simple: If they don't waste time while digging, it ends quickly for them. If they start stalling, you start shooting toes off. Then fingers. Etc. You just have to find the right motivation to show them that not stalling will end better for them.

  • (cs) in reply to Jeremy
    Jeremy:
    They learned gotos and breaks, their car gets 40 rods to the hogshead, and that's the way they likes it.

    That's pretty bad, even for a car as old as Grandpa Simpson's must have been.

    My car gets more like a half million rods to the hogshead.

    http://www.wolframalpha.com/input/?i=500000+rods+%2Fhogshead+to+miles+%2F+gallon

  • Joe (unregistered)

    Things like "My software architecture is better than his software architecture" is always a bad start in a discussion with management. What they hear is "That other software developer is playing with my toy. Stop him."

    However, what they react to is "This software is going to be changed in a way which will incapacitate it within 3 weeks from now. Production it at risk. The following requirements will fail: X, Y, Z. I'm going to put that in an email before the end of the day and you will be the recipients." In your case, list some from the NFRs realm for X, Y, Z.

    Add some horrific and colorful consequences from the business perspective.

    Take! Their! Damn! View!

    But I forgot: if you did this, you wouldn't work in software development, but in product management.

    If you are really committed to the project, don't rant software developer stories but learn to argue.

  • (cs) in reply to locallunatic
    locallunatic:
    Some Damn Yank:
    locallunatic:
    Steve The Cynic:
    The Legendary SNOOFLE:
    It was my own fault for thinking that I could fix "stupid".
    No, sorry, you can't fix "stupid".
    Yes you can fix stupid; you fix it for everyone else with method of choice, a shovel, and empty rural block of land.
    The people who say this have never tried to dig in an empty rural block of land.

    Very difficult. Lots of roots. Farmland better.

    Well yeah, but if you are going to do proper disposal meat grinders, amonia and/or bleach (but not at the same time!), and a drain is the proper way to get rid of human waste.

    Rubbish.

    Meat grinders, burger buns and a rock festival nearby.

  • Someone (unregistered) in reply to Apeiron
    Apeiron:
    Simple: If they don't waste time while digging, it ends quickly for them. If they start stalling, you start shooting toes off. Then fingers. Etc. You just have to find the right motivation to show them that not stalling will end better for them.
    So what do you do after you shoot of the first toe, the person says "OK fine I'll dig", and then comes after you with the shovel?
  • (cs)

    Here's how you should have handled it:

    JD: So I can just synchronize all the methods in all the classes; that will keep things coherent, right? You: No. JD: But it COULD work, right? You: No. JD: But I CAN do it that way? You: No.

    When there really is only one right way to do things, don't even give people the options to choose wrong ways, because absolutely invariably, they will.

  • (cs) in reply to Strolskon
    Strolskon:
    > JD: So I can just synchronize all the methods in all the classes; that > will keep things coherent, right?

    That's exactly what someone did to my open source project after I gave him commit access :(

    Branch, review, merge.

  • Norman Diamond (unregistered) in reply to snoofle
    snoofle:
    ANON:
    1. Manoj is an Indian name, so I assume he worked from offshore.
    Close; Manoj IS Indian, but he works on site.
    If the guy is located in America and has an American Indian name then one can guess he doesn't work from offshore, but if the guy has an English name then one should assume he works in the UK, or if he has a Japanese name then one should assume he works in Japan.

    But what about me? I have an English name but I've never worked in the UK. I'm working onshore, right here in Japan. My boss has a Japanese name but he's working offshore, in Canada.

    Now, which site is on site? It might be onshore somewhere, but it's offshore from Japan.

  • fleg (unregistered) in reply to Jeremy
    Jeremy:
    Meh. Given the choice between the 2 I think I'd rather have "6 months out of school" guy over "30 year veteran" guy.

    I'm sure there are some good ones that keep up, but in my experience those are more like to be the "set in their ways" "you kids and your damned 'functions' and 'loops'" guys.

    They learned gotos and breaks, their car gets 40 rods to the hogshead, and that's the way they likes it.

    I agree. And they're more likely to listen and try to learn (especially if they're taking over an important position). And they probably have a longer future (although I'll grant not necessarily with the company).
    In fact, I haven't worked with too many awesome 30 year veterans, and it seems people peak somewhere between 3 and 10 years, and then either:

    1. Move away from IT
    2. Lose interest because technology changes
    3. Plateu (remarkably rare)
    4. Resist change, and insist COBOL is still awesome
    5. Become managers and lose any recollection of life as a code monkey
    6. Hang around as 'experts' - where they get paid well, have no input in anything, and nobody actually knows what would happen if you sacked them

    most of the 30 year types I've met are somewhere between 2,4, and 6....

    Myself, I think I've peaked and like to think I'm at 3, but I can see a lot of 4 in me as well (%s/COBOL/C/)...

  • Vlad Patryshev (unregistered)

    Oh, the last part looks familiar. In one of my previous companies I had some data that refreshed regularly cached in an immutable table, similar to double buffering in video. Then passing it to a junior guy that happened to be a friend of my manager, the talk was like this.

    • need to write 'synchronized'
    • it's immutable, it does not need to be synchronized
    • still you need to write 'synchronized'
    • immutable structures don't need synchronization
    • you need 'synchronized'

    etc.

    Since he was the manager's friend, not me, guess who, in the eyes of the whole ladder of idiots, was wrong here eventually.

  • Jim (unregistered) in reply to name

    quote user="snoofle"]BTW: The place where I'm going is protected by 7x24 armed guards, floor to ceiling bullet proof glass, and bidirectional electronic locks on all doors, so there's no way I'm getting my clue bat in there; Mark is the new keeper of the bat, so show him some love...[/quote]They caught up with you, eh? Don't worry, you could still win the appeal....

  • gsdz (unregistered) in reply to DrPepper
    DrPepper:
    Old 30-year veteran:
    FAIL. You're a consultant (or employee). Offer your opinion (if asked), then implement their way. When it fails, fix it. If it incurs massive technical debt, who cares? You're making money to fix it!
    If you're a WTF programmer, that works -- charge them money to do it wrong, then charge them money to do it right. But some of us have higher standards -- we feel bad when we do it wrong. We'd rather leave than continue to do it wrong.
    Exactly. And even the most awesome of us occasionally let a bug in, or are the only ones that understand (so are kept just in case) or have misinterpreted that when the client said they wanted A rather than B they actually meant C which might be similar to C. Also the client decided that what they wanted originalyl doesn't actually work how they expected. etc ad infinitum
  • grisle (unregistered) in reply to Joe
    Joe:
    Things like "My software architecture is better than his software architecture" is always a bad start in a discussion with management. What they hear is "That other software developer is playing with my toy. Stop him."

    However, what they react to is "This software is going to be changed in a way which will incapacitate it within 3 weeks from now. Production it at risk. The following requirements will fail: X, Y, Z. I'm going to put that in an email before the end of the day and you will be the recipients." In your case, list some from the NFRs realm for X, Y, Z.

    Add some horrific and colorful consequences from the business perspective.

    Take! Their! Damn! View!

    But I forgot: if you did this, you wouldn't work in software development, but in product management.

    If you are really committed to the project, don't rant software developer stories but learn to argue.

    It doesn't work out that way. You tell them they're doing it wrong and they're going to crash and burn, and they ask "what would you know".

    Then when it crashes and burns it's because you didn't do it their way properly - you sabotaged it. You even sent out the emails suggesting this would happen (whoich nobody could predict, because they couldn't) ergo you are a saboteur)

  • The Vehicle Formerly Known as PathFinder (unregistered) in reply to Hpesoj
    Hpesoj:
    ANON:
    1. Manoj is an Indian name, so I assume he worked from offshore.
    Surely it's a pseudonym? Looks like a name spelt backwards to me.
    I can attest it is not a pseudonym. I once fired a Manoj for being utterly incompetent, slow witted and unable to learn or understand even the smallest things. It is a good thing for him that breathing is controlled autonomous by the respiratory control center.

    Perhaps I should let that shop should hire me before it is too late?

  • The Vehicle Formerly Known as PathFinder (unregistered) in reply to Jay

    [quote user="Jay"][quote user="herby"] Many could be debated endlessly.[/quote]

    Which is exactly why we have internet forums!

  • (cs) in reply to Jay
    Jay:
    herby:
    ... when you get the directive from "higher up" that they have found the next great thing, treat it with a grain of salt.

    Ditto.

    When I started in this business in 1980 (yes, there were computers then), all the industry experts were pushing "structured programming". ... Each new thing is always touted as the solution to all of our problems. I have fond memories of hearing over an over how if we just use the new methodology, it will no longer matter if our programmers are inexperienced or unskilled, somehow the magic of the new methodology will bring the project so a successful conclusion. A couple of times I've asked how this could possibly be true, and of course it is explained to me how I am just not understanding how the new system works if I could possibly ask such a foolish question...

    Any project manager who doesn't have a well-thumbed copy of The Mythical Man-Month on their shelf is not worth working with.

  • Jon (unregistered) in reply to Jay

    [quote user="Jay"][quote]

    1. Supposing you can get customer requirements in only 2 weeks. This is only possible for the most trivial of projects. It's hard to even manage to schedule a meeting for all relevant people within 2 weeks, never mind get them to agree on the requirements.

    [/quote]

    Not two weeks, but one day. This is called "scrum".

  • zerzerzedfsfqsazerzerazeraazer (unregistered) in reply to snoofle
    snoofle:
    I just came from a meeting with some higher ups at Mega Corp to turn in my final code-audit reports, and let them know I was leaving. Naturally, they asked Why? I laid it all out for them. They were not happy. Apparently, they had me penciled in for leading that charge down the road. It's going to hit the fan in the next week or so; unfortunately, I won't be here to see what happens, so there's no way to let you guys know...

    I'm sure you'll find a way to let us know...

    From your previous posts it looked like you had a good relationship with your boss (now B+1) and were like minded (given that he was aware that you are posting about it and even informing/pointing several things out)... So maybe that's an angle to get the information out. (Assuming the relationship is still good and the bridge was not burned)

  • (cs)

    Hi snoofle.

    I'm ambivalent on this news: from one point of view, you're leaving the WTF, Inc and will hopefully land in more sane environment. From other, we are losing steady stream of 'how it shouldn't be done' stories. Maybe there's some guy in WTF, Inc you are going to keep contact with? A lunch together every week, a story is shared, everyone is happy. Or you could even point him here, if you aren't afraid of deanonymization, of course.

    That said, good luck in the new place.

Leave a comment on “The Last Straw”

Log In or post as a guest

Replying to comment #:

« Return to Article