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

How can you tell when your project is headed for disaster?

Expand Messages
  • estherschindler
    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
    Message 1 of 30 , Apr 30 7:24 PM
    • 0 Attachment
      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
    • Phlip
      ... XP in theory gives one jargon to explain the situation accurately. ( Project Manager means many things to many projects, but Onsite Customer means only
      Message 2 of 30 , Apr 30 10:49 PM
      • 0 Attachment
        estherschindler wrote:

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

        XP in theory gives one jargon to explain the situation accurately.
        ("Project Manager" means many things to many projects, but "Onsite
        Customer" means only one to all projects.)

        XP in practice should give the warning signs. XP projects should fail
        early, loudly, cheaply, and reliably. They should not die late, quiet,
        expensively, and unpredictably.

        That requires obeying the warning sign instead of collectively ignoring it...

        > With 20-20 hindsight, you realize that the signs were there all along;

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

        One company went into "10-year startup" mode because the boss refused
        to ask for investment for growth. This means if I write a beautiful
        architecture that could cover many different product lines, and I vet
        it successfully against 3 real product lines, the boss still doesn't
        have the capacity to install it in all the other potential product
        lines and clean up. Bail.

        Several companies were indulging in pure .COM speculation. The
        investors only need one startup in their portfolio to go big, and we
        weren't it.

        One company wrote all the specifications up front, then thought of a
        design to cover all of them. Implementing all this design at the same
        time required inhuman synchronization, foresight, and tedious
        communications of what classes we would be writing if we weren't stuck
        in these meetings. Unfortunately I then discovered that TDD could very
        easily implement those classes, but not in a form to satisfy the
        meeting holders. Bail. Oh, and the "chief architect" of that project
        is now a fierce XP convert.

        One company appeased their CEO/investor by buying Microsoft Certified
        Solution Developer titles. This was supposed to reduce risk. The certs
        came with saturation-bombing marketing for Visual Basic, and the CEO,
        a non-programmer, bought into it because "Basic makes programming
        easy". The project required >15 complete modules, each the size of an
        average VB program. Because VB pushes COM, building the project
        required cooking all its Belgium COM objects over and over again. This
        cruft slowed everything down. All of us knew the clickety click click
        dance to slowly clean our registries, slowly regenerate new GUIDs (as
        if an integration were a versioned release), and slowly build new COM
        objects. No automated build scripts. Without this drag, the
        code-and-fix would otherwise have been adequate. With the drag, we
        went months late, and did poorly in the first few demos, making the
        CEO look bad. He pulled the plug.

        Another company the investors wanted to set up for a pump-and-dump.
        They refused to allow us to get a customer. And they let us do XP,
        figuring that some goofy-named methodology would help them blame the
        programmers. (/Thanks/, Kent!) Despite relentless sabotage, we
        finished working products, without a customer, and came so close to
        selling them that the investors had to claim poverty and shut us down.
        But XP prevented them from blaming the programmers, so the executives
        remain deadlocked and in court to this day.

        At the next company, they used pure code-and-fix, and had the lowest
        quality codebase, with the highest line count, I ever saw. They wanted
        to learn testing, and I pitched "write lots of tests" in the
        interview. Then I get onboard, and slowly learn that they don't want
        to integrate testing into their build cycle. They only want the kind
        of magic fairly land tests that prevent bugs even when you don't run
        them. That project will never die, because its company is the market
        leader, due essentially to a series of mistakes by the competing
        companies. So I realized the end was near - for me at least - when my
        boss stopped giving me daily marching orders, but started asking how
        to "decouple" all these tests from the code, meaning take them out.

        > As always: my editors hate it if I write, "Beezelbub, a guy I met in
        > an Internet discussion group, said...

        Uh, in my case I'm already cited thus, so it's grandparented in... Sigh.

        --
        Phlip
      • 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 3 of 30 , May 1, 2005
        • 0 Attachment
          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 4 of 30 , May 1, 2005
          • 0 Attachment
            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 5 of 30 , May 1, 2005
            • 0 Attachment
              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 6 of 30 , May 1, 2005
              • 0 Attachment
                > 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 7 of 30 , May 1, 2005
                • 0 Attachment
                  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 8 of 30 , May 1, 2005
                  • 0 Attachment
                    >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 9 of 30 , May 2, 2005
                    • 0 Attachment
                      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 10 of 30 , May 2, 2005
                      • 0 Attachment
                        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 11 of 30 , May 2, 2005
                        • 0 Attachment
                          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 12 of 30 , May 2, 2005
                          • 0 Attachment
                            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 13 of 30 , May 2, 2005
                            • 0 Attachment
                              --- "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 14 of 30 , May 2, 2005
                              • 0 Attachment
                                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 15 of 30 , May 2, 2005
                                • 0 Attachment
                                  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 16 of 30 , May 3, 2005
                                  • 0 Attachment
                                    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 17 of 30 , May 3, 2005
                                    • 0 Attachment
                                      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 18 of 30 , May 3, 2005
                                      • 0 Attachment
                                        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 19 of 30 , May 3, 2005
                                        • 0 Attachment
                                          --- 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 20 of 30 , May 3, 2005
                                          • 0 Attachment
                                            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 21 of 30 , May 3, 2005
                                            • 0 Attachment
                                              "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 22 of 30 , May 3, 2005
                                              • 0 Attachment
                                                "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 23 of 30 , May 3, 2005
                                                • 0 Attachment
                                                  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 24 of 30 , May 3, 2005
                                                  • 0 Attachment
                                                    > > -----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 25 of 30 , May 3, 2005
                                                    • 0 Attachment
                                                      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 26 of 30 , May 3, 2005
                                                      • 0 Attachment
                                                        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 27 of 30 , May 3, 2005
                                                        • 0 Attachment
                                                          >>>>> "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 28 of 30 , May 4, 2005
                                                          • 0 Attachment
                                                            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 29 of 30 , May 5, 2005
                                                            • 0 Attachment
                                                              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 30 of 30 , Aug 26, 2005
                                                              • 0 Attachment
                                                                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.