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

RE: [scrumdevelopment] Digest Number 390

Expand Messages
  • Steven Gordon
    Kevin, My point always was that effective software engineering requires both technical competence and something that is outside the scope of CS and CE: the
    Message 1 of 4 , Sep 2, 2003
    • 0 Attachment
      Kevin,

      My point always was that effective software engineering requires both
      technical competence and something that is outside the scope of CS and CE:
      the ability to work effectively in human organizations.

      I think you will find that the vast majority of development failures are not
      due to misunderstanding the principles of computer science or software
      engineering practice, but due to things that fall outside of the scope of
      pure science and engineering such as:
      1. Poor customer relations;
      2. Not being able to work with vague or evolving requirements;
      3. Caving in to political or economic pressures to overcommit;
      4. Mishandling stakeholder politics;
      5. Not being able to persuade the right people to do the things that will
      lead to success.
      The list goes on.

      Look at the problems NASA has. I do not think NASA's problem is that they
      do not know how to do ISO processes correctly. While every failure may
      superficially be a technical error of some sort, independent reviews have
      concluded that it is human organizational, social, and political issues that
      have ultimately lead to these errors and the resulting failures.

      Steven Gordon



      -----Original Message-----
      From: Kevin Aguanno [mailto:aguanno@...]
      Sent: Tue 9/2/2003 7:42 AM
      To: scrumdevelopment@yahoogroups.com
      Cc:
      Subject: Re: [scrumdevelopment] Digest Number 390

      I agree with Paul Tiseo:

      >The fact that it isn't done well by many practitioners shouldn't mean that
      >there is no science and/or engineering in software.

      It is just like the problem with ISO-900X quality systems. The concept was
      designed to create a system that attempts to stabilize quality by ensuring
      consistency, and then the next step was to slowly adjust factors that
      improve the quality, once consistent. Problem is, most applications I have
      seen simply try to stabilize the quality through consistent processes and
      stop there; they never take the next step and try to improve quality.

      Software developers may be following SE or CE practices, but without the
      feedback loop (the attempt to improve their own adaptation or application
      of the processes/techniques) then there will be no learning and no
      improvement over time. The fact that "it isn't being done well" may be a
      failure to learn, or a failure to incorporate the learning, not a failure
      in SE or CE principles.


      ----------
      Kevin J.J. Aguanno, PMPĀ®, MAPM
      IBM Certified Senior Project Manager,
      Canadian Project Management Knowledge Network (PMKN) Leader
      e-business Integration Solutions,
      IBM Global Services
      IBM Canada Ltd.

      Phone: (905) 316-8966
      Fax: (905) 316-2535
      Pager: (416) 600-0794






      Yahoo! Groups Sponsor

      <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17072090
      21:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir?
      camp=556&lineid=3614674?=egroupweb&pos=HM>

      <http://us.adserver.yahoo.com/l?M=259395.3614674.4902533.1261774/D=egroupmai
      l/S=:HM/A=1524963/rand=635105637>

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
      <http://docs.yahoo.com/info/terms/> .
    • Tiseo, Paul
      Well, maybe I didn t make myself clear, but *proper and well-designed* engineering processes invariably take into account the people dimension. They have to do
      Message 2 of 4 , Sep 2, 2003
      • 0 Attachment
        Well, maybe I didn't make myself clear, but *proper and well-designed*
        engineering processes invariably take into account the people dimension.
        They have to do so to be effective processes. (Furthermore, proper science
        doesn't concern itself with people issues, unless it is the science of
        people issues, such as psychology. A science is about pure knowledge.)

        IMO, agile SE is a minimal set of one or more lightweight processes (Scrum,
        XP, etc...) which are designed to take into account some things that seem to
        lie outside technical knowledge, like those Steve mentioned.

        For example, many agile processes are designed to handle the fact that
        requirements are hard to pin down. "Hard to pin down requirements" is a
        "people"-level problem and we can try to explain why that is true. It is a
        fact from the sociological and cognitive sciences. This currently accepted
        fact drives lightweight SE processes into a different mold or solution than
        heavyweight SE processes. The former throws bodies, time and formal review
        at the problem and tries to fully define from the get-go, the latter prefers
        to involve the source of the requirements closer to the process with
        incremental steps towards full elucidation plus the mindset of possible
        and/or eventual refactoring.

        What about this "mishandling stakeholder politics"? Does Scrum help us with
        that? Don't we try to minimize up-front design because of this political
        possibility? Isn't our choice of effective SE process(es) being affected by
        fields/sciences other than the pure technical of CS?

        Also, we shouldn't confuse effective SE process(es) with effective political
        maneuvering techniques. The latter are much more generically applicable
        processes that should be in the toolset of any senior corporate worker,
        software or not... :)

        _________________________________
        Paul Tiseo, Systems Programmer
        Research Computing Facility
        Mayo Clinic Jacksonville, Griffin 371
        tiseo123.paul456@...


        Absence is to love what wind is to fire; it extinguishes the small, it
        enkindles the great. - Comte de Bussy-Rabutin
        -----Original Message-----
        From: Steven Gordon [mailto:sagordon@...]
        Sent: Tuesday, September 02, 2003 11:32 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] Digest Number 390

        Kevin,

        My point always was that effective software engineering requires both
        technical competence and something that is outside the scope of CS and CE:
        the ability to work effectively in human organizations.

        I think you will find that the vast majority of development failures are not
        due to misunderstanding the principles of computer science or software
        engineering practice, but due to things that fall outside of the scope of
        pure science and engineering such as:
        1. Poor customer relations;
        2. Not being able to work with vague or evolving requirements;
        3. Caving in to political or economic pressures to overcommit;
        4. Mishandling stakeholder politics;
        5. Not being able to persuade the right people to do the things that will
        lead to success.
        The list goes on.

        Look at the problems NASA has. I do not think NASA's problem is that they
        do not know how to do ISO processes correctly. While every failure may
        superficially be a technical error of some sort, independent reviews have
        concluded that it is human organizational, social, and political issues that
        have ultimately lead to these errors and the resulting failures.

        Steven Gordon



        -----Original Message-----
        From: Kevin Aguanno [mailto:aguanno@...]
        Sent: Tue 9/2/2003 7:42 AM
        To: scrumdevelopment@yahoogroups.com
        Cc:
        Subject: Re: [scrumdevelopment] Digest Number 390

        I agree with Paul Tiseo:

        >The fact that it isn't done well by many practitioners shouldn't mean that
        >there is no science and/or engineering in software.

        It is just like the problem with ISO-900X quality systems. The concept was
        designed to create a system that attempts to stabilize quality by ensuring
        consistency, and then the next step was to slowly adjust factors that
        improve the quality, once consistent. Problem is, most applications I have
        seen simply try to stabilize the quality through consistent processes and
        stop there; they never take the next step and try to improve quality.

        Software developers may be following SE or CE practices, but without the
        feedback loop (the attempt to improve their own adaptation or application
        of the processes/techniques) then there will be no learning and no
        improvement over time. The fact that "it isn't being done well" may be a
        failure to learn, or a failure to incorporate the learning, not a failure
        in SE or CE principles.


        ----------
        Kevin J.J. Aguanno, PMP(r), MAPM
        IBM Certified Senior Project Manager,
        Canadian Project Management Knowledge Network (PMKN) Leader
        e-business Integration Solutions,
        IBM Global Services
        IBM Canada Ltd.

        Phone: (905) 316-8966
        Fax: (905) 316-2535
        Pager: (416) 600-0794






        Yahoo! Groups Sponsor

        <http://rd.yahoo.com/M=259395.3614674.4902533.1261774/D=egroupweb/S=17072090
        21:HM/A=1524963/R=0/SIG=12o885gmo/*http://hits.411web.com/cgi-bin/autoredir?
        camp=556&lineid=3614674?=egroupweb&pos=HM>

        <http://us.adserver.yahoo.com/l?M=259395.3614674.4902533.1261774/D=egroupmai
        l/S=:HM/A=1524963/rand=635105637>

        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...

        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
        <http://docs.yahoo.com/info/terms/> .


        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Jeff Sutherland
        I agree totally with Mary on this. Anyone who applies the scientific method to the waterfall process will prove repeatedly that it is totally broken, highly
        Message 3 of 4 , Sep 10, 2003
        • 0 Attachment
          I agree totally with Mary on this. Anyone who applies the scientific method
          to the waterfall process will prove repeatedly that it is totally broken,
          highly failure prone, and that most successful projects do not use it (even
          if they say they use it). Craig Larman's excellent review article in
          Computer magazine on the history of interative and incremental development
          documents that the guy that wrote the DOD standard that inflicted the
          waterfall method on us confesses that he made a mistake. He had no direct
          experience and relied on consultants and textbooks that were fatally flawed.

          Fred Brooks spent a decade on DOD standards committees getting the
          waterfall method revoked. It is no longer the preferred DOD approach. Too
          bad they lost billions on failed projects while Brooks and his committee
          were working on dismantling this beauracratic foolishness. All of this is
          documented on my web blog chapter and verse with links to critical papers.
          Read the DOD paper on the economic impact of the waterfall method. The DOD
          could pay for the Iraqi war with money saved by avoiding this methodology.

          Jeff Sutherland

          At 06:50 AM 8/30/2003, you wrote:
          >I don't see how Waterfall (sequential development) can be considered a
          >form of the Scientific Method. I wonder what your definition of
          >Scientific Method might be to come to such a conclusion.
        Your message has been successfully submitted and would be delivered to recipients shortly.