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

design practices

Expand Messages
  • Steven Mak
    Hi all, I am going to have a new project soon and I am the project manager of the project. I want to apply scrum practices with this project. My knowledge in
    Message 1 of 25 , Dec 23, 2004
    • 0 Attachment
      Hi all,

      I am going to have a new project soon and I am the project manager of
      the project. I want to apply scrum practices with this project. My
      knowledge in scrum is limited to this group, some online materials,
      and a book. Thus, hope this gives me practical experiences in how my
      development team more 'agile'.

      The project is about re-writing a system that has been using for
      serveral years. It's so badly written that it has to be re-written so
      as to have a easier life to maintain it.

      The first query is not about 'design'. Is traditional software
      development works better when we have deep understanding about the
      system? (eg. re-writing a system that we have been using for serveral
      years) or I would like to know how agile methologies work better in a
      not-so-emergent system development.

      The scope of the system is rather board, thus I believe it would take
      quite a number of iterations before its functionalities can compare
      with the existing system.

      I am wondering, with such a large system. How infrastruture and
      software design is done in Scrum, while not falling into the BDUF
      problem? Suppose it's a 4-week iteration. Would 'design' and
      'architecutral' work takes up more time in the first few iterations
      than the later iterations, as it gets sufficiently-built for most
      services on top of it?

      Is there any references on recommended design practices in Scrum?
      Thank you.

      Happy Holiday
      Steven
    • Reginald Braithwaite-Lee
      ... http://www.joelonsoftware.com/articles/fog0000000069.html -- Reginald Braithwaite-Lee http://www.braithwaite-lee.com/weblog/
      Message 2 of 25 , Dec 23, 2004
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...> wrote:

        > The project is about re-writing a system that has been using for
        > serveral years. It's so badly written that it has to be re-written so
        > as to have a easier life to maintain it.

        http://www.joelonsoftware.com/articles/fog0000000069.html

        --
        Reginald Braithwaite-Lee
        http://www.braithwaite-lee.com/weblog/
      • Ron Jeffries
        ... What would prevent you from working for four weeks and completing some one important feature of the program? What would prevent you from actually deploying
        Message 3 of 25 , Dec 23, 2004
        • 0 Attachment
          On Thursday, December 23, 2004, at 10:00:45 AM, Steven Mak wrote:

          > I am wondering, with such a large system. How infrastruture and
          > software design is done in Scrum, while not falling into the BDUF
          > problem? Suppose it's a 4-week iteration. Would 'design' and
          > 'architecutral' work takes up more time in the first few iterations
          > than the later iterations, as it gets sufficiently-built for most
          > services on top of it?

          What would prevent you from working for four weeks and completing
          some one important feature of the program?

          What would prevent you from actually deploying just that one
          feature?

          Ron Jeffries
          www.XProgramming.com
          Reason is and ought only to be the slave of the passions. -- David Hume
        • Hubert Smits
          Hi Steven, I ve been through two or three of these rewrite project, although not always in agile fashion. ... So that s how you sold it to management :-) ...
          Message 4 of 25 , Dec 23, 2004
          • 0 Attachment
            Hi Steven,

            I've been through two or three of these 'rewrite' project, although
            not always in agile fashion.


            On Thu, 23 Dec 2004 15:00:45 -0000, Steven Mak <tcmak@...> wrote:
            >
            >
            > Hi all,
            >
            > I am going to have a new project soon and I am the project manager of
            > the project. I want to apply scrum practices with this project. My
            > knowledge in scrum is limited to this group, some online materials,
            > and a book. Thus, hope this gives me practical experiences in how my
            > development team more 'agile'.
            >
            > The project is about re-writing a system that has been using for
            > serveral years. It's so badly written that it has to be re-written so
            > as to have a easier life to maintain it.

            So that's how you sold it to management :-)

            > The first query is not about 'design'. Is traditional software
            > development works better when we have deep understanding about the
            > system? (eg. re-writing a system that we have been using for serveral
            > years) or I would like to know how agile methologies work better in a
            > not-so-emergent system development.

            You need indeed a good understanding of the system, but this isn't too
            different from building a new system. The knowledge you need is about
            the outside, not the inside of the apps. What is it supposed to
            produce, against what input etc. Very similar to a new system.

            There are two traps to be aware of: 1) the old system may produce
            wrong results that everybody thinks are correct, giving you a hard
            time to prove that your new system is working correct. And 2) don't
            extend functionality as it equals to scope creep. Agile principles
            will help you here, but can also create a problem. Once the customers
            starts prioritising functionality changes over functionality migration
            then you're stuck with a half migrated system.

            > The scope of the system is rather board, thus I believe it would take
            > quite a number of iterations before its functionalities can compare
            > with the existing system.

            You may want to consider reducing functionality. Also think of a way
            to run both systems in parallel, the old one gradually reducing in
            size, the new one gradually growing.

            > I am wondering, with such a large system. How infrastruture and
            > software design is done in Scrum, while not falling into the BDUF
            > problem? Suppose it's a 4-week iteration. Would 'design' and
            > 'architecutral' work takes up more time in the first few iterations
            > than the later iterations, as it gets sufficiently-built for most
            > services on top of it?

            Hmm, you seem to be thinking in plan driven terms, but wrapping each
            phase into multiple iterations (I could be wrong of course). Each
            iteration delivers working software, not a document or 'architecture'.

            Having said that, I do agree that a certain amount of architecture
            work needs to be done upfront. I know that others disagree with me, I
            expect them to speak as well as it will be good to compare the
            methods. I would spend the first sprint to design the priniciple
            architecture and proof it's concept. Then start migrating functions
            and grow the architecture.

            > Is there any references on recommended design practices in Scrum?

            Scrum doesn't pescribe engineering practices. Have a look at
            <http://www.agilealliance.org/programs/roadmaps/Roadmap/modeling/modeling_index.htm>
            for some info on agile modelling.

            > Thank you.
            >
            > Happy Holiday
            > Steven

            Same to you!

            --Hubert
          • Hubert Smits
            Reginald, Interesting viewpoint from Joel. I can go a long way with him, but think that one reason to rewrite is missing from his list. Code can be a blackbox:
            Message 5 of 25 , Dec 23, 2004
            • 0 Attachment
              Reginald,

              Interesting viewpoint from Joel. I can go a long way with him, but
              think that one reason to rewrite is missing from his list. Code can be
              a blackbox: 25 year old mainframe assembly language for which the
              hardware is no longer available. Hense you have no choice.

              --Hubert


              On Thu, 23 Dec 2004 16:26:52 -0000, Reginald Braithwaite-Lee
              <raganwald@...> wrote:
              >
              >
              > --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...> wrote:
              >
              > > The project is about re-writing a system that has been using for
              > > serveral years. It's so badly written that it has to be re-written so
              > > as to have a easier life to maintain it.
              >
              > http://www.joelonsoftware.com/articles/fog0000000069.html
              >
              > --
              > Reginald Braithwaite-Lee
              > http://www.braithwaite-lee.com/weblog/
              >
              >
              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
            • Gary F
              ... If you re going to do Scrum, then I believe you re starting with the wrong questions. Start with questions like who is the customer, who is the product
              Message 6 of 25 , Dec 23, 2004
              • 0 Attachment
                --- Steven Mak <tcmak@...> wrote:

                > I am wondering, with such a large system. How infrastruture and
                > software design is done in Scrum, while not falling into the BDUF
                > problem? Suppose it's a 4-week iteration. Would 'design' and
                > 'architecutral' work takes up more time in the first few iterations
                > than the later iterations, as it gets sufficiently-built for most
                > services on top of it?

                If you're going to do Scrum, then I believe you're starting with the wrong questions.

                Start with questions like who is the customer, who is the product owner, what is the business
                value? Once you know the product owner, you have someone with responsibility for prioritizing
                results that add business value.

                Then you can start asking the questions about what to do about design - if indeed that's what
                needs to be addressed first. Conceivably, you might want to keep the existing design and simply
                replace those sections that are most in need - maybe because they have a high defect density, or
                maybe because the most urgent enhancements require refactoring of specific modules.

                > Is there any references on recommended design practices in Scrum?

                Scrum is about project management, not software design. While XP practices are consistent with
                Scrum in the sense of both being Agile, both targetting short iterations that deliver value, there
                is no requirement that one use XP approaches with Scrum. It's perfectly possible to use Scrum
                with traditional design approaches (though it is only in highly structured business environments
                where such designs can easily be shown to add value).

                You might want to address the software-specific questions to the extremeprogramming group on
                Yahoo, or maybe peruse the articles on Design at the Agile Alliance (
                http://www.agilealliance.org/articles/searchResults?topic=Design ). In fact, their article index
                at http://www.agilealliance.org/articles is a good place to start in general.

                Gary



                __________________________________
                Do you Yahoo!?
                Yahoo! Mail - Find what you need with new enhanced search.
                http://info.mail.yahoo.com/mail_250
              • Steven Mak
                Hi Ron, hmm.... I am not sure if I can get your meaning clearly (sorry for my limited English). I am not sure if anything prevents us from completing an
                Message 7 of 25 , Dec 23, 2004
                • 0 Attachment
                  Hi Ron,

                  hmm.... I am not sure if I can get your meaning
                  clearly (sorry for my limited English). I am not sure
                  if anything prevents us from completing an iteration.
                  But I am rather new in scrum and wondering if how
                  'design' is dealt with, or any practices that I
                  overlooked to prevent spending the whole iteration on
                  'design' but not delivering anything 'valuable'.

                  Steven

                  --- Ron Jeffries <ronjeffries@...> wrote:

                  > On Thursday, December 23, 2004, at 10:00:45 AM,
                  > Steven Mak wrote:
                  >
                  > > I am wondering, with such a large system. How
                  > infrastruture and
                  > > software design is done in Scrum, while not
                  > falling into the BDUF
                  > > problem? Suppose it's a 4-week iteration. Would
                  > 'design' and
                  > > 'architecutral' work takes up more time in the
                  > first few iterations
                  > > than the later iterations, as it gets
                  > sufficiently-built for most
                  > > services on top of it?
                  >
                  > What would prevent you from working for four weeks
                  > and completing
                  > some one important feature of the program?
                  >
                  > What would prevent you from actually deploying just
                  > that one
                  > feature?
                  >
                  > Ron Jeffries
                  > www.XProgramming.com
                  > Reason is and ought only to be the slave of the
                  > passions. -- David Hume
                  >
                  >
                  >




                  __________________________________
                  Do you Yahoo!?
                  Yahoo! Mail - now with 250MB free storage. Learn more.
                  http://info.mail.yahoo.com/mail_250
                • Steven Gordon
                  What it comes down to is the difference between the cost of maintaining the current software and the value of doing so, when compared to difference between the
                  Message 8 of 25 , Dec 23, 2004
                  • 0 Attachment
                    What it comes down to is the difference between the cost of maintaining the
                    current software and the value of doing so, when compared to difference
                    between the cost and value of rewriting the system.

                    If the users of the software are happy with the current utility of the product
                    and maintenance just consists of support and no addition of new features,
                    then it is hard to imagine a scenario where it makes business sense to rewrite.

                    If, on the other hand, maintenance currently includes the addition of new
                    features that are of great value to your customers and the current state of the
                    code is making the addition of these new feature difficult and expensive, then
                    rewriting could make sense. Even in this case, refactoring the old code
                    should be seriously considered.

                    Since these new features would have to be the essential payback, even if
                    you rewrite, you are also adding new functionality. If you can find a way to
                    implement the new functionality first in a way that can call the old system,
                    then you can achieve quicker payback, and also have a new system where
                    you can incrementally replace parts of the old system without impacting
                    customers.

                    Steven Gordon
                    http://sf.asu.edu/


                    -----Original Message-----
                    From: Reginald Braithwaite-Lee [mailto:raganwald@...]
                    Sent: Thu 12/23/2004 9:26 AM
                    To: scrumdevelopment@yahoogroups.com
                    Cc:
                    Subject: [scrumdevelopment] Re: design practices



                    --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...> wrote:

                    > The project is about re-writing a system that has been using for
                    > serveral years. It's so badly written that it has to be re-written so
                    > as to have a easier life to maintain it.

                    http://www.joelonsoftware.com/articles/fog0000000069.html

                    --
                    Reginald Braithwaite-Lee
                    http://www.braithwaite-lee.com/weblog/





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



                    Yahoo! Groups Sponsor
                    ADVERTISEMENT
                    click here <http://us.ard.yahoo.com/SIG=12961c1n1/M=294855.5468653.6549235.3001176/D=groups/S=1707209021:HM/EXP=1103905692/A=2455397/R=0/SIG=119u9qmi7/*http://smallbusiness.yahoo.com/domains/>
                    <http://us.adserver.yahoo.com/l?M=294855.5468653.6549235.3001176/D=groups/S=:HM/A=2455397/rand=621437464>


                    _____

                    Yahoo! Groups Links


                    * To visit your group on the web, go to:
                    http://groups.yahoo.com/group/scrumdevelopment/

                    * To unsubscribe from this group, send an email to:
                    scrumdevelopment-unsubscribe@yahoogroups.com <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                    * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
                  • Ron Jeffries
                    ... I don t always agree with Joel, but on this one I pretty much do. But ... there is an agile approach to replacing a whole legacy program. It s related to
                    Message 9 of 25 , Dec 23, 2004
                    • 0 Attachment
                      On Thursday, December 23, 2004, at 11:26:52 AM, Reginald Braithwaite-Lee wrote:

                      > --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...> wrote:

                      >> The project is about re-writing a system that has been using for
                      >> serveral years. It's so badly written that it has to be re-written so
                      >> as to have a easier life to maintain it.

                      > http://www.joelonsoftware.com/articles/fog0000000069.html

                      I don't always agree with Joel, but on this one I pretty much do.
                      But ... there is an agile approach to replacing a whole legacy
                      program. It's related to the agile approach to eating an elephant.

                      Ron Jeffries
                      www.XProgramming.com
                      Speculation or experimentation - which is more likely to give the correct answer?
                    • Ron Jeffries
                      ... I m supposing that the program is made up of features, is it not? Then why not do what Scrum prescribes, and deliver one or more features /in the very
                      Message 10 of 25 , Dec 23, 2004
                      • 0 Attachment
                        On Thursday, December 23, 2004, at 12:38:02 PM, Steven Mak wrote:

                        > hmm.... I am not sure if I can get your meaning
                        > clearly (sorry for my limited English). I am not sure
                        > if anything prevents us from completing an iteration.
                        > But I am rather new in scrum and wondering if how
                        > 'design' is dealt with, or any practices that I
                        > overlooked to prevent spending the whole iteration on
                        > 'design' but not delivering anything 'valuable'.

                        I'm supposing that the program is made up of features, is it not?

                        Then why not do what Scrum prescribes, and deliver one or more
                        features /in the very first month/, and every month thereafter?

                        And why not deploy those features, incrementally, one by one by one?

                        What would prevent you from doing that?

                        Ron Jeffries
                        www.XProgramming.com
                        Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
                        of his head. It is, as far as he knows, the only way of coming downstairs,
                        but sometimes he feels that there really is another way, if only he could
                        stop bumping for a moment and think of it. And then he feels that perhaps
                        there isn't. -- A. A. Milne
                      • Reginald Braithwaite-Lee
                        ... What experience has taught me is that the cost of software development is almost irrelevant: it s all about managing risks. A rewrite is a very risky
                        Message 11 of 25 , Dec 23, 2004
                        • 0 Attachment
                          --- In scrumdevelopment@yahoogroups.com, Steven Gordon <sagordon@a...> wrote:

                          > What it comes down to is the difference between the cost of maintaining the
                          > current software and the value of doing so, when compared to difference
                          > between the cost and value of rewriting the system.

                          What experience has taught me is that the cost of software development is almost
                          irrelevant: it's all about managing risks.

                          A rewrite is a very risky proposition, especially when compared to incremental alternatives
                          like refactoring or wrapping the legacy "Big Ball of Mud."

                          This is especially true when new functionality is added to the mandate: new functionality
                          invariably bloats the project and adds a high degree of risk. After all, if you don't have a
                          pressing need to add new functionality, why rewrite?

                          Of course, my jaded and cynical view of rewrites is driven by my direct observation of a
                          number of failures directly attributable to good intentioned rewrites ("Now with Object
                          Orientation!" "Now with Oracle!", and even "Goodbye Pascal, Hello C").

                          On the flip side, how many successful products/projects carry on delivering value when
                          under the hood their architecture is byzantine or even roccoco?
                        • Reginald Braithwaite-Lee
                          ... I just interviewed a fellow working on almost exactly the situation you describe. His team is doing most of the translation mechanically, parsing code and
                          Message 12 of 25 , Dec 23, 2004
                          • 0 Attachment
                            --- In scrumdevelopment@yahoogroups.com, Hubert Smits <hubert.smits@g...> wrote:
                            > Reginald,
                            >
                            > Interesting viewpoint from Joel. I can go a long way with him, but
                            > think that one reason to rewrite is missing from his list. Code can be
                            > a blackbox: 25 year old mainframe assembly language for which the
                            > hardware is no longer available. Hense you have no choice.

                            I just interviewed a fellow working on almost exactly the situation you describe. His team
                            is doing most of the translation mechanically, parsing code and writing a new program
                            witha lot of JavaCC and other tools.

                            They consider what they are doing as "porting" the system, not "rewriting" it, and one
                            point he made to me is that they are doing a "bug for bug" port: they are not responsible
                            for fixing any bugs until the whole thing is ported to the new environment.

                            This management of scope is impressive.

                            I'm familiar with another company doing a similar thing: they have software that translates
                            Powerbuilder code into Java Swing apps. Again, it's really porting and not rewriting. The
                            Java app looks like a Java app but the behaviour is 100% that of the old system, so much
                            so that they boast that the existing PB guys can understand the new Java code with
                            minimal Java training.

                            I would guess that this sort of port runs 100% counter to the intention that a rewrite "clean
                            up" a problem application.
                          • Hubert Smits
                            Hi Reginald, I wouldn t favour this approach, afraid of the garbage in, garbage out principle. What are the experiences of the two teams involved? Is the
                            Message 13 of 25 , Dec 24, 2004
                            • 0 Attachment
                              Hi Reginald,

                              I wouldn't favour this approach, afraid of the 'garbage in, garbage
                              out' principle. What are the experiences of the two teams involved? Is
                              the result of their efforts new suitable for either refactoring (with
                              less effort) and is it extendable with new functionality?

                              --Hubert


                              On Fri, 24 Dec 2004 03:38:17 -0000, Reginald Braithwaite-Lee
                              <raganwald@...> wrote:
                              >
                              >
                              > --- In scrumdevelopment@yahoogroups.com, Hubert Smits <hubert.smits@g...> wrote:
                              > > Reginald,
                              > >
                              > > Interesting viewpoint from Joel. I can go a long way with him, but
                              > > think that one reason to rewrite is missing from his list. Code can be
                              > > a blackbox: 25 year old mainframe assembly language for which the
                              > > hardware is no longer available. Hense you have no choice.
                              >
                              > I just interviewed a fellow working on almost exactly the situation you describe. His team
                              > is doing most of the translation mechanically, parsing code and writing a new program
                              > witha lot of JavaCC and other tools.
                              >
                              > They consider what they are doing as "porting" the system, not "rewriting" it, and one
                              > point he made to me is that they are doing a "bug for bug" port: they are not responsible
                              > for fixing any bugs until the whole thing is ported to the new environment.
                              >
                              > This management of scope is impressive.
                              >
                              > I'm familiar with another company doing a similar thing: they have software that translates
                              > Powerbuilder code into Java Swing apps. Again, it's really porting and not rewriting. The
                              > Java app looks like a Java app but the behaviour is 100% that of the old system, so much
                              > so that they boast that the existing PB guys can understand the new Java code with
                              > minimal Java training.
                              >
                              > I would guess that this sort of port runs 100% counter to the intention that a rewrite "clean
                              > up" a problem application.
                              >
                              >
                              > To Post a message, send it to: scrumdevelopment@...
                              > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                            • Gary F
                              ... Having done porting work in the past, I wouldn t call this porting. To me, porting means getting a code base to work on a different platform, e.g. between
                              Message 14 of 25 , Dec 24, 2004
                              • 0 Attachment
                                --- Reginald Braithwaite-Lee <raganwald@...> wrote:
                                > They consider what they are doing as "porting" the system, not "rewriting" it, and one

                                Having done porting work in the past, I wouldn't call this porting. To me, porting means getting
                                a code base to work on a different platform, e.g. between UNIX and MS Windows, or between Apache
                                and IE. The case you describe is what I'd consider a translation from one language to another.

                                The main difference is that with the sort of porting work I did, we tried very hard to keep the
                                changes to a minimum. There could easily be large portions of the code base we wouldn't go near.
                                But what you're describing touches everything.

                                Gary




                                __________________________________
                                Do you Yahoo!?
                                Send holiday email and support a worthy cause. Do good.
                                http://celebrity.mail.yahoo.com
                              • Steven Mak
                                Hi Hubert, ... Do you mind sharing your experience and opinions on these projects? do you think it would be better to run in an agile fashion? ... It s rather
                                Message 15 of 25 , Dec 24, 2004
                                • 0 Attachment
                                  Hi Hubert,


                                  --- Hubert Smits <hubert.smits@...> wrote:

                                  > Hi Steven,
                                  >
                                  > I've been through two or three of these 'rewrite'
                                  > project, although
                                  > not always in agile fashion.
                                  >

                                  Do you mind sharing your experience and opinions on
                                  these projects? do you think it would be better to run
                                  in an agile fashion?

                                  >
                                  > On Thu, 23 Dec 2004 15:00:45 -0000, Steven Mak
                                  > <tcmak@...> wrote:
                                  > >
                                  > >
                                  > > Hi all,
                                  > >
                                  > > I am going to have a new project soon and I am the
                                  > project manager of
                                  > > the project. I want to apply scrum practices with
                                  > this project. My
                                  > > knowledge in scrum is limited to this group, some
                                  > online materials,
                                  > > and a book. Thus, hope this gives me practical
                                  > experiences in how my
                                  > > development team more 'agile'.
                                  > >
                                  > > The project is about re-writing a system that has
                                  > been using for
                                  > > serveral years. It's so badly written that it has
                                  > to be re-written so
                                  > > as to have a easier life to maintain it.
                                  >
                                  > So that's how you sold it to management :-)

                                  It's rather a long story and I am not the salesman of
                                  this to the management. It's very much like Steven
                                  Gordon mentioned in another email. There are new
                                  features to be supported from month to month while the
                                  system is not well designed to cater for the new
                                  features. There are also some fundamental design flaw
                                  that are costly to fix. It's indeed a challenge to
                                  make it more flexible and make it more ready as a
                                  product to sell in the future, instead of a project
                                  for a single customer.

                                  >
                                  > > The first query is not about 'design'. Is
                                  > traditional software
                                  > > development works better when we have deep
                                  > understanding about the
                                  > > system? (eg. re-writing a system that we have been
                                  > using for serveral
                                  > > years) or I would like to know how agile
                                  > methologies work better in a
                                  > > not-so-emergent system development.
                                  >
                                  > You need indeed a good understanding of the system,
                                  > but this isn't too
                                  > different from building a new system. The knowledge
                                  > you need is about
                                  > the outside, not the inside of the apps. What is it
                                  > supposed to
                                  > produce, against what input etc. Very similar to a
                                  > new system.
                                  >
                                  > There are two traps to be aware of: 1) the old
                                  > system may produce
                                  > wrong results that everybody thinks are correct,
                                  > giving you a hard
                                  > time to prove that your new system is working
                                  > correct. And 2) don't
                                  > extend functionality as it equals to scope creep.
                                  > Agile principles
                                  > will help you here, but can also create a problem.
                                  > Once the customers
                                  > starts prioritising functionality changes over
                                  > functionality migration
                                  > then you're stuck with a half migrated system.
                                  >

                                  Thank you, I will bear this in mind.

                                  > > The scope of the system is rather board, thus I
                                  > believe it would take
                                  > > quite a number of iterations before its
                                  > functionalities can compare
                                  > > with the existing system.
                                  >
                                  > You may want to consider reducing functionality.
                                  > Also think of a way
                                  > to run both systems in parallel, the old one
                                  > gradually reducing in
                                  > size, the new one gradually growing.
                                  >
                                  > > I am wondering, with such a large system. How
                                  > infrastruture and
                                  > > software design is done in Scrum, while not
                                  > falling into the BDUF
                                  > > problem? Suppose it's a 4-week iteration. Would
                                  > 'design' and
                                  > > 'architecutral' work takes up more time in the
                                  > first few iterations
                                  > > than the later iterations, as it gets
                                  > sufficiently-built for most
                                  > > services on top of it?
                                  >
                                  > Hmm, you seem to be thinking in plan driven terms,
                                  > but wrapping each
                                  > phase into multiple iterations (I could be wrong of
                                  > course). Each
                                  > iteration delivers working software, not a document
                                  > or 'architecture'.
                                  >
                                  > Having said that, I do agree that a certain amount
                                  > of architecture
                                  > work needs to be done upfront. I know that others
                                  > disagree with me, I
                                  > expect them to speak as well as it will be good to
                                  > compare the
                                  > methods. I would spend the first sprint to design
                                  > the priniciple
                                  > architecture and proof it's concept. Then start
                                  > migrating functions
                                  > and grow the architecture.
                                  >
                                  > > Is there any references on recommended design
                                  > practices in Scrum?
                                  >
                                  > Scrum doesn't pescribe engineering practices. Have a
                                  > look at
                                  >
                                  <http://www.agilealliance.org/programs/roadmaps/Roadmap/modeling/modeling_index.htm>
                                  > for some info on agile modelling.
                                  >
                                  > > Thank you.
                                  > >
                                  > > Happy Holiday
                                  > > Steven
                                  >
                                  > Same to you!
                                  >
                                  > --Hubert
                                  >

                                  Thank you for your advices, and Merry Chrismas.

                                  Steven




                                  __________________________________
                                  Do you Yahoo!?
                                  Yahoo! Mail - now with 250MB free storage. Learn more.
                                  http://info.mail.yahoo.com/mail_250
                                • Mike Dwyer
                                  Let me try to catch up with this. We are asking, I think, how to take an existing system (aka ugly old un-maintainable) and make it neat, new, and manageable.
                                  Message 16 of 25 , Jan 3, 2005
                                  • 0 Attachment
                                    Let me try to catch up with this.

                                    We are asking, I think, how to take an existing system (aka ugly old
                                    un-maintainable) and make it neat, new, and manageable.

                                    Since we do not have any usable documentation, just a bunch of stuff the
                                    users of the system rely on, there is no BDUF just a pile of stuff.

                                    Stories, cards, can all capture what users actually 'use' the system for. A
                                    cool thought comes to mind in having every user story also contain a
                                    demonstration of what the system currently does for them.
                                    This way you get a discriminator between what the system does and what the
                                    users want it to do.

                                    First pass make the new neat system do what it does but in the new, neat,
                                    maintainable and manageable way you want to build it.

                                    Then add in the stuff the users want it to do.

                                    Why go through all of this? First you begin the life of the new neat
                                    version with a solid combination of FDD TDD information. And a very simple
                                    unforgiving test process. Since you are building a system that delivers
                                    exactly what the old system does, you simply need to print off all of the
                                    output from the old system then use the same data to print off all of the
                                    output from the new system and then match them up on a light table. If all
                                    you see is a single output then you know the system produces exactly what
                                    the old one did. If not then you know it does not.

                                    Now using that you add stuff to the new system. Once you add the stuff then
                                    the once new system is now the old system and so on and so on.

                                    Just a thought.

                                    Michael F. Dwyer

                                    Mike.Dwyer1@...



                                    -----Original Message-----
                                    From: Ron Jeffries [mailto:ronjeffries@...]
                                    Sent: Thursday, December 23, 2004 1:15 PM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: Re: [scrumdevelopment] design practices


                                    On Thursday, December 23, 2004, at 12:38:02 PM, Steven Mak wrote:

                                    > hmm.... I am not sure if I can get your meaning
                                    > clearly (sorry for my limited English). I am not sure
                                    > if anything prevents us from completing an iteration.
                                    > But I am rather new in scrum and wondering if how
                                    > 'design' is dealt with, or any practices that I
                                    > overlooked to prevent spending the whole iteration on
                                    > 'design' but not delivering anything 'valuable'.

                                    I'm supposing that the program is made up of features, is it not?

                                    Then why not do what Scrum prescribes, and deliver one or more
                                    features /in the very first month/, and every month thereafter?

                                    And why not deploy those features, incrementally, one by one by one?

                                    What would prevent you from doing that?

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
                                    of his head. It is, as far as he knows, the only way of coming downstairs,
                                    but sometimes he feels that there really is another way, if only he could
                                    stop bumping for a moment and think of it. And then he feels that perhaps
                                    there isn't. -- A. A. Milne





                                    To Post a message, send it to: scrumdevelopment@...
                                    To Unsubscribe, send a blank message to:
                                    scrumdevelopment-unsubscribe@...
                                    Yahoo! Groups Links
                                  • Joel
                                    I have never managed a re-write project before, so perhaps my answer is naive, but here goes anyway. I disagree with some other respondents. I think that you
                                    Message 17 of 25 , Jan 4, 2005
                                    • 0 Attachment
                                      I have never managed a re-write project before, so perhaps my answer
                                      is naive, but here goes anyway.
                                      I disagree with some other respondents. I think that you need to
                                      modify some Scrum/Agile practices because some assumptions are not
                                      valid in this type of project. For example, one assumption of Agile
                                      is that you should prioritize the functionality because lower
                                      priority functionality 1)might never be needed or 2)might not make
                                      economic sense by the time we get to it or 3) the user might just
                                      change their mind, (or other variations of this theme). One drawback
                                      of waterfall is that it treats all functionality with equal
                                      priority. But, in this case, all functionality may be required. The
                                      user may not want a replacement system unless it has ALL previous
                                      functionality, hence the need for prioritization assumption is no
                                      longer valid.
                                      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.

                                      --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...>
                                      wrote:
                                      >
                                      > Hi all,
                                      >
                                      > I am going to have a new project soon and I am the project manager
                                      of
                                      > the project. I want to apply scrum practices with this project. My
                                      > knowledge in scrum is limited to this group, some online materials,
                                      > and a book. Thus, hope this gives me practical experiences in how my
                                      > development team more 'agile'.
                                      >
                                      > The project is about re-writing a system that has been using for
                                      > serveral years. It's so badly written that it has to be re-written
                                      so
                                      > as to have a easier life to maintain it.
                                      >
                                      > The first query is not about 'design'. Is traditional software
                                      > development works better when we have deep understanding about the
                                      > system? (eg. re-writing a system that we have been using for
                                      serveral
                                      > years) or I would like to know how agile methologies work better in
                                      a
                                      > not-so-emergent system development.
                                      >
                                      > The scope of the system is rather board, thus I believe it would
                                      take
                                      > quite a number of iterations before its functionalities can compare
                                      > with the existing system.
                                      >
                                      > I am wondering, with such a large system. How infrastruture and
                                      > software design is done in Scrum, while not falling into the BDUF
                                      > problem? Suppose it's a 4-week iteration. Would 'design' and
                                      > 'architecutral' work takes up more time in the first few iterations
                                      > than the later iterations, as it gets sufficiently-built for most
                                      > services on top of it?
                                      >
                                      > Is there any references on recommended design practices in Scrum?
                                      > Thank you.
                                      >
                                      > Happy Holiday
                                      > Steven
                                    • Ron Jeffries
                                      ... I d wager a week s pay that for any proposed ALL previous functionality project, I can find at least one chunk of functionality that they don t really
                                      Message 18 of 25 , Jan 4, 2005
                                      • 0 Attachment
                                        On Tuesday, January 4, 2005, at 10:30:01 PM, Joel wrote:

                                        > The
                                        > user may not want a replacement system unless it has ALL previous
                                        > functionality, hence the need for prioritization assumption is no
                                        > longer valid.

                                        I'd wager a week's pay that for any proposed "ALL previous
                                        functionality" project, I can find at least one chunk of
                                        functionality that they don't really want. Without mentioning price.
                                        If I can mention price, more.

                                        Ron Jeffries
                                        www.XProgramming.com
                                        What is your dream? And knowing this, what have you
                                        done to work towards realizing it today? -- Les Brown
                                      • Kristan Vingrys
                                        I think you missed one important point about the assumption of Agile and priority, The user might want the system before it is finished . In this case it
                                        Message 19 of 25 , Jan 4, 2005
                                        • 0 Attachment
                                          I think you missed one important point about the assumption of Agile and priority, "The user might want the system before it is finished". In this case it would still be worthwhile prioritising the features to be implemented and working to that priority so if the user does come back before the system is finished they can make up there mind taking it as is knowing that the highest priority features have been implemented.
                                           
                                          With emergent design my understanding is that you should not make assumptions about features that maybe needed and design to those. In the case you are describing you know what features are required, therefore they should be considered in your design. In my opinion Agile practices do not discourage upfront design, they discourage making up features (but in the future they may want to ....).
                                           
                                          Regards,
                                           
                                          Kristan
                                          -----Original Message-----
                                          From: Joel [mailto:jadams@...]
                                          Sent: Wednesday, 5 January 2005 2:30 PM
                                          To: scrumdevelopment@yahoogroups.com
                                          Subject: [scrumdevelopment] Re: design practices


                                          I have never managed a re-write project before, so perhaps my answer
                                          is naive, but here goes anyway.
                                          I disagree with some other respondents.  I think that you need to
                                          modify some Scrum/Agile practices because some assumptions are not
                                          valid in this type of project.  For example, one assumption of Agile
                                          is that you should prioritize the functionality because lower
                                          priority functionality 1)might never be needed or 2)might not make
                                          economic sense by the time we get to it or 3) the user might just
                                          change their mind, (or other variations of this theme).  One drawback
                                          of waterfall is that it treats all functionality with equal
                                          priority.  But, in this case, all functionality may be required.  The
                                          user may not want a replacement system unless it has ALL previous
                                          functionality, hence the need for prioritization assumption is no
                                          longer valid. 
                                          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.

                                          --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...>
                                          wrote:
                                          >
                                          > Hi all,
                                          >
                                          > I am going to have a new project soon and I am the project manager
                                          of
                                          > the project. I want to apply scrum practices with this project. My
                                          > knowledge in scrum is limited to this group, some online materials,
                                          > and a book. Thus, hope this gives me practical experiences in how my
                                          > development team more 'agile'.
                                          >
                                          > The project is about re-writing a system that has been using for
                                          > serveral years. It's so badly written that it has to be re-written
                                          so
                                          > as to have a easier life to maintain it.
                                          >
                                          > The first query is not about 'design'. Is traditional software
                                          > development works better when we have deep understanding about the
                                          > system? (eg. re-writing a system that we have been using for
                                          serveral
                                          > years) or I would like to know how agile methologies work better in
                                          a
                                          > not-so-emergent system development.
                                          >
                                          > The scope of the system is rather board, thus I believe it would
                                          take
                                          > quite a number of iterations before its functionalities can compare
                                          > with the existing system.
                                          >
                                          > I am wondering, with such a large system. How infrastruture and
                                          > software design is done in Scrum, while not falling into the BDUF
                                          > problem? Suppose it's a 4-week iteration. Would 'design' and
                                          > 'architecutral' work takes up more time in the first few iterations
                                          > than the later iterations, as it gets sufficiently-built for most
                                          > services on top of it?
                                          >
                                          > Is there any references on recommended design practices in Scrum?
                                          > Thank you.
                                          >
                                          > Happy Holiday
                                          > Steven





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


                                        • woynam
                                          The key sentence is that all the functionality *may* be needed. I ve seen plenty of features that were never used, but they simply *had* to be there. Often,
                                          Message 20 of 25 , Jan 5, 2005
                                          • 0 Attachment
                                            The key sentence is that all the functionality *may* be needed. I've
                                            seen plenty of features that were never used, but they simply *had* to
                                            be there. Often, there's no one who can tell you why a feature is
                                            needed, or why it was put there in the first place.

                                            I would start with the highest priority features first. At some point,
                                            the customer may decide that there's enough functionality to deploy
                                            into production. Worst case scenario, you rebuild all the features,
                                            which is basically were you might end up if you used a waterfall
                                            approach.

                                            Good case scenario, your customer decides that they can live with a
                                            subset of the features, and the system gets deployed into production
                                            eariler. You gain important feedback as you continue developing the
                                            remaining requested features.

                                            Best case scenario, the customer decides they *don't* need the
                                            remaining feqatures, but would rather you work on some *new* feature
                                            that will benefit the business. If you had taken the waterfall
                                            approach, your answer may be, "Sorry, we can't do that. We're 12
                                            months into a 18 month rewrite, and all we have is a bunch of design
                                            documents. We have to code and test the system first before we can
                                            begin to worry about changes." :-)

                                            Mark

                                            --- In scrumdevelopment@yahoogroups.com, "Joel" <jadams@d...> wrote:
                                            >
                                            > I have never managed a re-write project before, so perhaps my
                                            answer
                                            > is naive, but here goes anyway.
                                            > I disagree with some other respondents. I think that you need to
                                            > modify some Scrum/Agile practices because some assumptions are not
                                            > valid in this type of project. For example, one assumption of
                                            Agile
                                            > is that you should prioritize the functionality because lower
                                            > priority functionality 1)might never be needed or 2)might not make
                                            > economic sense by the time we get to it or 3) the user might just
                                            > change their mind, (or other variations of this theme). One
                                            drawback
                                            > of waterfall is that it treats all functionality with equal
                                            > priority. But, in this case, all functionality may be required.
                                            The
                                            > user may not want a replacement system unless it has ALL previous
                                            > functionality, hence the need for prioritization assumption is no
                                            > longer valid.
                                            > 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.
                                            >
                                            > --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...>
                                            > wrote:
                                            > >
                                            > > Hi all,
                                            > >
                                            > > I am going to have a new project soon and I am the project
                                            manager
                                            > of
                                            > > the project. I want to apply scrum practices with this project. My
                                            > > knowledge in scrum is limited to this group, some online
                                            materials,
                                            > > and a book. Thus, hope this gives me practical experiences in how
                                            my
                                            > > development team more 'agile'.
                                            > >
                                            > > The project is about re-writing a system that has been using for
                                            > > serveral years. It's so badly written that it has to be
                                            re-written
                                            > so
                                            > > as to have a easier life to maintain it.
                                            > >
                                            > > The first query is not about 'design'. Is traditional software
                                            > > development works better when we have deep understanding about the
                                            > > system? (eg. re-writing a system that we have been using for
                                            > serveral
                                            > > years) or I would like to know how agile methologies work better
                                            in
                                            > a
                                            > > not-so-emergent system development.
                                            > >
                                            > > The scope of the system is rather board, thus I believe it would
                                            > take
                                            > > quite a number of iterations before its functionalities can
                                            compare
                                            > > with the existing system.
                                            > >
                                            > > I am wondering, with such a large system. How infrastruture and
                                            > > software design is done in Scrum, while not falling into the BDUF
                                            > > problem? Suppose it's a 4-week iteration. Would 'design' and
                                            > > 'architecutral' work takes up more time in the first few
                                            iterations
                                            > > than the later iterations, as it gets sufficiently-built for most
                                            > > services on top of it?
                                            > >
                                            > > Is there any references on recommended design practices in Scrum?
                                            > > Thank you.
                                            > >
                                            > > Happy Holiday
                                            > > Steven
                                          • woynam
                                            Just a little background on my experience with rewrites. I ve been at my current position for 7+ years, and joined the company to work on a rewrite of our
                                            Message 21 of 25 , Jan 5, 2005
                                            • 0 Attachment
                                              'Just a little background on my experience with rewrites.

                                              I've been at my current position for 7+ years, and joined the company
                                              to work on a rewrite of our mainframe-based trading system that
                                              supported our open-outcry trading model.

                                              Less than a year into the project, the threat of fully electronic,
                                              screen-based trading became a reality with the announcement of the
                                              first new options exchange in 25 years, the ISE. We were soon directed
                                              to change gears and build a screen-based system.

                                              Shortly after completing and deploying version 1.0 of the system, the
                                              trading of single stock futures was authorized, and the fear was that
                                              a futures exchange could steal a lot of our business. Thus, we began
                                              developing a screen-based futures trading engine as part of a joint
                                              venture with 2 other exchanges. This new system was built using 90% of
                                              the major components of the new system.

                                              Shortly after completing and deploying the 2nd version of the system,
                                              the business decided that a hybrid trading model, combining the best
                                              of open-outcry and screen-based trading, would allow us to better
                                              compete with the fully electronic markets. Thus, we began working on a
                                              hybrid trading system that utilizes elements of the mainframe system,
                                              and well as our new trading platform. We deployed this version over a
                                              year ago.

                                              In a nutshell, the mainframe system is still there, and is used for a
                                              number of products that continue to trade open-outcry, as well as
                                              being part of the hybrid trading system. Had we focused exclusively on
                                              replicating the functionality of the original system, we would have
                                              built the wrong system, as the business did not stand still in the
                                              face of tough competition. Not only we some features not needed, they
                                              were completely eliminated with the new business model.

                                              By iteratively developing and deploying the system, we were able to
                                              deal with the unexpected course corrections that came our way.

                                              This is the ultimate value of agility.

                                              Mark


                                              --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@c...> wrote:
                                              >
                                              > The key sentence is that all the functionality *may* be needed. I've
                                              > seen plenty of features that were never used, but they simply *had* to
                                              > be there. Often, there's no one who can tell you why a feature is
                                              > needed, or why it was put there in the first place.
                                              >
                                              > I would start with the highest priority features first. At some point,
                                              > the customer may decide that there's enough functionality to deploy
                                              > into production. Worst case scenario, you rebuild all the features,
                                              > which is basically were you might end up if you used a waterfall
                                              > approach.
                                              >
                                              > Good case scenario, your customer decides that they can live with a
                                              > subset of the features, and the system gets deployed into production
                                              > eariler. You gain important feedback as you continue developing the
                                              > remaining requested features.
                                              >
                                              > Best case scenario, the customer decides they *don't* need the
                                              > remaining feqatures, but would rather you work on some *new* feature
                                              > that will benefit the business. If you had taken the waterfall
                                              > approach, your answer may be, "Sorry, we can't do that. We're 12
                                              > months into a 18 month rewrite, and all we have is a bunch of design
                                              > documents. We have to code and test the system first before we can
                                              > begin to worry about changes." :-)
                                              >
                                              > Mark
                                              >
                                              > --- In scrumdevelopment@yahoogroups.com, "Joel" <jadams@d...> wrote:
                                              > >
                                              > > I have never managed a re-write project before, so perhaps my
                                              > answer
                                              > > is naive, but here goes anyway.
                                              > > I disagree with some other respondents. I think that you need to
                                              > > modify some Scrum/Agile practices because some assumptions are not
                                              > > valid in this type of project. For example, one assumption of
                                              > Agile
                                              > > is that you should prioritize the functionality because lower
                                              > > priority functionality 1)might never be needed or 2)might not make
                                              > > economic sense by the time we get to it or 3) the user might just
                                              > > change their mind, (or other variations of this theme). One
                                              > drawback
                                              > > of waterfall is that it treats all functionality with equal
                                              > > priority. But, in this case, all functionality may be required.
                                              > The
                                              > > user may not want a replacement system unless it has ALL previous
                                              > > functionality, hence the need for prioritization assumption is no
                                              > > longer valid.
                                              > > 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.
                                              > >
                                              > > --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...>
                                              > > wrote:
                                              > > >
                                              > > > Hi all,
                                              > > >
                                              > > > I am going to have a new project soon and I am the project
                                              > manager
                                              > > of
                                              > > > the project. I want to apply scrum practices with this project. My
                                              > > > knowledge in scrum is limited to this group, some online
                                              > materials,
                                              > > > and a book. Thus, hope this gives me practical experiences in how
                                              > my
                                              > > > development team more 'agile'.
                                              > > >
                                              > > > The project is about re-writing a system that has been using for
                                              > > > serveral years. It's so badly written that it has to be
                                              > re-written
                                              > > so
                                              > > > as to have a easier life to maintain it.
                                              > > >
                                              > > > The first query is not about 'design'. Is traditional software
                                              > > > development works better when we have deep understanding about the
                                              > > > system? (eg. re-writing a system that we have been using for
                                              > > serveral
                                              > > > years) or I would like to know how agile methologies work better
                                              > in
                                              > > a
                                              > > > not-so-emergent system development.
                                              > > >
                                              > > > The scope of the system is rather board, thus I believe it would
                                              > > take
                                              > > > quite a number of iterations before its functionalities can
                                              > compare
                                              > > > with the existing system.
                                              > > >
                                              > > > I am wondering, with such a large system. How infrastruture and
                                              > > > software design is done in Scrum, while not falling into the BDUF
                                              > > > problem? Suppose it's a 4-week iteration. Would 'design' and
                                              > > > 'architecutral' work takes up more time in the first few
                                              > iterations
                                              > > > than the later iterations, as it gets sufficiently-built for most
                                              > > > services on top of it?
                                              > > >
                                              > > > Is there any references on recommended design practices in Scrum?
                                              > > > Thank you.
                                              > > >
                                              > > > Happy Holiday
                                              > > > Steven
                                            • 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 22 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 23 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 24 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 25 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.