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

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

Expand Messages
  • Phlip
    Apr 30, 2005
    • 0 Attachment
      estherschindler wrote:

      > I'm not sure how much XP has to do with this. Maybe you do. Do you
      > find that the problems crop up earlier with XP projects? Are the
      > danger signs different?

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

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

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

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

      Oh dear. One "reverse resume" coming up. The recurring theme is
      technical success against overwhelming odds (some of which XP could
      have reduced), followed by management fiascos...

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

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

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

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

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

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

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

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

      --
      Phlip
    • Show all 30 messages in this topic