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

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

Expand Messages
  • Ron Jeffries
    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

      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

      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
      Bang, bang, Jeffries' silver hammer came down upon their heads ...
    • Show all 30 messages in this topic