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

Purpose Driven Development - starting at the end

Expand Messages
  • jacek_ratzinger
    Purpose Driven Development: http://jacekratzinger.blogspot.com/ My first kanban board had the following columns: ToDo, In Process, To Verify, To Document, Done
    Message 1 of 41 , Jan 21, 2012
    • 0 Attachment
      Purpose Driven Development: http://jacekratzinger.blogspot.com/

      My first kanban board had the following columns:
      ToDo, In Process, To Verify, To Document, Done
      With such a waterfall process, isn't it always happening that testing and documentation fall short, when time runs out close to a deadline?

      TDD tries to move at least the testing more to the front of the process, to prevent the quality creep. Excited of this principle, I started to focus in projects on the result first. This lead to the idea to start with my last column of my kanban board: to document.

      In PDD (http://jacekratzinger.blogspot.com/) the user topic (a piece of the user manual) is written first before the testing (using this user topic directly as input) and the coding.

      Have you ever experienced that focusing first on the user and the purpose the software for the user lead you to a better design?

      Greest,Jacek
    • Charlie Poole
      Hi Jacek, On Fri, Jan 27, 2012 at 12:30 AM, jacek_ratzinger wrote: ... One must always worry about meaning of terms
      Message 41 of 41 , Jan 27, 2012
      • 0 Attachment
        Hi Jacek,

        On Fri, Jan 27, 2012 at 12:30 AM, jacek_ratzinger
        <ratzinger.jacek@...> wrote:
        <snip>
        > Perhaps "user documentation" has negative connotations such as the term "specification" for Charlie Poole (http://tech.groups.yahoo.com/group/testdrivendevelopment/message/34964).
        > What is a better term for the information you would like to find, when you are looking for a new application?
        </snip>

        One must always worry about meaning of terms as it is perceived by the
        audience. In our field, meanings
        can change every five years or so, so much of your audience already
        has established meanings for
        terms if you re-use a term from "old times" in a new way.

        This is made more difficult by the fact that things change at
        different rates in different places - i.e.
        different countries, different companies, different teams - so usage
        is not always common.

        In the 80s (I could go back further, but why bother) a "specification"
        was clearly something very
        finished, very formal and very unchangeable - at least not changed
        without going through a
        very large formal process. But "in the 80s" is not quite correct, as
        there are companies using
        "specifications" in this way right now.

        Similarly, a "user manual" (not quite the same as "user
        documentation") was similar to a
        specification, but more oriented to those things a user would see. The
        technique of writing
        the user manual first was put out (for the first time AFAIK) in that
        same decade. The idea
        (back then) was to create a very finished document, complete with
        illustrations, so that
        programmers could work toward software that matched the manual.

        In the late 90s, I spent some time in a group at Microsoft and saw
        "specifications" that were
        very much like user manuals. That is, artists worked carefully to
        create the desired appearance
        and writers specified the exact steps that users should follow when
        using the app. These
        specs were sometimes changed, but not lightly. I guess part of the
        reason was that a lot
        of effort went into producing them.

        In all those past examples, what I see operating is a desire to make
        it *unnecessary* for
        the programmer to give much thought to the purpose of the application.
        Specs were
        written by analysts or program managers. Manuals were created by
        artists and technical
        writers. Programmers just programmed.

        Of course, I see that is not what you are trying to do. You don't want
        to diminish the
        understanding of the programmers but to increase it. But if you use
        terms that have
        been associated with the "dumbing down" of the programmer's craft in
        the past, you
        shouldn't be surprised if at least some folks make that association.

        I think "purpose" is a good term. I've seen too many teams who do NOT understand
        the purpose of what they do. For example, I've seen teams with very
        poor understanding
        of how the company they work in makes its money. Naturally, such
        programmers need
        to be given very precise instructions (e.g. a manual) because they
        don't have the
        background to make intelligent decisions. It seems obvious to me, however, that
        the better course is to educate them in the real purpose of what they
        are doing and
        how it will be used. A "user manual" - at least as the term is
        normally used - would
        only scratch the surface of such ignorance.

        For me, it's not so much that terms have a _*negative* connotation as that they
        may have an association that runs contrary to your overall aims.

        How about "user story"? Do you have some association with that term that makes
        you prefer "user manual"?

        Charlie
      Your message has been successfully submitted and would be delivered to recipients shortly.