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

Re: [scrumdevelopment] Re: design practices

Expand Messages
  • todd
    ... This is a bit of FUD. There s nothing in top down design that makes it any more monolithic or dependent or less changeable than any other design approach.
    Message 1 of 25 , Jan 5, 2005
    • 0 Attachment
      Steven Gordon wrote:

      > Emergent design has other benefits over up-front design besides being
      > able to handle changing/uncertain/emergent requirements:
      >
      > 1. Emergent designs force the code to be easily changable, whereas
      > top-down holistic design can easily create code that is monolithically
      > dependent on the current design. Even if requirements never changed,
      > implementing the system a few requirements at a time results in a
      > system that will be battle tested at being able to accommodate
      > additional requirements after deployment.


      This is a bit of FUD. There's nothing in top down design that makes it
      any more monolithic or dependent or less changeable than any other
      design approach. If you know how to design your code to be testable and
      changeable then it will be. And it can be far easier to add in new
      requirements, depending on the nature of the new requirements. If people
      add useless over complicated code that doesn't work then that's there
      own issue, it's not required by any design methodology that i know of.
      Nor will any design methodology prevent someone from doing stupid stuff.
    • Steven Gordon
      The argument that if you know what you are doing, you can create a perfectly good software using any methodology (or even no methodology) defeats anything we
      Message 2 of 25 , Jan 5, 2005
      • 0 Attachment
        The argument that if you know what you are doing, you can create a perfectly good software using any methodology (or even no methodology) defeats anything we say here. Given the current state of software today, this is not a very realistic or productive argument.

        It is common sense that a design that has had new requirements added to it dozens of times in a principled way can be more trusted to be able to accommodate new requirements of similar kinds than a design that has never had any new requirements added to it.

        -----Original Message-----
        From: todd [mailto:todd@...]
        Sent: Wed 1/5/2005 10:53 AM
        To: scrumdevelopment@yahoogroups.com
        Cc:
        Subject: Re: [scrumdevelopment] Re: design practices




        Steven Gordon wrote:

        > Emergent design has other benefits over up-front design besides being
        > able to handle changing/uncertain/emergent requirements:
        >
        > 1. Emergent designs force the code to be easily changable, whereas
        > top-down holistic design can easily create code that is monolithically
        > dependent on the current design. Even if requirements never changed,
        > implementing the system a few requirements at a time results in a
        > system that will be battle tested at being able to accommodate
        > additional requirements after deployment.


        This is a bit of FUD. There's nothing in top down design that makes it
        any more monolithic or dependent or less changeable than any other
        design approach. If you know how to design your code to be testable and
        changeable then it will be. And it can be far easier to add in new
        requirements, depending on the nature of the new requirements. If people
        add useless over complicated code that doesn't work then that's there
        own issue, it's not required by any design methodology that i know of.
        Nor will any design methodology prevent someone from doing stupid stuff.
      • todd
        ... It s productive and realistic because you can t overcome this lack by adding a methodology. So dinging one methodology in favor another isn t fair, imho.
        Message 3 of 25 , Jan 5, 2005
        • 0 Attachment
          Steven Gordon wrote:

          > The argument that if you know what you are doing, you can create a
          > perfectly good software using any methodology (or even no methodology)
          > defeats anything we say here.

          It's productive and realistic because you can't overcome this lack by
          adding a methodology. So dinging one methodology in favor another isn't
          fair, imho.

          >
          > It is common sense that a design that has had new requirements added
          > to it dozens of times in a principled way can be more trusted to be
          > able to accommodate new requirements of similar kinds than a design
          > that has never had any new requirements added to it.

          The use of the word "principled" defeats anything we say here. Given
          the current state of software today, this is not a very realistic or
          productive argument. :-)
        Your message has been successfully submitted and would be delivered to recipients shortly.