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

Responsibility

Expand Messages
  • Phil Lewis
    Going back in time now (coz I don t do email at weekends...) ... Yeah, of course it s just tough nugies. Do you really want to be held responsible for what
    Message 1 of 4 , Sep 2, 2002
    • 0 Attachment
      Going back in time now (coz I don't do email at weekends...)

      > > Nope.
      > > Each individual is respinsible for their own actions, and
      > their own actions
      > > only.
      >
      > So if people take our advice and it's bad advice, it's just tough
      > nugies. Hmm ...

      Yeah, of course it's just tough nugies. Do you really want to be held
      responsible for what people /think/ you meant when you wrote something,
      without the opportunity to confirm their understanding and put them
      straight?

      But even that is not the point. I'm afraid I was actually talking about
      universal law.

      Each individual is responsible for their own actions, and their own actions
      only.

      And thats the soft position. The hard position is much more contraversial,
      and might generate too much off topic discussion.


      **************************************************************************************************
      The views expressed in this E-mail are those of the author and not necessarily those of Knowledge Management Software.
      If you are not the intended recipient or the person responsible for delivering to the intended recipient, please be advised that you have received this E-mail in error and that any use is strictly prohibited.

      If you have received this E-mail in error, please notify us by forwarding this E-mail to the following address:

      mailadmin@...
      **************************************************************************************************
    • Ron Jeffries
      An essay on responsibility in debt reduction. Longer than it might be, but I want to show where I am, and the path I m walking. You will see these ideas again.
      Message 2 of 4 , Feb 25, 2005
      • 0 Attachment
        An essay on responsibility in debt reduction. Longer than it might
        be, but I want to show where I am, and the path I'm walking. You
        will see these ideas again.

        Around Thursday, February 24, 2005, 5:35:35 PM, Kent Beck wrote:

        > You seem to be rather hard on yourself and your team, saying that
        > technical debt is a mistake and that the perpetrator should fix it
        > on personal time. Sometimes technical debt is just the result of
        > doing your best yesterday and then learning something. I think
        > learning is cause for celebration, not self flagellation.

        Thank you, Kent, sincerely, for your concern. Much of the above does
        not describe me, but thanks for the invitation:

        Let's talk about me. What is "doing my best"? There's an old
        tradition, when making something, to put a flaw into it
        intentionally, as a sign of humility before the perfection of
        divinity. Apparently I have no need of this practice, as everything
        I make is flawed unintentionally.

        I want everything that I make to be perfect; it never is. Every day
        I must settle for good enough; every day there is something
        imperfect in what I've done. How can I live with this? It's easy ...
        now, after many years.

        I want my work to be perfect and it is not. Do I accept that?
        Certainly. It's true: I must accept it. Do I stop there, oh well,
        I'm imperfect, might as well get good at it? No. I accept it, and I
        move on, to ... improvement.

        I'm one whole being. I'm imperfect, and I want my work to be
        perfect. I'm imperfect and I always will be. I can't be perfect, and
        I don't accept imperfect. So I choose ... improvement.

        I don't choose blame; I choose responsibility. That missing test? I
        was there and I didn't write it. That bad design? I put it in. That
        promise? I didn't keep it. That's not blame, it's responsibility.
        Perhaps they're hard to tell apart, but they're quite different.

        Kent tells me that the programming team owns the code: I do not. OK,
        I'm the one that put that bad design into our code, but it's our
        code. Our bad design. We own it. We are responsible for the bad
        design in the code. We are responsible for our code having good
        design.

        Brad is telling us that the customer owns the product: the
        programmers do not. The customer owns the product with the bad
        design in it. The customer gets to decide what to do about it.

        Kent and I find that challenging, and scary. Perhaps you do as well.

        (Note to self, for another day: Let's go one step further. The
        whole team owns the product with the bad design. The whole team
        gets to decide what to do about it. Is the divide between customer
        and not-customer a flaw in what should be a unified approach to
        the product? Yes, and no. Yin/yang, one thing. A drop of
        programmer in every customer, a drop of customer in every
        programmer.)

        There's some bad design in our code. I put it in; we all put it in.
        If we had known it was bad, we would not have put it in.

        (Note to self: another day, relate this to YAGNI, which is
        intentionally putting bad design in. No regrets.)

        This particular bit of technical debt is not the result of choosing
        with open eyes to go into debt: I've learned something which, had I
        recognized it sooner, would have guided me sooner to a different
        path.

        How do I learn? Practice. I want to face this flaw, to fix it, and
        in so doing, to perfect myself.

        How does the programming team learn? Practice. I want them to face
        the flaw, to have the opportunity to perfect themselves.

        Practice, like exercise, sometimes hurts a bit. The hurt ... helps.
        It helps us be present in facing the flaw, it helps us build the
        learning into a groove. I want to feel the hurt just enough; I want
        the programmers to feel the hurt just enough. It's not punishment;
        it's not self-flagellation; it's exercise. It's practice. Feel the
        burn.

        Responsibility -- I'm liking that word better than accountability by
        the way -- starts with me. I'm responsible; the programmers are
        responsible; the customer is responsible. The whole team is
        responsible.

        Of course I want to fix the problem: I'm responsible. Of course the
        programmers want to fix the problem: we're responsible. Of course
        the customer wants to steer the project: they're responsible. (Of
        course the whole team ...)

        It starts with personal responsibility. It ends there, having gone
        all the way to the edge of the universe and back.

        Blame? No. Responsibility, yes.
        Self flagellation? No. Responsibility, yes.

        At every level, me, programmers, customer, team: feel the burn.
        That's learning happening. Feel the burn.

        Ron Jeffries
        www.XProgramming.com
        Know what I pray for? The strength to change what I can, the inability to
        accept what I can't and the incapacity to tell the difference. --Calvin and Hobbes
      • Steve Bate
        I am on several quotes lists and this is one I received today... Action springs not from thought, but from a readiness for responsibility. - Dietrich
        Message 3 of 4 , Feb 25, 2005
        • 0 Attachment
          I am on several quotes lists and this is one I received
          today...

          "Action springs not from thought, but from a readiness
          for responsibility." - Dietrich Bonhoeffer

          Seemed apropros...

          > -----Original Message-----
          > From: Ron Jeffries [mailto:ronjeffries@...]
          > Sent: Friday, February 25, 2005 5:18 AM
          > To: extremeprogramming
          > Subject: [XP] Responsibility
          >
          >
          >
          > An essay on responsibility in debt reduction. Longer than it might
          > be, but I want to show where I am, and the path I'm walking. You
          > will see these ideas again.
          >
          > Around Thursday, February 24, 2005, 5:35:35 PM, Kent Beck wrote:
          >
          > > You seem to be rather hard on yourself and your team, saying that
          > > technical debt is a mistake and that the perpetrator should fix it
          > > on personal time. Sometimes technical debt is just the result of
          > > doing your best yesterday and then learning something. I think
          > > learning is cause for celebration, not self flagellation.
          >
          > Thank you, Kent, sincerely, for your concern. Much of the above does
          > not describe me, but thanks for the invitation:
          >
          > Let's talk about me. What is "doing my best"? There's an old
          > tradition, when making something, to put a flaw into it
          > intentionally, as a sign of humility before the perfection of
          > divinity. Apparently I have no need of this practice, as everything
          > I make is flawed unintentionally.
          >
          > I want everything that I make to be perfect; it never is. Every day
          > I must settle for good enough; every day there is something
          > imperfect in what I've done. How can I live with this? It's easy ...
          > now, after many years.
          >
          > I want my work to be perfect and it is not. Do I accept that?
          > Certainly. It's true: I must accept it. Do I stop there, oh well,
          > I'm imperfect, might as well get good at it? No. I accept it, and I
          > move on, to ... improvement.
          >
          > I'm one whole being. I'm imperfect, and I want my work to be
          > perfect. I'm imperfect and I always will be. I can't be perfect, and
          > I don't accept imperfect. So I choose ... improvement.
          >
          > I don't choose blame; I choose responsibility. That missing test? I
          > was there and I didn't write it. That bad design? I put it in. That
          > promise? I didn't keep it. That's not blame, it's responsibility.
          > Perhaps they're hard to tell apart, but they're quite different.
          >
          > Kent tells me that the programming team owns the code: I do not. OK,
          > I'm the one that put that bad design into our code, but it's our
          > code. Our bad design. We own it. We are responsible for the bad
          > design in the code. We are responsible for our code having good
          > design.
          >
          > Brad is telling us that the customer owns the product: the
          > programmers do not. The customer owns the product with the bad
          > design in it. The customer gets to decide what to do about it.
          >
          > Kent and I find that challenging, and scary. Perhaps you do as well.
          >
          > (Note to self, for another day: Let's go one step further. The
          > whole team owns the product with the bad design. The whole team
          > gets to decide what to do about it. Is the divide between customer
          > and not-customer a flaw in what should be a unified approach to
          > the product? Yes, and no. Yin/yang, one thing. A drop of
          > programmer in every customer, a drop of customer in every
          > programmer.)
          >
          > There's some bad design in our code. I put it in; we all put it in.
          > If we had known it was bad, we would not have put it in.
          >
          > (Note to self: another day, relate this to YAGNI, which is
          > intentionally putting bad design in. No regrets.)
          >
          > This particular bit of technical debt is not the result of choosing
          > with open eyes to go into debt: I've learned something which, had I
          > recognized it sooner, would have guided me sooner to a different
          > path.
          >
          > How do I learn? Practice. I want to face this flaw, to fix it, and
          > in so doing, to perfect myself.
          >
          > How does the programming team learn? Practice. I want them to face
          > the flaw, to have the opportunity to perfect themselves.
          >
          > Practice, like exercise, sometimes hurts a bit. The hurt ... helps.
          > It helps us be present in facing the flaw, it helps us build the
          > learning into a groove. I want to feel the hurt just enough; I want
          > the programmers to feel the hurt just enough. It's not punishment;
          > it's not self-flagellation; it's exercise. It's practice. Feel the
          > burn.
          >
          > Responsibility -- I'm liking that word better than accountability by
          > the way -- starts with me. I'm responsible; the programmers are
          > responsible; the customer is responsible. The whole team is
          > responsible.
          >
          > Of course I want to fix the problem: I'm responsible. Of course the
          > programmers want to fix the problem: we're responsible. Of course
          > the customer wants to steer the project: they're responsible. (Of
          > course the whole team ...)
          >
          > It starts with personal responsibility. It ends there, having gone
          > all the way to the edge of the universe and back.
          >
          > Blame? No. Responsibility, yes.
          > Self flagellation? No. Responsibility, yes.
          >
          > At every level, me, programmers, customer, team: feel the burn.
          > That's learning happening. Feel the burn.
          >
          > Ron Jeffries
          > www.XProgramming.com
          > Know what I pray for? The strength to change what I can, the inability to
          > accept what I can't and the incapacity to tell the difference.
          > --Calvin and Hobbes
          >
          >
          >
          >
          > 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
          >
          >
          >
          >
          >
          >
          >
          >
        • Brad Appleton
          ... I do find it scary. Enough to make me want to double-check if that is what I am really saying (or if it follows from that)... Previously, my thinking was
          Message 4 of 4 , Feb 27, 2005
          • 0 Attachment
            Ron Jeffries wrote:
            > Brad is telling us that the customer owns the product: the
            > programmers do not. The customer owns the product with the bad
            > design in it. The customer gets to decide what to do about it.
            >
            > Kent and I find that challenging, and scary. Perhaps you do as well.

            I do find it scary. Enough to make me want to double-check if that is
            what I am really saying (or if it follows from that)...

            Previously, my thinking was that:
            * the product-customer "owns" the product
            * the organization-customer "owns" the project
            * the development-team "owns" the codebase

            Usually, the project manager is a part of the "development team", so I
            want them to take the team's side when the organization and the team
            "lock horns", tho I acknowledge that wont always happen.

            I guess "owning the codebase" implies "owning the 'architecture'". And
            to me, the architecture is what makes it possible (or
            probable/improbable) to produce release after release of the product.
            The product may realize the functionality, but the architecture/code is
            what embodies the knowledge that makes it possible.

            So while the "asset" to the "customer" is the "product" (one release at
            a time), the "asset" to the organization is the architecture (and of
            course the people :-). Getting an organization/management to realize
            that can be very difficult. But I guess the flip-side of that is that
            the "business" owns the architecture, not so much the development team.

            I do think the development team is responsible for the architecture. And
            at the same time, if the organization does appreciate the importance of
            it, and doesnt allow the things necessary to do it well, I bloody well
            agree that the organization (rather than just the programmers) has
            earned more then their fair share of the blame for it, so I guess that
            means they ought to be given responsibility for it too. And that means
            they need to be given the knowledge to decide responsibly - which it
            then falls upon us technical folk to do.

            So I guess I would go so far as to say the "business" owns the
            architecture (the codebase), and the customer owns the product (the
            deliverables derived/built from the codebase). Im not sure if I'd go as
            far as to say the customer owns the architecture too. That does indeed
            scare me a lot - so I guess better listen very closely.

            > At every level, me, programmers, customer, team: feel the burn.
            > That's learning happening. Feel the burn.

            Change and learning can indeed be scary. Growing pains!
            --
            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
          Your message has been successfully submitted and would be delivered to recipients shortly.