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

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

Expand Messages
  • Phlip
    ... They are all _technical_ successes. Everyone knows .DOT com bosses are full of crap. Also, some aren t business failures, they are simply insufficiently
    Message 1 of 30 , May 1, 2005
    • 0 Attachment
      Devin Mullins wrote:

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

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

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

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

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

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

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

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

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

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

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

        --
        Phlip
      • John Carter
        ... I assume you have Death March by Ed Yourdon in your hand. If not go get it now. I have been fairly lucky by industry standards, but some of that luck was
        Message 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 of 30 , Aug 26, 2005
                                                        • 0 Attachment
                                                          On Mon, May 02, 2005 at 04:19:10AM -0500, Ron Jeffries wrote:
                                                          > Finally, FINALLY!, in a meeting about what to do, she told her
                                                          > boss that what to do was to terminate her.
                                                          >
                                                          > The next two weeks, she went into the office, did what she could,
                                                          > and came home without stress.
                                                          >
                                                          > I'm glad she quit. But my guess is that all the weeks before that,
                                                          > she could have gone into the office, done what she could, and come
                                                          > home without stress. My guess is that we can always do that, that
                                                          > stress is something we accept more than something that is provided
                                                          > to us.

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

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

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

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

                                                          > Might be a knack to learn ...

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

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


                                                          --
                                                          Steven J. Owens
                                                          puff@...

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