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

Re: Purpose Driven Development - PDD

Expand Messages
  • jacek_ratzinger
    As described in Purpose Driven Development (http://jacekratzinger.blogspot.com/2012/01/purpose-driven-development-pdd.html) user topics are elaborated within
    Message 1 of 10 , Jan 16, 2012
    View Source
    • 0 Attachment
      As described in Purpose Driven Development (http://jacekratzinger.blogspot.com/2012/01/purpose-driven-development-pdd.html) user topics are elaborated within the iteration where they are implemented.

      Yes, software development is an iterative process, continuously refining to reach the best result. Therefore, user topics are not all and not entirely written up front.

      User topics are based on the ideas of DITA (Darwin Information Typing Architecture), where user documentation is composed of individual topics. They are (as much as possible) independent items that are assembled through topic maps. Thus, the technical documentation composed of topics also grows in the course of the development project.

      Jacek


      --- In testdrivendevelopment@yahoogroups.com, Al Chou <hotfusionman@...> wrote:
      >
      > The first edition of _Code Complete_ advocated this documentation-first development style. I think it suffers from the same problem as BDUF: it's not possible to fully know at the beginning how the software should be.
      >
      > Al
      >
      >
      > On Jan 13, 2012, at 12:42, "jacek_ratzinger" <ratzinger.jacek@...> wrote:
      >
      > > Hi Kim,
      > >
      > > Thank you for the book recommendation.
      > >
      > > Indeed there are several things in common, but there are also differences in the basic idea.
      > >
      > > Already form start (from the title) this book talks about "Specification". From this specifications the living documentation is derived as end-product.
      > >
      > > With Purpose Driven Development the journey starts from the "end-product". The first step is a user topic (a piece of the user manual). From this the specification is derived.
      > > In other words we abuse the user manual to become the specification :-)
      > >
      > > Greets, Jacek
      > >
      > >
      > > --- In testdrivendevelopment@yahoogroups.com, Kim Gräsman <kim.grasman@> wrote:
      > >>
      > >> Hi Jacek,
      > >>
      > >> On Thu, Jan 12, 2012 at 19:59, jacek_ratzinger
      > >> <ratzinger.jacek@> wrote:
      > >>>
      > >>> * test = documentation
      > >>> Thus, tests and documentation seem to have much in common. In my
      > >>> opinion, especially user manuals can be well combined with test
      > >>> automation. I call this process Purpose Driven Development
      > >>
      > >> This sounds a lot like Gojko Adzic's Specification By Example, but he
      > >> puts much more emphasis on the collaboration aspects of it;
      > >> http://www.specificationbyexample.com/key_ideas.html
      > >>
      > >> I'm midway through his book now, and I can definitely recommend it.
      > >>
      > >> - Kim
      > >>
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      >
    • jacek_ratzinger
      One section of the blog on PDD (http://jacekratzinger.blogspot.com/2012/01/purpose-driven-development-pdd.html) is called The Executable Documentation . User
      Message 2 of 10 , Jan 16, 2012
      View Source
      • 0 Attachment
        One section of the blog on PDD (http://jacekratzinger.blogspot.com/2012/01/purpose-driven-development-pdd.html) is called "The Executable Documentation".

        User topics are instrumented with the help of tools such as the Concordion framework (http://www.concordion.org) to be directly part of automated tests. Thus, the user manual itself is the environment for the test automation and as such executable to stay up to date.

        When you want to change the expected behavior of our code, you change the user manual first, instrument it for testing, and implement the code that suffices the user topic afterwards.
        -> user document a little, test a little, code a little, ...

        Jacek



        --- In testdrivendevelopment@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
        >
        > I think the living documentation *is* the specification in this book. Not
        > only does the living documentation represent the "requirement", it is also
        > executable. This makes it the ideal specification because it can always
        > tell you deterministically whether it is currently met or not - just ask it
        > to run itself.
        >
        > Users generally cannot read code, so the user manual will inevitably not be
        > executable and therefore whether or not it is actually true will always be
        > subjective.
        >
        > SteveG
        >
        > On Fri, Jan 13, 2012 at 1:42 PM, jacek_ratzinger
        > <ratzinger.jacek@...>wrote:
        >
        > > **
        > >
        > >
        > > Hi Kim,
        > >
        > > Thank you for the book recommendation.
        > >
        > > Indeed there are several things in common, but there are also differences
        > > in the basic idea.
        > >
        > > Already form start (from the title) this book talks about "Specification".
        > > From this specifications the living documentation is derived as end-product.
        > >
        > > With Purpose Driven Development the journey starts from the "end-product".
        > > The first step is a user topic (a piece of the user manual). From this the
        > > specification is derived.
        > > In other words we abuse the user manual to become the specification :-)
        > >
        > > Greets, Jacek
        > >
        > > --- In testdrivendevelopment@yahoogroups.com, Kim Gräsman <kim.grasman@>
        > > wrote:
        > > >
        > > > Hi Jacek,
        > > >
        > > > On Thu, Jan 12, 2012 at 19:59, jacek_ratzinger
        > > > <ratzinger.jacek@> wrote:
        > > > >
        > > > > * test = documentation
        > > > > Thus, tests and documentation seem to have much in common. In my
        > > > > opinion, especially user manuals can be well combined with test
        > > > > automation. I call this process Purpose Driven Development
        > > >
        > > > This sounds a lot like Gojko Adzic's Specification By Example, but he
        > > > puts much more emphasis on the collaboration aspects of it;
        > > > http://www.specificationbyexample.com/key_ideas.html
        > > >
        > > > I'm midway through his book now, and I can definitely recommend it.
        > > >
        > > > - Kim
        > > >
        > >
        > >
        > >
        >
        >
        > [Non-text portions of this message have been removed]
        >
      • jacek_ratzinger
        One of the sections of PDD is called The Executable Documentation . User topics - the elements of the user documentation - are instrumented and directly used
        Message 3 of 10 , Jan 20, 2012
        View Source
        • 0 Attachment
          One of the sections of PDD is called "The Executable Documentation".
          User topics - the elements of the user documentation - are instrumented and directly used as input to automated tests. For example the Concordion Framework (http://www.concordion.org/) provides a technical foundation for such an executable documentation.

          As a result the documentation is always in sync with the implementation (e.g. when used with a continuous integration system).

          Greets, Jacek

          --- In testdrivendevelopment@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
          >
          > I think the living documentation *is* the specification in this book. Not
          > only does the living documentation represent the "requirement", it is also
          > executable. This makes it the ideal specification because it can always
          > tell you deterministically whether it is currently met or not - just ask it
          > to run itself.
          >
          > Users generally cannot read code, so the user manual will inevitably not be
          > executable and therefore whether or not it is actually true will always be
          > subjective.
          >
          > SteveG
          >
          > On Fri, Jan 13, 2012 at 1:42 PM, jacek_ratzinger
          > <ratzinger.jacek@...>wrote:
          >
          > > **
          > >
          > >
          > > Hi Kim,
          > >
          > > Thank you for the book recommendation.
          > >
          > > Indeed there are several things in common, but there are also differences
          > > in the basic idea.
          > >
          > > Already form start (from the title) this book talks about "Specification".
          > > From this specifications the living documentation is derived as end-product.
          > >
          > > With Purpose Driven Development the journey starts from the "end-product".
          > > The first step is a user topic (a piece of the user manual). From this the
          > > specification is derived.
          > > In other words we abuse the user manual to become the specification :-)
          > >
          > > Greets, Jacek
          > >
          > > --- In testdrivendevelopment@yahoogroups.com, Kim Gräsman <kim.grasman@>
          > > wrote:
          > > >
          > > > Hi Jacek,
          > > >
          > > > On Thu, Jan 12, 2012 at 19:59, jacek_ratzinger
          > > > <ratzinger.jacek@> wrote:
          > > > >
          > > > > * test = documentation
          > > > > Thus, tests and documentation seem to have much in common. In my
          > > > > opinion, especially user manuals can be well combined with test
          > > > > automation. I call this process Purpose Driven Development
          > > >
          > > > This sounds a lot like Gojko Adzic's Specification By Example, but he
          > > > puts much more emphasis on the collaboration aspects of it;
          > > > http://www.specificationbyexample.com/key_ideas.html
          > > >
          > > > I'm midway through his book now, and I can definitely recommend it.
          > > >
          > > > - Kim
          > > >
          > >
          > >
          > >
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • jacek_ratzinger
          Yes, I agree with you that it makes a difference how we look at specifications. Therefore, the first step of PDD is to develop the next piece of the user
          Message 4 of 10 , Jan 20, 2012
          View Source
          • 0 Attachment
            Yes, I agree with you that it makes a difference how we look at specifications. Therefore, the first step of PDD is to develop the next piece of the user manual (as a special format of specification), then use it for test automation, and finally write the code to satisfy the user manual.

            While working with PDD, I realized that this form of specifications (i.e. the user topics of PDD: http://jacekratzinger.blogspot.com/) help to initially focus on the purpose for the user - to take the user perspective - before thinking about technical features.

            Greets, Jacek


            --- In testdrivendevelopment@yahoogroups.com, Charlie Poole <charliepoole@...> wrote:
            >
            > There is always a problem with the word "specification" since it means many
            > things to different people. On top of the dictionary meaning there are layers
            > and layers of connotations / associations with the word.
            >
            > For example, I personally can't hear the word without imagining something
            > top-down and unchangeable, because of years of dealing with things
            > called "specifications" that had those characteristics. Consequently, I rarely
            > use the word myself and I have to be very careful to ask folks just what
            > they mean when they use it - as when I'm speaking with someone who
            > is more recently in our trade and does not have those associations.
            >
            > It makes conversation hard, of course. :-)
            >
            > Charlie
            >
            > On Fri, Jan 13, 2012 at 1:32 PM, Steven Gordon <sgordonphd@...> wrote:
            > > I think the living documentation *is* the specification in this book.  Not
            > > only does the living documentation represent the "requirement", it is also
            > > executable.  This makes it the ideal specification because it can always
            > > tell you deterministically whether it is currently met or not - just ask it
            > > to run itself.
            > >
            > > Users generally cannot read code, so the user manual will inevitably not be
            > > executable and therefore whether or not it is actually true will always be
            > > subjective.
            > >
            > > SteveG
            > >
            > > On Fri, Jan 13, 2012 at 1:42 PM, jacek_ratzinger
            > > <ratzinger.jacek@...>wrote:
            > >
            > >> **
            > >>
            > >>
            > >> Hi Kim,
            > >>
            > >> Thank you for the book recommendation.
            > >>
            > >> Indeed there are several things in common, but there are also differences
            > >> in the basic idea.
            > >>
            > >> Already form start (from the title) this book talks about "Specification".
            > >> From this specifications the living documentation is derived as end-product.
            > >>
            > >> With Purpose Driven Development the journey starts from the "end-product".
            > >> The first step is a user topic (a piece of the user manual). From this the
            > >> specification is derived.
            > >> In other words we abuse the user manual to become the specification :-)
            > >>
            > >> Greets, Jacek
            > >>
            > >> --- In testdrivendevelopment@yahoogroups.com, Kim Gräsman <kim.grasman@>
            > >> wrote:
            > >> >
            > >> > Hi Jacek,
            > >> >
            > >> > On Thu, Jan 12, 2012 at 19:59, jacek_ratzinger
            > >> > <ratzinger.jacek@> wrote:
            > >> > >
            > >> > >    * test = documentation
            > >> > > Thus, tests and documentation seem to have much in common. In my
            > >> > > opinion, especially user manuals can be well combined with test
            > >> > > automation. I call this process Purpose Driven Development
            > >> >
            > >> > This sounds a lot like Gojko Adzic's Specification By Example, but he
            > >> > puts much more emphasis on the collaboration aspects of it;
            > >> > http://www.specificationbyexample.com/key_ideas.html
            > >> >
            > >> > I'm midway through his book now, and I can definitely recommend it.
            > >> >
            > >> > - Kim
            > >> >
            > >>
            > >>
            > >>
            > >
            > >
            > > [Non-text portions of this message have been removed]
            > >
            > >
            > >
            > > ------------------------------------
            > >
            > > Yahoo! Groups Links
            > >
            > >
            > >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.