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

RE: [scrumdevelopment] Re: design practices

Expand Messages
  • Steven Gordon
    Emergent design has other benefits over up-front design besides being able to handle changing/uncertain/emergent requirements: 1. Emergent designs force the
    Message 1 of 25 , Jan 5, 2005
    • 0 Attachment
      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.

      2. Developers can learn something from the design and implementation of a few requirements that will improve the design and implementation of the remaining requirements, whereas if we design the whole thing before implementing any of it, we get no feedback on whether the overall design strategy is a good one.

      3. We can better estimate how long it will take to complete the project from the first month of design and implementation of a few requirements from beginning to end than from just a month of pure design.

      Steven Gordon

      http://sf.asu.edu/




      --- In scrumdevelopment@yahoogroups.com, "Joel" <jadams@d...> wrote:
      > Another assumption we frequently make is that design should be
      > emergent. Writing code only for the current function is a good
      thing
      > because re-writing isn't expensive compared to adding complexity
      and
      > functionality that is never needed. But in the case where all
      > functionality has equal priority, and the system cannot be released
      > until all of the functionality is included, isn't this an
      inefficient
      > approach?
      > My guess is that this project would benefit from more up-front
      design
      > than a new development project. And I think that I would be asking
      > the team where else they can find efficiencies given the somewhat
      > unique situation.
    • 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 2 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 3 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 4 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.