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

Re: [scrumdevelopment] Re: How much refactoring?

Expand Messages
  • Pablo Emanuel
    Ilja, ... If you mean the literal *we*, since we don t have all the data, I guess we should respect the team s judgement. If you mean we, as in what would we
    Message 1 of 104 , Apr 30, 2009
    • 0 Attachment
      Ilja,
      >
      > 2009/4/29 Ilja Preuß <iljapreuss@...>
      >>
      >> Hi Pablo,
      >>
      >> > Ilja,
      >> >
      >> > the risk of they getting the 10M if the delivery were in 2 weeks was 0.
      >>
      >> Yes. Are you suggesting that was the only alternative?
      >
      >
      > No,the team did.

      So, does that mean we should stop looking for alternatives?
       
      If you mean the literal *we*, since we don't have all the data, I guess we should respect the team's judgement. If you mean we, as in what would we do if we were part of the team, I'd say we should think no more than what would bring value. In general, you should plan as much as to keep the marginal return positive. I should plan an additional delta if the expected return in the scenario where we plan this delta is greater than the expected return in the scenario where we don't plan plus the cost of delta. BTW, that's the main point against BUPF. In this case, if we already have a quick and dirty solution that would take 4.5 days to implement, we couldn't waste another day trying to find a better solution, or our expected value drops drastically, since we move from a point where we have a pretty good chance of making it to a situation where if we can find a better solution that would take 4 days or less, we're doomed.
       
       



      >> > So,
      >> > if there was even a slight chance to get the money with the early
      >> > delivery,
      >> > logic says we should always go for it (unless there is a comparable risk
      >> > of
      >> > a loss greater than that).
      >>
      >> No, logic doesn't say that. There is a slight chance that I can win
      >> the lottery if I invest some money. Logic doesn't say that I should.
      >
      > It depends. If the ticket costs USD 1, the prize is USD 1M, and you have one
      > chance in 10,000 to win, logic *shouts* that you should.

      Exactly. It depends. Which sounds way different to me than "logic says
      we should *always* go for it" (emphasis added by me).
       
      OK, so let's do the calculation in the example. Let's assume a team of 7 well-payed developers (let's say GBP 100,000/year). The team's week costs a little under 15,000 pounds. My additional cost of doing the quick and dirty solution is 3 weeks =~ 45,000 pounds. To make it worth, the chance of getting the 10M pounds should be at least 45,000/10M = 0.45%. So, yes, it depends. If the pretty good chance of making the 10M actually were a mere 1%, it would still make sense, but if it were 0.1% instead, it wouldn't.
       
       


      >> > Your and Dave's approach
      >>
      >> I don't remember advocating any approach. As far as I remember, I was
      >> merely asking some questions. Did I miss something?
      >
      > Sorry, I jumped to conclusions. A pretty small jump, I guess, but still a
      > jump, nonetheless.

      Not sure why you think it was a small jump.

      >> > is just more ammo for business on their (IMO,
      >> > somewhat justified) complaint that developers can't get business needs,
      >> > and
      >> > focus instead on technical arguments on what should be a purely business
      >> > value-related issue.
      >>
      >> I'd think that reducing risk *is* a business need. Isn't it?
      >
      > In this case, the team was indeed reducing a risk - a positive risk! In
      > their deffence, they weren't conscious of that, and they changed their mind
      > when they understood what was involved.

      I take that as a "yes".
       
      No! Reducing positive risks is definitely not a business need.
       


      So how is "the technical risk is too high with this approach" *not* a
      business value related issue?
       
      Yes, it would be, if it were right. Everyone agreed that the "too" in your sentence didn't apply to this case. The technical risk was high, but was negligible when compared to the positive business risk.
       
      Regards,
      Pablo Emanuel
    • Pablo Emanuel
      Ilja, ... If you mean the literal *we*, since we don t have all the data, I guess we should respect the team s judgement. If you mean we, as in what would we
      Message 104 of 104 , Apr 30, 2009
      • 0 Attachment
        Ilja,
        >
        > 2009/4/29 Ilja Preuß <iljapreuss@...>
        >>
        >> Hi Pablo,
        >>
        >> > Ilja,
        >> >
        >> > the risk of they getting the 10M if the delivery were in 2 weeks was 0.
        >>
        >> Yes. Are you suggesting that was the only alternative?
        >
        >
        > No,the team did.

        So, does that mean we should stop looking for alternatives?
         
        If you mean the literal *we*, since we don't have all the data, I guess we should respect the team's judgement. If you mean we, as in what would we do if we were part of the team, I'd say we should think no more than what would bring value. In general, you should plan as much as to keep the marginal return positive. I should plan an additional delta if the expected return in the scenario where we plan this delta is greater than the expected return in the scenario where we don't plan plus the cost of delta. BTW, that's the main point against BUPF. In this case, if we already have a quick and dirty solution that would take 4.5 days to implement, we couldn't waste another day trying to find a better solution, or our expected value drops drastically, since we move from a point where we have a pretty good chance of making it to a situation where if we can find a better solution that would take 4 days or less, we're doomed.
         
         



        >> > So,
        >> > if there was even a slight chance to get the money with the early
        >> > delivery,
        >> > logic says we should always go for it (unless there is a comparable risk
        >> > of
        >> > a loss greater than that).
        >>
        >> No, logic doesn't say that. There is a slight chance that I can win
        >> the lottery if I invest some money. Logic doesn't say that I should.
        >
        > It depends. If the ticket costs USD 1, the prize is USD 1M, and you have one
        > chance in 10,000 to win, logic *shouts* that you should.

        Exactly. It depends. Which sounds way different to me than "logic says
        we should *always* go for it" (emphasis added by me).
         
        OK, so let's do the calculation in the example. Let's assume a team of 7 well-payed developers (let's say GBP 100,000/year). The team's week costs a little under 15,000 pounds. My additional cost of doing the quick and dirty solution is 3 weeks =~ 45,000 pounds. To make it worth, the chance of getting the 10M pounds should be at least 45,000/10M = 0.45%. So, yes, it depends. If the pretty good chance of making the 10M actually were a mere 1%, it would still make sense, but if it were 0.1% instead, it wouldn't.
         
         


        >> > Your and Dave's approach
        >>
        >> I don't remember advocating any approach. As far as I remember, I was
        >> merely asking some questions. Did I miss something?
        >
        > Sorry, I jumped to conclusions. A pretty small jump, I guess, but still a
        > jump, nonetheless.

        Not sure why you think it was a small jump.

        >> > is just more ammo for business on their (IMO,
        >> > somewhat justified) complaint that developers can't get business needs,
        >> > and
        >> > focus instead on technical arguments on what should be a purely business
        >> > value-related issue.
        >>
        >> I'd think that reducing risk *is* a business need. Isn't it?
        >
        > In this case, the team was indeed reducing a risk - a positive risk! In
        > their deffence, they weren't conscious of that, and they changed their mind
        > when they understood what was involved.

        I take that as a "yes".
         
        No! Reducing positive risks is definitely not a business need.
         


        So how is "the technical risk is too high with this approach" *not* a
        business value related issue?
         
        Yes, it would be, if it were right. Everyone agreed that the "too" in your sentence didn't apply to this case. The technical risk was high, but was negligible when compared to the positive business risk.
         
        Regards,
        Pablo Emanuel
      Your message has been successfully submitted and would be delivered to recipients shortly.