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

Re: [XP] How can you tell when your project is headed for disaster?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 of 30 , Aug 26 11:49 AM
                                                    • 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.