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

Reaction to "Canary in a coal mine" video

Expand Messages
  • Andrew Wagner
    So I just got done watching A canary in a coal mine by Ken Schwaber. I thought this was brilliant, and have a few questions about implementation details. Let
    Message 1 of 7 , Jun 18, 2009
    • 0 Attachment
      So I just got done watching "A canary in a coal mine" by Ken Schwaber. I thought this was brilliant, and have a few questions about implementation details.

      Let me first try to summarize one of the points, as I understand it, so that I can be corrected as needed: developers should push back and refuse to lower code quality, because it may "improve" the immediate release date, but it will damage future ones.

      My first question revolves around quality: how do you define it? He talks as if it's a fixed thing, but in fact there are zillions of ways you can define quality, from static code analysis, to code coverage, to "good OO design", whatever that means. He talks about being able to measure the maintenance cost of lowering quality, but isn't it better to avoid it in the first place? It seems to me like the issue here is that "quality" gets redefined or stretched, more than a conscience decision to "cut quality".

      My second question revolves around estimates. This seems to be another fuzzy thing. I mean, if the developers can just say "no it's going to take 12 hours, not 8", then the natural tendency will be to over-estimate (I know, I'm a developer). So something still needs to keep that pressure in place for the estimates to be accurate, which is not at all easy. Or am I way off base here?

      Thanks for any thoughts!
    • jmilunsky
      Quality is something that you should build in from the getgo. And it s really important that you try to define your quality goals upfront. There s lot s you
      Message 2 of 7 , Jun 18, 2009
      • 0 Attachment
        Quality is something that you should build in from the getgo. And it's really important that you try to define your quality goals upfront. There's lot's you can do in this regard...

        Peer design reviews, pair programming, unit tests, automated testing, functional testing. Also important to define acceptance test criteria up front which is the best way to ensure what you get is what you wanted in the first place.

        The idea regarding estimates is to establish sustainable throughput in your organization. So there's no sense padding estimates. You want to try to figure out what your average team velocity is so that you know what you can put in the pipeline. If you fake the estimates you'll just add more pressure on the team or piss stakeholders off.


        --- In scrumdevelopment@yahoogroups.com, Andrew Wagner <wagner.andrew@...> wrote:
        >
        > So I just got done watching "A canary in a coal mine" by Ken Schwaber. I
        > thought this was brilliant, and have a few questions about implementation
        > details.
        > Let me first try to summarize one of the points, as I understand it, so that
        > I can be corrected as needed: developers should push back and refuse to
        > lower code quality, because it may "improve" the immediate release date, but
        > it will damage future ones.
        >
        > My first question revolves around quality: how do you define it? He talks as
        > if it's a fixed thing, but in fact there are zillions of ways you can define
        > quality, from static code analysis, to code coverage, to "good OO design",
        > whatever that means. He talks about being able to measure the maintenance
        > cost of lowering quality, but isn't it better to avoid it in the first
        > place? It seems to me like the issue here is that "quality" gets redefined
        > or stretched, more than a conscience decision to "cut quality".
        >
        > My second question revolves around estimates. This seems to be another fuzzy
        > thing. I mean, if the developers can just say "no it's going to take 12
        > hours, not 8", then the natural tendency will be to over-estimate (I know,
        > I'm a developer). So something still needs to keep that pressure in place
        > for the estimates to be accurate, which is not at all easy. Or am I way off
        > base here?
        >
        > Thanks for any thoughts!
        >
      • victor oliveira
        Andrew, I agree with you that quality is not an absolute at all as I ve posted about it in my blog last month:
        Message 3 of 7 , Jun 18, 2009
        • 0 Attachment
          Andrew,

             I agree with you that quality is not an absolute at all as I've posted about it in my blog last month: http://csvo.wordpress.com/2009/05/25/quality-is-not-absolute/
             When talking about defining quality my reference will always be the manufacturing goods industry.
             You have to establish a quality level in the DoD of the items. The quality level is defined by a set of tests or questions.
             One of the items could be asking the developers if the code is maintainable with a yes or no answer.
             In a yogurt factory you could pick 1 out of a 2000 pack and check if the product is light red with a yes/no answer (strawberry yogurt).
             Another item could be measured, like code coverage percentage above 90%.
             Once they are defined, you need to consider that they should not be lowered because of immediate satisfaction.
             In this way, you clearly choose a level of quality and try to uphold it.

          Best Regards,
          Victor Hugo de Oliveira

          Scrum & Agile Blog
          http://csvo.wordpress.com

          Concrete Solutions
          new edition: http://www.concretesolutions.com.br/index_eng/


          On Thu, Jun 18, 2009 at 1:55 PM, Andrew Wagner <wagner.andrew@...> wrote:


          So I just got done watching "A canary in a coal mine" by Ken Schwaber. I thought this was brilliant, and have a few questions about implementation details.


          Let me first try to summarize one of the points, as I understand it, so that I can be corrected as needed: developers should push back and refuse to lower code quality, because it may "improve" the immediate release date, but it will damage future ones.

          My first question revolves around quality: how do you define it? He talks as if it's a fixed thing, but in fact there are zillions of ways you can define quality, from static code analysis, to code coverage, to "good OO design", whatever that means. He talks about being able to measure the maintenance cost of lowering quality, but isn't it better to avoid it in the first place? It seems to me like the issue here is that "quality" gets redefined or stretched, more than a conscience decision to "cut quality".

          My second question revolves around estimates. This seems to be another fuzzy thing. I mean, if the developers can just say "no it's going to take 12 hours, not 8", then the natural tendency will be to over-estimate (I know, I'm a developer). So something still needs to keep that pressure in place for the estimates to be accurate, which is not at all easy. Or am I way off base here?

          Thanks for any thoughts!




          --

        • Andrew Wagner
          I like the idea here of choosing a standard of quality, and then sticking with it. The only thing I don t like is the following part: On Thu, Jun 18, 2009 at
          Message 4 of 7 , Jun 18, 2009
          • 0 Attachment
            I like the idea here of choosing a standard of quality, and then sticking with it. The only thing I don't like is the following part:

            On Thu, Jun 18, 2009 at 1:24 PM, victor oliveira <victor.oliveira@...> wrote:
            <snip>
               One of the items could be asking the developers if the code is maintainable with a yes or no answer.




            This doesn't seem realistic to me. Any code can be maintained with enough effort. The question is "how maintainable is it?", which is a very hard question to answer indeed. 

             
          • victor oliveira
            One way to quantify how maintainable it is, is to collect yes/no answers and analyze them together.If you put together a set of questions such as: Was it
            Message 5 of 7 , Jun 18, 2009
            • 0 Attachment

              One way to quantify how maintainable it is, is to collect yes/no answers and analyze them together.
              If you put together a set of questions such as:
              Was it easier or more difficult than the last Sprint to add functionality ?
              Was the code readable ?
              and so on... this can generate a number.

              I'm not an expert in surveys, but I am aware that there are very defined techniques to conduct a survey and from that generate numeric data that can be used as a criteria. Depending on the number of members involved it may be more or less reliable, but at least it is something.
              I don't use something that sophisticated on the 'how maintainable it is', only constant communication with the team to get a sense of what is going on but we have seriously discussed periodic surveys with the teams.

              Best Regards,
              Victor Hugo de Oliveira

              Scrum & Agile Blog
              http://csvo.wordpress.com

              Concrete Solutions
              new edition: http://www.concretesolutions.com.br/index_eng/


              On Thu, Jun 18, 2009 at 2:40 PM, Andrew Wagner <wagner.andrew@...> wrote:


              I like the idea here of choosing a standard of quality, and then sticking with it. The only thing I don't like is the following part:

              On Thu, Jun 18, 2009 at 1:24 PM, victor oliveira <victor.oliveira@...> wrote:
              <snip>

                 One of the items could be asking the developers if the code is maintainable with a yes or no answer.




              This doesn't seem realistic to me. Any code can be maintained with enough effort. The question is "how maintainable is it?", which is a very hard question to answer indeed. 

               




              --

            • Lance Walton
              Hi. I have four responses to your question. The first is that there is now a fair amount of research that shows that people (and I ve found developers do this
              Message 6 of 7 , Jun 18, 2009
              • 0 Attachment
                Hi.

                I have four responses to your question. The first is that there is now a fair amount of research that shows that people (and I've found developers do this in particular) usually underestimate rather than overestimate in terms of time.

                Secondly, I'm not sure if you are a developer or not. Let's suppose you are. Now, let's suppose that *you* are asked to produce an estimate. Are *you* going to pad the estimate so that *you* can mess about or whatever?

                Thirdly, the task is going to take the time it takes regardless of the estimate. If a developer feels pressure to do it in the estimated time (and maybe that estimate was produced with pressure to keep it small), then either they will make mistakes because they are trying to go too fast, or they will be unhappy that they missed the deadline, or they will be unhappy with the result, or ...

                Fourth, it's an *estimate*, not a fact.

                Regards,

                Lance

                --- In scrumdevelopment@yahoogroups.com, Andrew Wagner <wagner.andrew@...> wrote:
                >
                > My second question revolves around estimates. This seems to be another fuzzy
                > thing. I mean, if the developers can just say "no it's going to take 12
                > hours, not 8", then the natural tendency will be to over-estimate (I know,
                > I'm a developer). So something still needs to keep that pressure in place
                > for the estimates to be accurate, which is not at all easy. Or am I way off
                > base here?
                >
                > Thanks for any thoughts!
                >
              • Ron Jeffries
                Hello, Andrew. On Thursday, June 18, 2009, at 12:55:03 PM, you ... Well ... I really don t think estimates have anything to do with it.
                Message 7 of 7 , Jun 19, 2009
                • 0 Attachment
                  Hello, Andrew. On Thursday, June 18, 2009, at 12:55:03 PM, you
                  wrote:

                  > My second question revolves around estimates. This seems to be another fuzzy
                  > thing. I mean, if the developers can just say "no it's going to take 12
                  > hours, not 8", then the natural tendency will be to over-estimate (I know,
                  > I'm a developer). So something still needs to keep that pressure in place
                  > for the estimates to be accurate, which is not at all easy. Or am I way off
                  > base here?

                  Well ... I really don't think estimates have anything to do with it.
                  http://www.xprogramming.com/xpmag/jatMakingTheDate.htm

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  My advice is to do it by the book, get good at the practices, then do as
                  you will. Many people want to skip to step three. How do they know?
                Your message has been successfully submitted and would be delivered to recipients shortly.