Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Interviewing with a "reverse resume" (was: How can you tell when your project is headed for disaster?)

Expand Messages
  • Devin Mullins
    ... How do you take all these project failures to a job interview? Do you say, honestly, why you feel each one was a failure, and you were just a victim of
    Message 1 of 30 , May 1, 2005
      Phlip wrote:

      >Oh dear. One "reverse resume" coming up. The recurring theme is
      >technical success against overwhelming odds (some of which XP could
      >have reduced), followed by management fiascos...
      >
      >
      How do you take all these project failures to a job interview? Do you
      say, honestly, why you feel each one was a failure, and you were just a
      victim of happenstance? Do you try and downplay that part, and just
      point out your successes in the projects? etc. If they question whether
      or not a)you're the fault of some of these failures, or b)you're too
      picky, what do you do to combat that opinion?

      I'm not in that situation, mind you, but I like to ask questions about
      the extremes and then interpolate.
      ---
      Devin Mullins
      Intergalactic Teleport Industries, Inc.
      Chief Technical Officer
      Santa Martia, Mars
    • Phlip
      ... They are all _technical_ successes. Everyone knows .DOT com bosses are full of crap. Also, some aren t business failures, they are simply insufficiently
      Message 2 of 30 , May 1, 2005
        Devin Mullins wrote:

        > Phlip wrote:
        >
        > >Oh dear. One "reverse resume" coming up. The recurring theme is
        > >technical success against overwhelming odds (some of which XP could
        > >have reduced), followed by management fiascos...
        >
        > How do you take all these project failures to a job interview?

        They are all _technical_ successes. Everyone knows .DOT com bosses are
        full of crap.

        Also, some aren't business failures, they are simply insufficiently
        exploited technical success.

        Yes, it's a drag, but I don't present them all as business failures,
        and the interviewers don't ask...

        --
        Phlip
      • Phlip
        ... Okay, I l pretend this is an interview. (Meaning I won t scream mind your own business! ;) ... For a couple of them, I did not bail when the warning signs
        Message 3 of 30 , May 1, 2005
          Devin Mullins wrote:

          > How do you take all these project failures to a job interview?

          Okay, I'l pretend this is an interview. (Meaning I won't scream "mind
          your own business!";)

          > Do you
          > say, honestly, why you feel each one was a failure, and you were just a
          > victim of happenstance?

          For a couple of them, I did not bail when the warning signs appeared
          (such as the bosses start shifting us between projects every other
          week). For a couple of them, I went with a very high-risk project
          because I wanted the technical challenge and potential reward. In both
          cases, my loyalty was used against me.

          > a)you're the fault of some of these failures

          If a boss repeatedly disregards your advice, then blames you as a
          project starts failing, what would you do?

          --
          Phlip
        • John Carter
          ... I assume you have Death March by Ed Yourdon in your hand. If not go get it now. I have been fairly lucky by industry standards, but some of that luck was
          Message 4 of 30 , May 1, 2005
            > estherschindler wrote:

            > Or, if you're more experienced, you *have* learned to recognize the
            > danger signs, and you know it's time to (a) fix them or (b) bail

            I assume you have "Death March" by Ed Yourdon in your hand. If not go
            get it now.

            I have been fairly lucky by industry standards, but some of that luck
            was good judgment. I can think of several projects that came my way,
            that I scrambled like mad, pulled every string and called in every
            favour to avoid. Phew! And then tried to ignore the screams of woe in
            the background as I carried on my merry way...

            I have used all of these rules at one time or other, or wished that I
            had used one of these rules in hindsight. (Of course, these rules may
            be inverted to select where you are going to run to..)

            No one of these rules is enough to trigger the "flight" reflex, but if
            you see them coming together, hitch up yer skirts and RUN!

            1) If I can't think of how to build such a monster in a reasonable
            time, with the resources (currently) available, odds on no one else can
            either. (No matter what the PHB says, odds on it _will_ be with
            the resources currently available. They hardly ever give you more.)

            2) Analysis Paralysis. Signs of reams of analysis, but no short term
            (within weeks) deliverables.

            3) Dragon guarding the DB. Yes, the DB is mission critical to the
            organization, but if the dragon that guards the DB _doesn't_
            regard your project as mission critical, you're stuffed.

            4) Nobody selling what you build. Much as we geeks hate sales
            droids, if no one is actually selling or itching to sell what
            you're building.... Don't bother.

            5) Nobody building what's been sold. If the implementation team
            doesn't match up to the company hype. Run, don't walk.

            6) No identifiable (by name) customer for what is being sold(built)
            squealing for the product.

            7) Lots of code, no working prototypes, nobody has even tried to
            build the final deliverable. You have a herd of cats here and no
            tech-savvy management.

            8) Evil HR practices. eg. Everyone is on short term contract. Even
            guys who have been there for years are on contracts that don't
            extend beyond the end of year. The place is full of Bad Karma and
            staffed by suckers. Run! Now!

            9) Net vibe. If the 'net is populated with "XYZ sucks" and "XYZ
            shafted me" ... without a matching number "XYZ is Grreat", "XYZ
            treated me well", look for the nearest exit.

            10) Micky tech. Do a crude benchmark and a quick spreadsheet model of
            how much cpu/memory/disk/bandwidth the target platform has
            relative to the required task. If the answer isn't "lots" pad
            your time to delivery estimates by a factor of 3. Yes, I did say x 3.

            11) Midnight infestation of pasty faced overweight
            trogdolytes. Bad. Real Bad. Run away. If your cow-orkers don't
            have a life, they will expect you not to have one either.

            12) Fast & Filthy code cleanliness test. If the code is plastered
            with globals, statics and singletons. Be Afraid. Be Very
            Afraid. Maintaining that crock'o'shit will eat your life.


            13) (This is one I have never applied, but now as I look back over
            projects that did go skew vs those that went right for me, I will
            apply it in future....)

            Is your boss up to the project? Does he have the political punch
            and willpower to champion the project. Can he herd cats? Does he
            technically have a clue? Does he have a firm grip on the
            timelines? Mentally "interview" him and in your own mind measure
            whether he is fit for the role of managing you and your
            project. If not your options are to subtly support him or to head for
            the exit. Leaving him to flounder will just pull you into the mud
            first.



            John Carter Phone : (64)(3) 358 6639
            Tait Electronics Fax : (64)(3) 359 4632
            PO Box 1645 Christchurch Email : john.carter@...
            New Zealand


            "We are the Dyslexia of Borg. Your ass will be laminated. Futility is resistant."
          • James Carr
            Unfortunately, my first big project was a major disaster (that even now, a year after the project was proposed, it still sits on my list). I suppose a lot of
            Message 5 of 30 , May 1, 2005
              Unfortunately, my first big project was a major disaster (that even
              now, a year after the project was proposed, it still sits on my list).
              I suppose a lot of factors affected this project going down the tubes
              (along with my well being) and has been a lot of stress considering it
              was my first out of college project, but here's why I believe it went
              bad:

              - No direct contact with the client. Even now, a year later, I have
              never sat down with the client or ever spoken with them over the
              phone. All communication has been handled by another firm who is
              having us (or I rather) do the programming work for their client. Any
              questions I ever have when given requirements are deferred to the next
              meeting.

              - Unclear requirements. The cycle goes as follows. Clients give
              requirements (which are very vague and open ended), and then come back
              and will either go back on it (I was told at least one employment
              history should be required. I was recently told that I need to have
              that removed and allow people to complete the application without
              filling out an employment history), expand on it (they liked it so
              much they wanted more), etc.

              - I also think it is a bad sign when a client tries to define
              technical details. They have persistently asked that we disable the
              back button on the users browser, I refuse to do something like that
              (it serves no point since clicking back doesnt break anything, and the
              use of sessions keeps them from going back after the complete an
              application).

              - Small team, with people added near the end of the project. On the
              whole project, I was the sole programmer, and was expected to complete
              a job application processing system that produced applications in PDF
              format through an administration section. What sucked, however, was
              that the other firm decided to hire someone that would redo the whole
              thing in a day (or so they thought at the time). The person knew very
              little of the language used, and rewrote some key parts that removed
              the encapsulation the domain and data access layer by embedding domain
              and data access code into the view.

              -shifting projects, unable to focus on one thing. The whole time I
              worked on the project, I have had a multitude of other projects
              crossing my desk and bothering me. That's the most stressful part I
              suppose... all these projects cross my desk and I never get time to
              really sit down and iron out any kind of formal process.

              Finally, I'd have to say that another tell tail sign a project is
              headed for disaster is when management doesn't understand the
              architecture used perhaps. The chief complaint about the code I wrote?
              It was too complex. Just because I used OOP rather than a mish mash of
              html and "scriptlets".

              Of course, there's lots of other small details that possibly should be
              factored in. Compressed timescale (50 hours was the expected
              completion time), no formal project plan, no upfront design or
              planning (basically just identified what was needed and coded it), and
              perhaps some newbie programmer naivety (I had the old "I can do it in
              a week" mentality).

              Also, I'd defiantely say that ensuring your developers well being may
              be a major point. I was completely stressed out, even working overtime
              trying in vain to get things done, and at the same time feeling that
              my compensation wasn't enough (I'm paid $12/hourly for design,
              development, and deployment... and get yelled at when things go bad).

              Cheers,
              JC

              -

              On 4/30/05, estherschindler <esther@...> wrote:
              > I'm working on my next article for Software Test & Performance
              > magazine (stpmag.com). Ordinarily, my "best practices" column is about
              > the ways developers and testers do the right thing: the actions or
              > attitudes they've found successful. I'm taking a slightly different
              > approach, this time, by looking as crises in the making.
              >
              > We've all been there. The project goes horribly wrong. Neither the
              > users nor the development team is happy with the application (if it
              > ever did ship). And you wish you could erase the experience from your
              > resume (perhaps it would look better if you said you spent that year
              > playing piano in a house of ill repute?).
              >
              > With 20-20 hindsight, you realize that the signs were there all along;
              > you should have been able to recognize them. Or, if you're more
              > experienced, you *have* learned to recognize the danger signs, and you
              > know it's time to (a) fix them or (b) bail. I'd like to start a
              > discussion -- and I'd very much like to quote you -- about recognizing
              > when a project is in trouble. How do you know? How *should* you have
              > known? (For instance, a true example from my own past: I knew that
              > Sandra wasn't long for our start-up when she began bringing the daily
              > newspaper to work. And reading it.)
              >
              > These indications don't have to be directly related to the technology
              > or the team. It's a bit funny to use an example from an advertisement,
              > but this one provides a good demonstration. In a Bank of America ad
              > about their investments in crappy neighborhoods (they didn't phrase it
              > that way), the speaker said they knew they'd succeeded, "when the
              > flowerboxes begin showing up on front porches." Teams have the same
              > sort of indirect indications, too, for good or ill. Which ones have
              > you recognized -- or failed to recognize? Are there distinctions
              > between the signs that mean,"This shows we're in trouble, but it can
              > be fixed" and "We're about to explode. Quit NOW!"?
              >
              > I'm not sure how much XP has to do with this. Maybe you do. Do you
              > find that the problems crop up earlier with XP projects? Are the
              > danger signs different?
              >
              > As always: my editors hate it if I write, "Beezelbub, a guy I met in
              > an Internet discussion group, said...." If you say something pithy,
              > I'd like to quote you by name, company, title and location ("George
              > Smith, a programmer at Foo & Company in Pasadena, California,
              > says..."). Let me know that info by private e-mail, if necessary, or
              > at least give me a way to reach you.
              >
              > Esther Schindler
              > Contributing Editor, Software Test & Performance magazine
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.com
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
            • BenAveling
              ... There s blame and there s blame. For example, a prime minister I shall not name regularly blames failings on his underlings: Bad underlings: They didn t
              Message 6 of 30 , May 1, 2005
                >If a boss repeatedly disregards your advice, then blames you as a
                >project starts failing, what would you do?
                >

                There's blame and there's blame. For example, a prime minister I shall
                not name regularly blames failings on his underlings: "Bad underlings:
                They didn't tell me. Nobody told me. Not my fault. I was not told, I
                did not know. Bad bad underlings. "

                And he punishes these underlings with severe promotions...

                Regards, Ben A.
              • Phlip
                ... Golly! I ve certainly never heard of any national leader anywhere doing _that_! But thanks for the idea for another week or three of ZeekLand... ;-) --
                Message 7 of 30 , May 2, 2005
                  BenAveling wrote:

                  > There's blame and there's blame. For example, a prime minister I shall
                  > not name regularly blames failings on his underlings: "Bad underlings:
                  > They didn't tell me. Nobody told me. Not my fault. I was not told, I
                  > did not know. Bad bad underlings. "
                  >
                  > And he punishes these underlings with severe promotions...

                  Golly! I've certainly never heard of any national leader anywhere doing _that_!

                  But thanks for the idea for another week or three of ZeekLand... ;-)

                  --
                  Phlip
                  http://www.c2.com/cgi/wiki?ZeekLand
                • Ron Jeffries
                  Hi James ... Your job sounds to me like one with too little pay and too much crap, so at first blush I think you need a new one. However, given that you are
                  Message 8 of 30 , May 2, 2005
                    Hi James ...

                    Your job sounds to me like one with too little pay and too much
                    crap, so at first blush I think you need a new one. However, given
                    that you are stuck in this one, some additional comments and
                    questions below, based on what I'd be thinking if I were in your
                    shoes ...

                    On Sunday, May 1, 2005, at 10:18:40 PM, James Carr wrote:

                    > Unfortunately, my first big project was a major disaster (that even
                    > now, a year after the project was proposed, it still sits on my list).

                    When you say it sits on your list, do you mean that someone expects
                    you to get it done? Or something else. If the former, let me suggest
                    that you read and meditate on my article /Petition the King/, which
                    is not to be taken literally ... quite.

                    http://www.xprogramming.com/xpmag/PetitionTheKing.htm

                    > I suppose a lot of factors affected this project going down the tubes
                    > (along with my well being) and has been a lot of stress considering it
                    > was my first out of college project, but here's why I believe it went
                    > bad:

                    > - No direct contact with the client. Even now, a year later, I have
                    > never sat down with the client or ever spoken with them over the
                    > phone. All communication has been handled by another firm who is
                    > having us (or I rather) do the programming work for their client. Any
                    > questions I ever have when given requirements are deferred to the next
                    > meeting.

                    In this situation, two things I'd consider are:

                    1. Not starting on anything until my questions are answered, and
                    producing some kind of continuing, updated every day, chart,
                    indicating to all and sundry that all their important stuff is not
                    being progressed because they haven't answered my questions.

                    2. Whenever something has to be done over, use some kind of chart,
                    updated every day, indicating rework because of changing
                    requirement.

                    Mind you, with neither of these would I be trying to rub people's
                    nose in things, merely to make them apparent. And when something was
                    my mistake, I'd mark that differently on the chart than if it was a
                    requirements change.

                    I'd want everyone to be always aware of the wastage, to feel the
                    burn, but not to feel that I was trying to punish them, make them
                    look stupid, or attack them.

                    Check out http://www.xprogramming.com/xpmag/BigVisibleCharts.htm
                    and http://www.xprogramming.com/xpmag/natural.htm#N175

                    > - Unclear requirements. The cycle goes as follows. Clients give
                    > requirements (which are very vague and open ended), and then come back
                    > and will either go back on it (I was told at least one employment
                    > history should be required. I was recently told that I need to have
                    > that removed and allow people to complete the application without
                    > filling out an employment history), expand on it (they liked it so
                    > much they wanted more), etc.

                    See above for the cost of changes. Consider making the cost of each
                    thing you implement explicit. Cost of adding history, $150. Cost of
                    removing history, $15. (And the ratio should probably be about like
                    that: if it's more, I'd be wondering why.)

                    And, as I alluded to in an earlier posting, if they'll pay, why do
                    we care? It's another 15 bucks ...

                    > - I also think it is a bad sign when a client tries to define
                    > technical details. They have persistently asked that we disable the
                    > back button on the users browser, I refuse to do something like that
                    > (it serves no point since clicking back doesnt break anything, and the
                    > use of sessions keeps them from going back after the complete an
                    > application).

                    Why refuse? They want it. What do you care? So they're wrong, if
                    they are. It's their money.

                    If the system doesn't go back ... and I click back ... I might be
                    confused. They might even be right.

                    > - Small team, with people added near the end of the project. On the
                    > whole project, I was the sole programmer, and was expected to complete
                    > a job application processing system that produced applications in PDF
                    > format through an administration section. What sucked, however, was
                    > that the other firm decided to hire someone that would redo the whole
                    > thing in a day (or so they thought at the time). The person knew very
                    > little of the language used, and rewrote some key parts that removed
                    > the encapsulation the domain and data access layer by embedding domain
                    > and data access code into the view.

                    Tell me more about why it bothers you that these things happened,
                    please ...

                    > -shifting projects, unable to focus on one thing. The whole time I
                    > worked on the project, I have had a multitude of other projects
                    > crossing my desk and bothering me. That's the most stressful part I
                    > suppose... all these projects cross my desk and I never get time to
                    > really sit down and iron out any kind of formal process.

                    See Petition the King. You say that things "cross your desk". Maybe
                    they shouldn't be reaching your desk, or should be sent back marked
                    "Unprocessed", or a myriad of other things.

                    Maybe you would profit from batching things that are distracting,
                    and processing them when you need a break, to provide more time to
                    concentrate.

                    I'm not sure what you mean here by "formal process", so tell me
                    more. But maybe you could just add one element to the process, to
                    make it a little better, every now and again, rather than ironing
                    out a whole process.

                    > Finally, I'd have to say that another tell tail sign a project is
                    > headed for disaster is when management doesn't understand the
                    > architecture used perhaps. The chief complaint about the code I wrote?
                    > It was too complex. Just because I used OOP rather than a mish mash of
                    > html and "scriptlets".

                    I'm wondering these things:

                    1. Why is management even aware of the architecture?
                    2. Is the architecture really better in OO rather than a mish mash
                    of html and scriptlets?

                    > Of course, there's lots of other small details that possibly should be
                    > factored in.

                    > Compressed timescale (50 hours was the expected
                    > completion time),

                    What if you learned to complete the most important 50 hours' worth
                    in 50 hours?

                    What if you even learned to predict ahead of time what you would
                    have completed in 50 hours?

                    That's only a week or two of work ... couldn't you get pretty good
                    at predicting? Then you'd need to get good at completing what was
                    predicted ... what would stand in the way of that?

                    > no formal project plan,

                    what kind of formal project plan would help you? What about it makes
                    you think it would be helpful? What other ways to get that help
                    might be possible?

                    > no upfront design or planning (basically just identified what was
                    > needed and coded it),

                    What went wrong due to this? Why is it a problem? When were the
                    problems first identified? How much did they (or would they) cost to
                    fix? Why was it that much? Have you read /Refactoring/? Are you
                    doing anything like /Test Driven Development/?

                    > and
                    > perhaps some newbie programmer naivety (I had the old "I can do it in
                    > a week" mentality).

                    The thing I wish I had learned many years ago was how to predict how
                    much I could do in a week, and then do it. It's really quite easy,
                    it just takes practice and paying attention (accountability, Mr Beck
                    is now calling it I believe).

                    > Also, I'd defiantely say that ensuring your developers well being may
                    > be a major point. I was completely stressed out, even working overtime
                    > trying in vain to get things done, and at the same time feeling that
                    > my compensation wasn't enough (I'm paid $12/hourly for design,
                    > development, and deployment... and get yelled at when things go bad).

                    Your compensation isn't enough, unless you are in a federal prison.
                    Or perhaps India or China or one of those places. Even then,
                    actually.

                    However ... here's a story.

                    My wife's job had been getting more and more stressful. The
                    company had been acquired, they were having to take over work that
                    had been poorly done, and customers who were already angry. There
                    wasn't time to organize better, and managers were all thrashing
                    and doing strange things.

                    She was working infinite hours, stressing out like a fiend, then
                    driving to her parents' house to take care of them. She didn't
                    sleep at our house for four months. She was going crazy.

                    Finally, FINALLY!, in a meeting about what to do, she told her
                    boss that what to do was to terminate her.

                    The next two weeks, she went into the office, did what she could,
                    and came home without stress.

                    I'm glad she quit. But my guess is that all the weeks before that,
                    she could have gone into the office, done what she could, and come
                    home without stress. My guess is that we can always do that, that
                    stress is something we accept more than something that is provided
                    to us.

                    Might be a knack to learn ...

                    Good luck! Keep those questions and ideas coming!

                    Ron Jeffries
                    www.XProgramming.com
                    The main reason that testing at the end of a development cycle finds
                    problems is not that problems were put in near the end, it is that
                    testing was put off until then.
                  • James Carr
                    Hi Ron, Thanks for the reply (pretty in depth)! I agree I should seek alternatives, and at the moment I am hunting for alternative employment, but do need to
                    Message 9 of 30 , May 2, 2005
                      Hi Ron,

                      Thanks for the reply (pretty in depth)! I agree I should seek
                      alternatives, and at the moment I am hunting for alternative
                      employment, but do need to handle things at the current place in the
                      meantime. Anyway, to answer your questions:

                      > When you say it sits on your list, do you mean that someone expects
                      > you to get it done?

                      Well, the other firm will meet with the client, and I'll be given a
                      list of requirements / bug fixes / additions to complete. I'll
                      complete them, then they meet again with the client at another date
                      and come back with more. Sometimes it may be a month before they come
                      back, and even a two month period while their contact was on maternity
                      leave. Basically this is the cycle. I complete tasks on the list, they
                      submit the completed tasks, and then they come back with more. I've
                      complained I'd rather not do anything until they get full
                      requirements, but it seems this request falls on deaf ears.



                      > 1. Not starting on anything until my questions are answered, and
                      > producing some kind of continuing, updated every day, chart,
                      > indicating to all and sundry that all their important stuff is not
                      > being progressed because they haven't answered my questions.
                      >
                      > 2. Whenever something has to be done over, use some kind of chart,
                      > updated every day, indicating rework because of changing
                      > requirement.
                      >
                      > I'd want everyone to be always aware of the wastage, to feel the
                      > burn, but not to feel that I was trying to punish them, make them
                      > look stupid, or attack them.

                      Indeed. I believe that looking back this would have been perhaps the
                      best course of action to take, an d will probably do this the next
                      time they come back with another list (as I have completed the
                      current).


                      > See above for the cost of changes. Consider making the cost of each
                      > thing you implement explicit. Cost of adding history, $150. Cost of
                      > removing history, $15. (And the ratio should probably be about like
                      > that: if it's more, I'd be wondering why.)
                      >
                      > And, as I alluded to in an earlier posting, if they'll pay, why do
                      > we care? It's another 15 bucks ...
                      I guess one possible problem is they are tight on costs. I am also
                      asked by management to mark off bug fixes as non-billable (as these
                      are my fault and I should have avoided them... ugh). Keep in mind I
                      didn't know anything about test driven development at the time.


                      > Why refuse? They want it. What do you care? So they're wrong, if
                      > they are. It's their money.
                      Well, basically I take into account user analysis studies that say
                      taking away the back button limits accessibility, and take great care
                      not to go down the dirty road of taking things away from the user. Of
                      course, if they persist, I will probably let in and do it.


                      > > - Small team, with people added near the end of the project. On the
                      > > whole project, I was the sole programmer, and was expected to complete
                      > > a job application processing system that produced applications in PDF
                      > > format through an administration section. What sucked, however, was
                      > > that the other firm decided to hire someone that would redo the whole
                      > > thing in a day (or so they thought at the time). The person knew very
                      > > little of the language used, and rewrote some key parts that removed
                      > > the encapsulation the domain and data access layer by embedding domain
                      > > and data access code into the view.
                      >
                      > Tell me more about why it bothers you that these things happened,
                      > please ...

                      I guess the reason this bothered me was that out of all the things
                      that were wrong or had issues in the system, the component he worked
                      on was the one thing that worked flawlessly. The reason for him
                      working on it was that it needed a simple search operation, which just
                      needed a simple query plugged into it. I guess what bothered me was
                      the code was of poor quality and completely went around the APIs that
                      allowed for good database abstraction that allowed me to change the
                      underlying database with little or no problems in the domain.

                      That, and I repeatedly needed to help him over instant messenger
                      because he couldn't get stuff working r ight, or he got alot of
                      warnings from his code. I think what bothered me the most, however
                      (despite perhaps a bruised ego) was the other firms implication that I
                      was "dumb" and that this fresh programmer with no experience could do
                      what I did 100x better and complete the project in a day. I think it
                      was just that mentality that was given initially, before they came
                      back and asked me to complete it, that really turned me off.


                      > I'm not sure what you mean here by "formal process", so tell me
                      > more. But maybe you could just add one element to the process, to
                      > make it a little better, every now and again, rather than ironing
                      > out a whole process.

                      Well, I am increasingly finding that adding things in as much as
                      possible are starting to help better. I recently wrote unit tests for
                      the entire code base and have found it better/easier to control
                      problems when refactoring. Subversion has been great for revision
                      tracking, etc. At the time I knew of none of these, and simply took
                      the description an started coding away without any form of planning.

                      The way I see it, I beleive it would be best to try to sit down and
                      tailor a process to follow when developing software, i.e. get
                      requirements, write up some use cases and scenarios with the client
                      (so they can point out their thoughts and suggestions on the spot),
                      draw up some initial design, write unit tests for the hypothetical
                      design, etc. Of course, maybe that is all that needs to be done, to
                      jump right in and use this kind of format.


                      > 1. Why is management even aware of the architecture?
                      > 2. Is the architecture really better in OO rather than a mish mash
                      > of html and scriptlets?
                      The other firm (which has a self-proclaimed "web specialist" who only
                      knows the very basics of the language and the code he has written is
                      of the copy and paste variety) apparently desires to be able to modify
                      the code himself, and complained to the management that I made it too
                      complex that "no one can understand it". I feel the comment blocks
                      were adequate, but I did not know that a requirement (at the time) was
                      that the code needed to be modifiable by a third party.

                      > What if you learned to complete the most important 50 hours' worth
                      > in 50 hours?
                      >
                      > What if you even learned to predict ahead of time what you would
                      > have completed in 50 hours?
                      >
                      > That's only a week or two of work ... couldn't you get pretty good
                      > at predicting? Then you'd need to get good at completing what was
                      > predicted ... what would stand in the way of that?

                      I've gotten better at this now. But at the time, well, what can I say?
                      I was only one month out of college and had never even worked on a
                      project larger than a small CGI script (which usually takes an hour or
                      two). To me, I completely felt it was within my skills to complete the
                      system in 50 hours. If I was in the same shoes again, I probably
                      would have quoted 500 hours. ;)


                      > > no upfront design or planning (basically just identified what was
                      > > needed and coded it),
                      >
                      > What went wrong due to this? Why is it a problem? When were the
                      > problems first identified? How much did they (or would they) cost to
                      > fix? Why was it that much? Have you read /Refactoring/? Are you
                      > doing anything like /Test Driven Development/?

                      As I stated earlier, I learned of refactoring, test driven
                      development, and all the goodies only recently. I have Refactoring and
                      PoEAA by Martin Fowler, XP explained by Beck, as well as many other
                      books (almost the complete set from the Addison Wesley Object
                      Technology Series). I guess the main problem is I wrote a rather large
                      software system with no formal control or unit tests of any kind. With
                      15,000 lines of code written under a month with no overall plan or
                      guide, things are rather a bit... messy.

                      > Your compensation isn't enough, unless you are in a federal prison.
                      > Or perhaps India or China or one of those places. Even then,
                      > actually.

                      Indeed. I feel this has been a major drag on my productivity. In the
                      beginning I was rather hard working, and put in alot of hours overtime
                      off the clock to make sure my projects were done the best to my
                      ability and was pretty focused. Unfortunately, I've recently became a
                      bit demotivated, especially when learning that one of the computer
                      repair technicians actually make $2 more than I. I often consider
                      going out on my own as proramming projects are done 100% by myself,
                      but lack the experience to really go out on a limb myself. How does
                      one keep demotivation from hampering work ability? I feel like it's a
                      catch-22... I'm demotivated because of my pay, yet this can also
                      become a cause and affect of not getting a raise. Bleh, just
                      stressful. ;)

                      Thanks for the comments Ron, very helpful. This project has been
                      stressful, and I have relieved some of that stress by refactoring the
                      code and making it more cleaner, but it bothers me that if I knew then
                      what I know now, I could have done a better job faster. I guess that's
                      the price you pay though. Rather than having a mentor show you how to
                      do things right, you instead learn to do things right by doing them
                      wrong and having a project blow up in your face. :)

                      Thanks,
                      JC
                    • David Moskowitz
                      Hi Esther, There is also the organization that says they want to do Agile (including XP), but don t have the internal culture to support it. I ve seen this
                      Message 10 of 30 , May 2, 2005
                        Hi Esther,

                        There is also the organization that says they want to do Agile
                        (including XP), but don't have the internal culture to support it.
                        I've seen this more than once. For a consultant, it can be very
                        difficult to identify these situation during an interview or RFP
                        process.

                        What makes an agile project fail could be different from makes a
                        classic project fail. Constant re-work kills a classic project by
                        contributing to cost overruns, etc. That type of waste can (should)
                        be avoided with an agile approach... but if an agile process is new
                        to the organization, they have to be committed to making it succeed.

                        If users aren't available to work with developers...
                        If user disappear in the middle of the project...
                        If staff is constantly re-assigned...
                        If there is the organizational or cultural insistance the requirements
                        and design have to be done before the code starts...
                        If the development teams aren't empowered to make decisions...
                        If the organization won't integrate testing into the development
                        process (or insists that it's done after the code)...
                        If it's impossible to get collabloration and cooperation between all
                        stakeholders...

                        ...the project is headed for disaster.

                        David




                        On 4/30/05, estherschindler <esther@...> wrote:
                        > I'm working on my next article for Software Test & Performance
                        > magazine (stpmag.com). Ordinarily, my "best practices" column is about
                        > the ways developers and testers do the right thing: the actions or
                        > attitudes they've found successful. I'm taking a slightly different
                        > approach, this time, by looking as crises in the making.
                        ...snip...
                      • Jeff Grigg
                        ... During the initial phone interview, the project manager said, I know our schedule is ambitious, but I think we can make it. That s the point at which I
                        Message 11 of 30 , May 2, 2005
                          --- "estherschindler" <esther@b...> wrote:
                          > [...] recognizing when a project is in trouble. [...]

                          During the initial phone interview, the project manager said,
                          "I know our schedule is ambitious, but I think we can make it."

                          That's the point at which I knew the project was headed for disaster.

                          So I joined the project, and saved it.

                          -- Jeff Grigg, Consultant
                          in Saint Louis, Missouri
                        • Devin Mullins
                          ... How, may I ask? -Devin
                          Message 12 of 30 , May 2, 2005
                            Jeff Grigg wrote:

                            >During the initial phone interview, the project manager said,
                            >"I know our schedule is ambitious, but I think we can make it."
                            >
                            >That's the point at which I knew the project was headed for disaster.
                            >
                            >So I joined the project, and saved it.
                            >
                            >-- Jeff Grigg, Consultant
                            >in Saint Louis, Missouri
                            >
                            >
                            How, may I ask?

                            -Devin
                          • Phlip
                            ... By, among other things, making the schedule a projection, not a goal? -- Phlip
                            Message 13 of 30 , May 2, 2005
                              Devin Mullins wrote:

                              > >During the initial phone interview, the project manager said,
                              > >"I know our schedule is ambitious, but I think we can make it."
                              > >
                              > >That's the point at which I knew the project was headed for disaster.
                              > >
                              > >So I joined the project, and saved it.

                              > How, may I ask?

                              By, among other things, making the schedule a projection, not a goal?

                              --
                              Phlip
                            • Devin Mullins
                              ... Well, I ve got thoughts, too, but I wanna hear what he _actually_ did. Making the schedule a projection, not a goal, requires agreement from the managers
                              Message 14 of 30 , May 3, 2005
                                Phlip wrote:

                                >Devin Mullins wrote:
                                >
                                >
                                >>>So I joined the project, and saved it.
                                >>>
                                >>>
                                >>How, may I ask?
                                >>
                                >>
                                >By, among other things, making the schedule a projection, not a goal?
                                >
                                >
                                Well, I've got thoughts, too, but I wanna hear what he _actually_ did.
                                Making the schedule a projection, not a goal, requires agreement from
                                the managers and customers (and if not, I want to know how), so it might
                                not always be the available option.
                              • Ron Jeffries
                                Hi James, I ll make just a couple of comments this morning, then take a look when I get back tonight and see what else comes to mind ... ... Certainly this
                                Message 15 of 30 , May 3, 2005
                                  Hi James,

                                  I'll make just a couple of comments this morning, then take a look
                                  when I get back tonight and see what else comes to mind ...

                                  On Monday, May 2, 2005, at 8:35:24 AM, James Carr wrote:

                                  >> When you say it sits on your list, do you mean that someone expects
                                  >> you to get it done?

                                  > Well, the other firm will meet with the client, and I'll be given a
                                  > list of requirements / bug fixes / additions to complete. I'll
                                  > complete them, then they meet again with the client at another date
                                  > and come back with more. Sometimes it may be a month before they come
                                  > back, and even a two month period while their contact was on maternity
                                  > leave. Basically this is the cycle. I complete tasks on the list, they
                                  > submit the completed tasks, and then they come back with more. I've
                                  > complained I'd rather not do anything until they get full
                                  > requirements, but it seems this request falls on deaf ears.

                                  Certainly this doesn't sound as communicative as I'd like: seems
                                  like you have to wait a long time for feedback about how you've
                                  done, and even for clarity on what is asked. That must make your job
                                  harder.

                                  I'm wondering, though, about the "full requirements" idea. This
                                  relates a bit to Alistair's recent comments about customers not
                                  knowing enough about what they want, it seems to me.

                                  I would always prefer to know more about what's coming. On the other
                                  hand, a) I can probably guess pretty well what else they'll want; b)
                                  I have learned not to prejudice today's code by building for what
                                  might happen tomorrow; c) I've learned how to do that without having
                                  tomorrow bite me hard in the nether regions; d) I know I'll get
                                  better feedback about what comes next if my customers can see what
                                  has already been done.

                                  In that light, please say more, if you care to, about your thoughts
                                  on "full requirements" and how they'd help you.


                                  >> 1. Not starting on anything until my questions are answered, and
                                  >> producing some kind of continuing, updated every day, chart,
                                  >> indicating to all and sundry that all their important stuff is not
                                  >> being progressed because they haven't answered my questions.
                                  >>
                                  >> 2. Whenever something has to be done over, use some kind of chart,
                                  >> updated every day, indicating rework because of changing
                                  >> requirement.
                                  >>
                                  >> I'd want everyone to be always aware of the wastage, to feel the
                                  >> burn, but not to feel that I was trying to punish them, make them
                                  >> look stupid, or attack them.

                                  > Indeed. I believe that looking back this would have been perhaps the
                                  > best course of action to take, an d will probably do this the next
                                  > time they come back with another list (as I have completed the
                                  > current).

                                  Great. Live and learn. I'll come back to that.

                                  >> See above for the cost of changes. Consider making the cost of each
                                  >> thing you implement explicit. Cost of adding history, $150. Cost of
                                  >> removing history, $15. (And the ratio should probably be about like
                                  >> that: if it's more, I'd be wondering why.)
                                  >>
                                  >> And, as I alluded to in an earlier posting, if they'll pay, why do
                                  >> we care? It's another 15 bucks ...

                                  > I guess one possible problem is they are tight on costs. I am also
                                  > asked by management to mark off bug fixes as non-billable (as these
                                  > are my fault and I should have avoided them... ugh). Keep in mind I
                                  > didn't know anything about test driven development at the time.

                                  I'm not comfortable with that idea given that you are on hourly. I
                                  would be especially uncomfortable if the requirements were unclear.
                                  However, the rules are the rules, and given that you're not a
                                  prisoner of the state, you can choose how to respond.

                                  >> Why refuse? They want it. What do you care? So they're wrong, if
                                  >> they are. It's their money.

                                  > Well, basically I take into account user analysis studies that say
                                  > taking away the back button limits accessibility, and take great care
                                  > not to go down the dirty road of taking things away from the user. Of
                                  > course, if they persist, I will probably let in and do it.

                                  To me, nothing else makes sense. Do what they ask, or don't do the
                                  job at all. If I were one of those people who thinks in binary,
                                  anyway. But there are always gradations. Generally, though, I take
                                  the position that, after all the guidance I can give, the customer
                                  gets what she then asks for.

                                  >> > - Small team, with people added near the end of the project. On the
                                  >> > whole project, I was the sole programmer, and was expected to complete
                                  >> > a job application processing system that produced applications in PDF
                                  >> > format through an administration section. What sucked, however, was
                                  >> > that the other firm decided to hire someone that would redo the whole
                                  >> > thing in a day (or so they thought at the time). The person knew very
                                  >> > little of the language used, and rewrote some key parts that removed
                                  >> > the encapsulation the domain and data access layer by embedding domain
                                  >> > and data access code into the view.
                                  >>
                                  >> Tell me more about why it bothers you that these things happened,
                                  >> please ...

                                  > I guess the reason this bothered me was that out of all the things
                                  > that were wrong or had issues in the system, the component he worked
                                  > on was the one thing that worked flawlessly. The reason for him
                                  > working on it was that it needed a simple search operation, which just
                                  > needed a simple query plugged into it. I guess what bothered me was
                                  > the code was of poor quality and completely went around the APIs that
                                  > allowed for good database abstraction that allowed me to change the
                                  > underlying database with little or no problems in the domain.

                                  Do you mean that it worked flawlessly before he started?

                                  I understand that poor quality code being put into "your" system
                                  would be a concern, and that it would be hard to see how to address
                                  it in this case.

                                  > That, and I repeatedly needed to help him over instant messenger
                                  > because he couldn't get stuff working r ight, or he got alot of
                                  > warnings from his code. I think what bothered me the most, however
                                  > (despite perhaps a bruised ego) was the other firms implication that I
                                  > was "dumb" and that this fresh programmer with no experience could do
                                  > what I did 100x better and complete the project in a day. I think it
                                  > was just that mentality that was given initially, before they came
                                  > back and asked me to complete it, that really turned me off.

                                  Do you mean that they came back and asked you to complete the other
                                  person's work? That would be good news, I'd think, and perhaps an
                                  opportunity to remind them gently that you're the cool one.

                                  >> I'm not sure what you mean here by "formal process", so tell me
                                  >> more. But maybe you could just add one element to the process, to
                                  >> make it a little better, every now and again, rather than ironing
                                  >> out a whole process.

                                  > Well, I am increasingly finding that adding things in as much as
                                  > possible are starting to help better. I recently wrote unit tests for
                                  > the entire code base and have found it better/easier to control
                                  > problems when refactoring. Subversion has been great for revision
                                  > tracking, etc. At the time I knew of none of these, and simply took
                                  > the description an started coding away without any form of planning.

                                  OK ...

                                  > The way I see it, I beleive it would be best to try to sit down and
                                  > tailor a process to follow when developing software, i.e. get
                                  > requirements, write up some use cases and scenarios with the client
                                  > (so they can point out their thoughts and suggestions on the spot),
                                  > draw up some initial design, write unit tests for the hypothetical
                                  > design, etc. Of course, maybe that is all that needs to be done, to
                                  > jump right in and use this kind of format.

                                  That's one way. XP isn't quite like that, in the customer
                                  communication area, because written communication is weaker in many
                                  key areas than conversation. (Written has its place as well, of
                                  course.)

                                  But if one sits down to try to tailor a process in the abstract, one
                                  is unlikely to get it right. Especially if one has never actually
                                  been on a "good" projects. So maybe trying little things is the
                                  better way ...

                                  OK, enough for now, I have a gig to get to. More later. Good luck!

                                  Ron Jeffries
                                  www.XProgramming.com
                                  Bang, bang, Jeffries' silver hammer came down upon their heads ...
                                • Devin Mullins
                                  ... Maybe it depends on location, I dunno, but in my area, in the first job out of college, you re going to be better served by switching jobs (and negotiating
                                  Message 16 of 30 , May 3, 2005
                                    James Carr wrote:

                                    >Indeed. I feel this has been a major drag on my productivity. In the
                                    >beginning I was rather hard working, and put in alot of hours overtime
                                    >off the clock to make sure my projects were done the best to my
                                    >ability and was pretty focused. Unfortunately, I've recently became a
                                    >bit demotivated, especially when learning that one of the computer
                                    >repair technicians actually make $2 more than I. I often consider
                                    >going out on my own as proramming projects are done 100% by myself,
                                    >but lack the experience to really go out on a limb myself. How does
                                    >one keep demotivation from hampering work ability? I feel like it's a
                                    >catch-22... I'm demotivated because of my pay, yet this can also
                                    >become a cause and affect of not getting a raise. Bleh, just
                                    >stressful. ;)
                                    >
                                    >
                                    Maybe it depends on location, I dunno, but in my area, in the first job
                                    out of college, you're going to be better served by switching jobs (and
                                    negotiating for salary) than by waiting for the piddly little raises.
                                    Mind you, I'm in my first job out of college as well, but I learned one
                                    thing real quick: Find people who know a lot about the industry, and
                                    become friends with them.

                                    Go on job interviews. Take your time picking a job. Don't pick one
                                    unless you're really confident that it 1)pays well enough and 2)doesn't
                                    suck. Actually, you'll find that, if people show an interest in you,
                                    just that will raise your morale. :)

                                    Can't comment on the independent contractor thing, that scares me at the
                                    moment.

                                    Devin
                                  • Jeff Grigg
                                    ... In part, by being a truly amazing C++ architect, developer, mentor, and technical lead. (...and modest too!!! ;- :-) Aside from personal productivity
                                    Message 17 of 30 , May 3, 2005
                                      --- Jeff Grigg wrote:
                                      >>>> So I joined the project, and saved it.

                                      >> --- Devin Mullins wrote:
                                      >>> How, may I ask?

                                      In part, by being a truly amazing C++ architect, developer, mentor,
                                      and technical lead. (...and modest too!!! ;-> :-)

                                      Aside from personal productivity and teamwork, what really made
                                      success possible was aggressive iterative development and delivery
                                      of functionality, similar to XP User Stories. And automated
                                      regression testing (but not full XP Test Driven Development).
                                      Intense teamwork and communication in a war room environment was
                                      very helpful too.

                                      We had to prove that we could develop working software quickly. And
                                      that it would actually work, and solve some business problems. And
                                      we needed confidence in our estimates (our Velocity), as we were
                                      working against the year 2000 deadline. Fortunately, we managed to
                                      achieve a much higher velocity than I or anyone else had expected,
                                      without which we would have had no hope of meeting the deadline.


                                      The technical issues were not the only project problems. I give our
                                      project leadership full credit for resolving a later political
                                      crisis between the I.T. department and external vendors that
                                      threatened to derail the whole project.
                                    • twifkak@comcast.net
                                      Thanks for your reply, Jeff. I feel like I m all take and no give on this list. :) replies below.. ... See, I wonder how much this is an effect on these XP
                                      Message 18 of 30 , May 3, 2005
                                        Thanks for your reply, Jeff. I feel like I'm all take and no give on this list. :)

                                        replies below..

                                        > --- Jeff Grigg wrote:
                                        > >>>> So I joined the project, and saved it.
                                        > >>> How, may I ask?
                                        > In part, by being a truly amazing C++ architect, developer, mentor,
                                        > and technical lead. (...and modest too!!! ;-> :-)
                                        See, I wonder how much this is an effect on these XP success stories. I know it's been said before, but I wanna try out the words for myself: The sort of people who are on this list are good programmers. Not necessarily experts at this library or that language, but the kind of people who read and learn and synthesize and continue to strive for self-improvement (and use polysyndetons to make a point), which are some of the very traits necessary to write good code.

                                        To an extent, I think part of that success is that when it is said a developer writes "good code," it means he is more experienced at predicting the future of the code, so the code he writes reflects that through maintainability.

                                        To a greater extent, though, I think the developer succeeds at applying TDD and iterative development and anti-semitic refactoring because he was always good at picking up new things and learning them quickly, and was always the type to excel when given a tight feedback loop.

                                        Then again, I should read one of the myriad of XP books out there and shut the heck up until so.

                                        > Aside from personal productivity and teamwork, what really made
                                        > success possible was aggressive iterative development and delivery
                                        > of functionality, similar to XP User Stories. And automated
                                        > regression testing (but not full XP Test Driven Development).
                                        > Intense teamwork and communication in a war room environment was
                                        > very helpful too.
                                        OK. I have no comments here. Always interesting to see what bag of tricks people bring to a project. :) It helps me build ideas on what my own bag of tricks should be. (As I'm no XP coach, I'm going to have to pick some subset, at first.)

                                        > We had to prove that we could develop working software quickly. And
                                        > that it would actually work, and solve some business problems. And
                                        > we needed confidence in our estimates (our Velocity), as we were
                                        > working against the year 2000 deadline. Fortunately, we managed to
                                        > achieve a much higher velocity than I or anyone else had expected,
                                        > without which we would have had no hope of meeting the deadline.
                                        Cool.
                                        1)You measured velocity via those pseudo-user stories you mentioned, I take it?
                                        2)How did you develop it quickly, but maintain quality? Was automated regression testing enough? Did iterative development prove to help you write quality code? Did you find that the "war room environment" was adequate to communicate the dependencies between different people's code, or were problems discovered after the fact?

                                        > The technical issues were not the only project problems. I give our
                                        > project leadership full credit for resolving a later political
                                        > crisis between the I.T. department and external vendors that
                                        > threatened to derail the whole project.
                                        Way to insert that little bit of token modesty, there. (Just kidding! Don't hurt me.)

                                        Thanks,
                                        Devin


                                        > --- Jeff Grigg wrote:
                                        > >>>> So I joined the project, and saved it.
                                        >
                                        > >> --- Devin Mullins wrote:
                                        > >>> How, may I ask?
                                        >
                                        > In part, by being a truly amazing C++ architect, developer, mentor,
                                        > and technical lead. (...and modest too!!! ;-> :-)
                                        >
                                        > Aside from personal productivity and teamwork, what really made
                                        > success possible was aggressive iterative development and delivery
                                        > of functionality, similar to XP User Stories. And automated
                                        > regression testing (but not full XP Test Driven Development).
                                        > Intense teamwork and communication in a war room environment was
                                        > very helpful too.
                                        >
                                        > We had to prove that we could develop working software quickly. And
                                        > that it would actually work, and solve some business problems. And
                                        > we needed confidence in our estimates (our Velocity), as we were
                                        > working against the year 2000 deadline. Fortunately, we managed to
                                        > achieve a much higher velocity than I or anyone else had expected,
                                        > without which we would have had no hope of meeting the deadline.
                                        >
                                        >
                                        > The technical issues were not the only project problems. I give our
                                        > project leadership full credit for resolving a later political
                                        > crisis between the I.T. department and external vendors that
                                        > threatened to derail the whole project.
                                        >
                                        >
                                        >
                                        >
                                        >
                                        > To Post a message, send it to: extremeprogramming@...
                                        >
                                        > To Unsubscribe, send a blank message to:
                                        > extremeprogramming-unsubscribe@...
                                        >
                                        > ad-free courtesy of objectmentor.com
                                        > Yahoo! Groups Links
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                      • Steven Gordon
                                        anti-semitic refactoring ?? ... From: extremeprogramming@yahoogroups.com on behalf of twifkak@comcast.net Sent: Tue 5/3/2005 7:48 AM To:
                                        Message 19 of 30 , May 3, 2005
                                          "anti-semitic refactoring"??

                                          -----Original Message-----
                                          From: extremeprogramming@yahoogroups.com on behalf of twifkak@...
                                          Sent: Tue 5/3/2005 7:48 AM
                                          To: extremeprogramming@yahoogroups.com
                                          Cc:
                                          Subject: Re: [XP] Re: Recognizing when your project is headed for disaster?



                                          Thanks for your reply, Jeff. I feel like I'm all take and no give on this list. :)

                                          replies below..

                                          > --- Jeff Grigg wrote:
                                          > >>>> So I joined the project, and saved it.
                                          > >>> How, may I ask?
                                          > In part, by being a truly amazing C++ architect, developer, mentor,
                                          > and technical lead. (...and modest too!!! ;-> :-)
                                          See, I wonder how much this is an effect on these XP success stories. I know it's been said before, but I wanna try out the words for myself: The sort of people who are on this list are good programmers. Not necessarily experts at this library or that language, but the kind of people who read and learn and synthesize and continue to strive for self-improvement (and use polysyndetons to make a point), which are some of the very traits necessary to write good code.

                                          To an extent, I think part of that success is that when it is said a developer writes "good code," it means he is more experienced at predicting the future of the code, so the code he writes reflects that through maintainability.

                                          To a greater extent, though, I think the developer succeeds at applying TDD and iterative development and anti-semitic refactoring because he was always good at picking up new things and learning them quickly, and was always the type to excel when given a tight feedback loop.

                                          Then again, I should read one of the myriad of XP books out there and shut the heck up until so.

                                          > Aside from personal productivity and teamwork, what really made
                                          > success possible was aggressive iterative development and delivery
                                          > of functionality, similar to XP User Stories. And automated
                                          > regression testing (but not full XP Test Driven Development).
                                          > Intense teamwork and communication in a war room environment was
                                          > very helpful too.
                                          OK. I have no comments here. Always interesting to see what bag of tricks people bring to a project. :) It helps me build ideas on what my own bag of tricks should be. (As I'm no XP coach, I'm going to have to pick some subset, at first.)

                                          > We had to prove that we could develop working software quickly. And
                                          > that it would actually work, and solve some business problems. And
                                          > we needed confidence in our estimates (our Velocity), as we were
                                          > working against the year 2000 deadline. Fortunately, we managed to
                                          > achieve a much higher velocity than I or anyone else had expected,
                                          > without which we would have had no hope of meeting the deadline.
                                          Cool.
                                          1)You measured velocity via those pseudo-user stories you mentioned, I take it?
                                          2)How did you develop it quickly, but maintain quality? Was automated regression testing enough? Did iterative development prove to help you write quality code? Did you find that the "war room environment" was adequate to communicate the dependencies between different people's code, or were problems discovered after the fact?

                                          > The technical issues were not the only project problems. I give our
                                          > project leadership full credit for resolving a later political
                                          > crisis between the I.T. department and external vendors that
                                          > threatened to derail the whole project.
                                          Way to insert that little bit of token modesty, there. (Just kidding! Don't hurt me.)

                                          Thanks,
                                          Devin


                                          > --- Jeff Grigg wrote:
                                          > >>>> So I joined the project, and saved it.
                                          >
                                          > >> --- Devin Mullins wrote:
                                          > >>> How, may I ask?
                                          >
                                          > In part, by being a truly amazing C++ architect, developer, mentor,
                                          > and technical lead. (...and modest too!!! ;-> :-)
                                          >
                                          > Aside from personal productivity and teamwork, what really made
                                          > success possible was aggressive iterative development and delivery
                                          > of functionality, similar to XP User Stories. And automated
                                          > regression testing (but not full XP Test Driven Development).
                                          > Intense teamwork and communication in a war room environment was
                                          > very helpful too.
                                          >
                                          > We had to prove that we could develop working software quickly. And
                                          > that it would actually work, and solve some business problems. And
                                          > we needed confidence in our estimates (our Velocity), as we were
                                          > working against the year 2000 deadline. Fortunately, we managed to
                                          > achieve a much higher velocity than I or anyone else had expected,
                                          > without which we would have had no hope of meeting the deadline.
                                          >
                                          >
                                          > The technical issues were not the only project problems. I give our
                                          > project leadership full credit for resolving a later political
                                          > crisis between the I.T. department and external vendors that
                                          > threatened to derail the whole project.








                                          [Non-text portions of this message have been removed]
                                        • Anthony Moralez
                                          Refactoring Nazi
                                          Message 20 of 30 , May 3, 2005
                                            "Refactoring Nazi"

                                            On 5/3/05, Steven Gordon <sagordon@...> wrote:
                                            > "anti-semitic refactoring"??
                                            >
                                            > -----Original Message-----
                                            > From: extremeprogramming@yahoogroups.com on behalf of twifkak@...
                                            > Sent: Tue 5/3/2005 7:48 AM
                                            > To: extremeprogramming@yahoogroups.com
                                            > Cc:
                                            > Subject: Re: [XP] Re: Recognizing when your project is headed for disaster?
                                            >
                                            > Thanks for your reply, Jeff. I feel like I'm all take and no give on this list. :)
                                            >
                                            > replies below..
                                            >
                                            > > --- Jeff Grigg wrote:
                                            > > >>>> So I joined the project, and saved it.
                                            > > >>> How, may I ask?
                                            > > In part, by being a truly amazing C++ architect, developer, mentor,
                                            > > and technical lead. (...and modest too!!! ;-> :-)
                                            > See, I wonder how much this is an effect on these XP success stories. I know it's been said before, but I wanna try out the words for myself: The sort of people who are on this list are good programmers. Not necessarily experts at this library or that language, but the kind of people who read and learn and synthesize and continue to strive for self-improvement (and use polysyndetons to make a point), which are some of the very traits necessary to write good code.
                                            >
                                            > To an extent, I think part of that success is that when it is said a developer writes "good code," it means he is more experienced at predicting the future of the code, so the code he writes reflects that through maintainability.
                                            >
                                            > To a greater extent, though, I think the developer succeeds at applying TDD and iterative development and anti-semitic refactoring because he was always good at picking up new things and learning them quickly, and was always the type to excel when given a tight feedback loop.
                                            >
                                            > Then again, I should read one of the myriad of XP books out there and shut the heck up until so.
                                            >
                                            > > Aside from personal productivity and teamwork, what really made
                                            > > success possible was aggressive iterative development and delivery
                                            > > of functionality, similar to XP User Stories. And automated
                                            > > regression testing (but not full XP Test Driven Development).
                                            > > Intense teamwork and communication in a war room environment was
                                            > > very helpful too.
                                            > OK. I have no comments here. Always interesting to see what bag of tricks people bring to a project. :) It helps me build ideas on what my own bag of tricks should be. (As I'm no XP coach, I'm going to have to pick some subset, at first.)
                                            >
                                            > > We had to prove that we could develop working software quickly. And
                                            > > that it would actually work, and solve some business problems. And
                                            > > we needed confidence in our estimates (our Velocity), as we were
                                            > > working against the year 2000 deadline. Fortunately, we managed to
                                            > > achieve a much higher velocity than I or anyone else had expected,
                                            > > without which we would have had no hope of meeting the deadline.
                                            > Cool.
                                            > 1)You measured velocity via those pseudo-user stories you mentioned, I take it?
                                            > 2)How did you develop it quickly, but maintain quality? Was automated regression testing enough? Did iterative development prove to help you write quality code? Did you find that the "war room environment" was adequate to communicate the dependencies between different people's code, or were problems discovered after the fact?
                                            >
                                            > > The technical issues were not the only project problems. I give our
                                            > > project leadership full credit for resolving a later political
                                            > > crisis between the I.T. department and external vendors that
                                            > > threatened to derail the whole project.
                                            > Way to insert that little bit of token modesty, there. (Just kidding! Don't hurt me.)
                                            >
                                            > Thanks,
                                            > Devin
                                            >
                                            > > --- Jeff Grigg wrote:
                                            > > >>>> So I joined the project, and saved it.
                                            > >
                                            > > >> --- Devin Mullins wrote:
                                            > > >>> How, may I ask?
                                            > >
                                            > > In part, by being a truly amazing C++ architect, developer, mentor,
                                            > > and technical lead. (...and modest too!!! ;-> :-)
                                            > >
                                            > > Aside from personal productivity and teamwork, what really made
                                            > > success possible was aggressive iterative development and delivery
                                            > > of functionality, similar to XP User Stories. And automated
                                            > > regression testing (but not full XP Test Driven Development).
                                            > > Intense teamwork and communication in a war room environment was
                                            > > very helpful too.
                                            > >
                                            > > We had to prove that we could develop working software quickly. And
                                            > > that it would actually work, and solve some business problems. And
                                            > > we needed confidence in our estimates (our Velocity), as we were
                                            > > working against the year 2000 deadline. Fortunately, we managed to
                                            > > achieve a much higher velocity than I or anyone else had expected,
                                            > > without which we would have had no hope of meeting the deadline.
                                            > >
                                            > >
                                            > > The technical issues were not the only project problems. I give our
                                            > > project leadership full credit for resolving a later political
                                            > > crisis between the I.T. department and external vendors that
                                            > > threatened to derail the whole project.
                                            >
                                            > [Non-text portions of this message have been removed]
                                            >
                                            >
                                            > To Post a message, send it to: extremeprogramming@...
                                            >
                                            > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                            >
                                            > ad-free courtesy of objectmentor.com
                                            > Yahoo! Groups Links
                                            >
                                            >
                                            >
                                            >
                                            >
                                          • SirGilligan
                                            I thought we needed some thing songs to sing while we code ourselves off of the edge of the flat world... See the bottom of my web page and enjoy (If you are
                                            Message 21 of 30 , May 3, 2005
                                              I thought we needed some thing songs to sing while we code ourselves
                                              off of the edge of the flat world...

                                              See the bottom of my web page and enjoy (If you are old enough to
                                              recognize the tune)!

                                              http://home.att.net/~geoffrey.slinker/agile.html
                                            • Jeff Grigg
                                              ... Hmmm... Is it... anti-semitic = anti-Jewish sentiment anti-syntactic = without form anti-semantic = without meaning I ll guess (changing the form of the
                                              Message 22 of 30 , May 3, 2005
                                                > > -----Original Message-----
                                                > > From: twifkak@c...
                                                > > Sent: Tue 5/3/2005 7:48 AM
                                                > > To a greater extent, though, I think the developer
                                                > > succeeds at applying TDD and iterative development
                                                > > and anti-semitic refactoring [...]

                                                > --- Steven Gordon <sagordon@a...> wrote:
                                                >> "anti-semitic refactoring"??

                                                --- Anthony Moralez <anthony.moralez@g...> wrote:
                                                > "Refactoring Nazi"

                                                Hmmm...
                                                Is it...
                                                anti-semitic = anti-Jewish sentiment
                                                anti-syntactic = without form
                                                anti-semantic = without meaning

                                                I'll guess (changing the form of the code) "without changing its
                                                meaning" (function)
                                              • twifkak@comcast.net
                                                Yikes. Well, 1)Anthony was correct. Wasn t meant to offend. Just a bad pun, is all. 2)I m a little saddened that my warped sense of humor distracted everybody
                                                Message 23 of 30 , May 3, 2005
                                                  Yikes. Well,
                                                  1)Anthony was correct. Wasn't meant to offend. Just a bad pun, is all.
                                                  2)I'm a little saddened that my warped sense of humor distracted everybody from my insightful comments and questions, whatever they were.

                                                  Devin


                                                  > > --- Steven Gordon <sagordon@a...> wrote:
                                                  > >> "anti-semitic refactoring"??
                                                  > --- Anthony Moralez <anthony.moralez@g...> wrote:
                                                  > > "Refactoring Nazi"
                                                  > Hmmm...
                                                  > Is it...
                                                  > anti-semitic = anti-Jewish sentiment
                                                  > anti-syntactic = without form
                                                  > anti-semantic = without meaning
                                                  >
                                                  > I'll guess (changing the form of the code) "without changing its
                                                  > meaning" (function)
                                                • Ron Jeffries
                                                  ... I m not a big fan of comment blocks. The best way for anyone to maintain your code is to be involved in helping you implement it. I understand that that s
                                                  Message 24 of 30 , May 3, 2005
                                                    On Monday, May 2, 2005, at 8:35:24 AM, James Carr wrote:

                                                    >> 1. Why is management even aware of the architecture?
                                                    >> 2. Is the architecture really better in OO rather than a mish mash
                                                    >> of html and scriptlets?
                                                    > The other firm (which has a self-proclaimed "web specialist" who only
                                                    > knows the very basics of the language and the code he has written is
                                                    > of the copy and paste variety) apparently desires to be able to modify
                                                    > the code himself, and complained to the management that I made it too
                                                    > complex that "no one can understand it". I feel the comment blocks
                                                    > were adequate, but I did not know that a requirement (at the time) was
                                                    > that the code needed to be modifiable by a third party.

                                                    I'm not a big fan of comment blocks. The best way for anyone to
                                                    maintain your code is to be involved in helping you implement it. I
                                                    understand that that's not likely to happen.

                                                    >> What if you learned to complete the most important 50 hours' worth
                                                    >> in 50 hours?
                                                    >>
                                                    >> What if you even learned to predict ahead of time what you would
                                                    >> have completed in 50 hours?
                                                    >>
                                                    >> That's only a week or two of work ... couldn't you get pretty good
                                                    >> at predicting? Then you'd need to get good at completing what was
                                                    >> predicted ... what would stand in the way of that?

                                                    > I've gotten better at this now. But at the time, well, what can I say?
                                                    > I was only one month out of college and had never even worked on a
                                                    > project larger than a small CGI script (which usually takes an hour or
                                                    > two). To me, I completely felt it was within my skills to complete the
                                                    > system in 50 hours. If I was in the same shoes again, I probably
                                                    > would have quoted 500 hours. ;)

                                                    Live and learn ...

                                                    >> > no upfront design or planning (basically just identified what was
                                                    >> > needed and coded it),
                                                    >>
                                                    >> What went wrong due to this? Why is it a problem? When were the
                                                    >> problems first identified? How much did they (or would they) cost to
                                                    >> fix? Why was it that much? Have you read /Refactoring/? Are you
                                                    >> doing anything like /Test Driven Development/?

                                                    > As I stated earlier, I learned of refactoring, test driven
                                                    > development, and all the goodies only recently. I have Refactoring and
                                                    > PoEAA by Martin Fowler, XP explained by Beck, as well as many other
                                                    > books (almost the complete set from the Addison Wesley Object
                                                    > Technology Series). I guess the main problem is I wrote a rather large
                                                    > software system with no formal control or unit tests of any kind. With
                                                    > 15,000 lines of code written under a month with no overall plan or
                                                    > guide, things are rather a bit... messy.

                                                    Live and learn ...

                                                    >> Your compensation isn't enough, unless you are in a federal prison.
                                                    >> Or perhaps India or China or one of those places. Even then,
                                                    >> actually.

                                                    > Indeed. I feel this has been a major drag on my productivity. In the
                                                    > beginning I was rather hard working, and put in alot of hours overtime
                                                    > off the clock to make sure my projects were done the best to my
                                                    > ability and was pretty focused. Unfortunately, I've recently became a
                                                    > bit demotivated, especially when learning that one of the computer
                                                    > repair technicians actually make $2 more than I. I often consider
                                                    > going out on my own as proramming projects are done 100% by myself,
                                                    > but lack the experience to really go out on a limb myself. How does
                                                    > one keep demotivation from hampering work ability? I feel like it's a
                                                    > catch-22... I'm demotivated because of my pay, yet this can also
                                                    > become a cause and affect of not getting a raise. Bleh, just
                                                    > stressful. ;)

                                                    Yes ... I mean this in the kindest possible way: consider quitting.
                                                    They might even hire you back at a higher rate. Also consider not
                                                    quitting until you have a better job lined up, and work to do that.

                                                    > Thanks for the comments Ron, very helpful. This project has been
                                                    > stressful, and I have relieved some of that stress by refactoring the
                                                    > code and making it more cleaner, but it bothers me that if I knew then
                                                    > what I know now, I could have done a better job faster. I guess that's
                                                    > the price you pay though. Rather than having a mentor show you how to
                                                    > do things right, you instead learn to do things right by doing them
                                                    > wrong and having a project blow up in your face. :)

                                                    Live and learn. I really mean that. As Richard Gabriel puts it: "The
                                                    work teaches us."

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    Curiosity is more powerful than skepticism.
                                                  • John D. Mitchell
                                                    ... [...] ... When caring / passion are traded away. IME, it s in the little things like people not actually, really listening to each other. Excuses like
                                                    Message 25 of 30 , May 3, 2005
                                                      >>>>> "estherschindler" == estherschindler <esther@...> writes:
                                                      [...]

                                                      > These indications don't have to be directly related to the technology or
                                                      > the team. It's a bit funny to use an example from an advertisement, but
                                                      > this one provides a good demonstration. In a Bank of America ad about
                                                      > their investments in crappy neighborhoods (they didn't phrase it that
                                                      > way), the speaker said they knew they'd succeeded, "when the flowerboxes
                                                      > begin showing up on front porches." Teams have the same sort of indirect
                                                      > indications, too, for good or ill. Which ones have you recognized -- or
                                                      > failed to recognize? Are there distinctions between the signs that
                                                      > mean,"This shows we're in trouble, but it can be fixed" and "We're about
                                                      > to explode. Quit NOW!"?

                                                      When caring / passion are traded away. IME, it's in the little things like
                                                      people not actually, really listening to each other. Excuses like being
                                                      busy are clear signs if they persist but it's time to freak out when people
                                                      substitute the various political manipulation tricks such as
                                                      enthusiastically agreeing with multiple, contradictory needs.

                                                      Another case is when various addictive behaviors crop up. For example, "I
                                                      can quit [doing something bad] anytime I want." (but never does) or
                                                      "everything will be better after [pipe dream]." (but never does) or "well,
                                                      I've already broke my diet with this one little cookie so screw it, I might
                                                      as well eat the whole damn box." or....

                                                      Have fun,
                                                      John
                                                    • Brad Appleton
                                                      One of the biggest signs I see, is when the players being held accountable arent playing to win from a team/project-wide perspective, but are either
                                                      Message 26 of 30 , May 4, 2005
                                                        One of the biggest signs I see, is when the "players" being held
                                                        accountable arent "playing to win" from a team/project-wide perspective,
                                                        but are either playing not-to-fail, or else playing to win only from
                                                        their own personal advancement and not "the greater good".

                                                        In that case, when its clear Im in the middle of a losing game, I tend
                                                        to resort to one of the following strategies:
                                                        1) change the rules (perhaps by CHANGING the players, or the referee :)
                                                        2) change the PLAYERS
                                                        3) change (move) the end-goals (goal posts)
                                                        4) change the game
                                                        5) declare "game over" (sometimes turns into #4 above)
                                                        (note, this could mean declaring *victory*, not necessarily defeat)

                                                        --
                                                        Brad Appleton <brad@...> www.bradapp.net
                                                        Software CM Patterns (www.scmpatterns.com)
                                                        Effective Teamwork, Practical Integration
                                                        "And miles to go before I sleep" --Robert Frost
                                                      • Edmund Schweppe
                                                        ... Nah. It s anti-Symantic = without virus protection.
                                                        Message 27 of 30 , May 5, 2005
                                                          Jeff Grigg wrote:
                                                          > anti-semitic = anti-Jewish sentiment
                                                          > anti-syntactic = without form
                                                          > anti-semantic = without meaning

                                                          Nah. It's anti-Symantic = without virus protection.
                                                        • Steven J. Owens
                                                          ... One of my favorite sayings about stress (though I don t hold it as gospel truth) is stress is a decision you haven t made yet. This is one of those
                                                          Message 28 of 30 , Aug 26, 2005
                                                            On Mon, May 02, 2005 at 04:19:10AM -0500, Ron Jeffries wrote:
                                                            > Finally, FINALLY!, in a meeting about what to do, she told her
                                                            > boss that what to do was to terminate her.
                                                            >
                                                            > The next two weeks, she went into the office, did what she could,
                                                            > and came home without stress.
                                                            >
                                                            > I'm glad she quit. But my guess is that all the weeks before that,
                                                            > she could have gone into the office, done what she could, and come
                                                            > home without stress. My guess is that we can always do that, that
                                                            > stress is something we accept more than something that is provided
                                                            > to us.

                                                            One of my favorite sayings about stress (though I don't hold it
                                                            as gospel truth) is "stress is a decision you haven't made yet."

                                                            This is one of those things you have to apply with judgement, of
                                                            course. Obviously a lot of the time stress comes from putting off a
                                                            decision. Sometimes it's a deliberate choice to ignore the stress
                                                            with the idea that the key stress factor will go away. Sometimes it
                                                            does go away, sometimes it doesn't. Sometimes the decision you're
                                                            putting off is simply the decision to accept the situation and live
                                                            with it. Sometimes, as in your wife's case, it's the decision not to
                                                            accept the situation.

                                                            Not quite related, in googling to try to find the origin of that
                                                            saying, I found this somewwhat interesting page:

                                                            http://www.unl.edu/stress/mgmt/decision.html

                                                            > Might be a knack to learn ...

                                                            Saw a good variation on a classic quote, on the wall above the
                                                            nurses' station last night, as I visited a friend who had a stroke
                                                            over the weekend:

                                                            God grant me the serenity to accept the people I cannot change,
                                                            the courage to change the one I can,
                                                            and the wisdom to know it's me.


                                                            --
                                                            Steven J. Owens
                                                            puff@...

                                                            "I'm going to make broad, sweeping generalizations and strong,
                                                            declarative statements, because otherwise I'll be here all night and
                                                            this document will be four times longer and much less fun to read.
                                                            Take it all with a grain of salt." - http://darksleep.com/notablog
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.