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

Re: When does presentation layer come in?

Expand Messages
  • aacockburn
    I m sorry, the logic was too broken in that post for me to attempt a response. I stand by what I wrote. Alistair ... change both ... for other ... will not ...
    Message 1 of 283 , Jul 31, 2008
    • 0 Attachment
      I'm sorry, the logic was too broken in that post for me to attempt a
      response. I stand by what I wrote.

      Alistair

      --- In agile-usability@yahoogroups.com, "James Page" <jamespage@...>
      wrote:
      >
      > >
      > > .. it's a lot faster to change directions if you don't have to
      change both
      > > the visuals and the application
      > > logic.
      >
      >
      > Why? When you are building an api you are building a set of rules
      for other
      > components to talk to your component. Rules are hard to change.
      >
      > If you are just building an API then you are stuck in a cave and
      will not
      > realize that you need to change. You will have missed some great
      inputs
      > which is the real interaction of the visuals against the API, and
      feedback
      > from real users.
      >
      > Also there is no such thing as the perfect API. As you build the
      visuals you
      > will have to write clunky code to get around the non-flexibility of
      your API
      > for the issues that you did not have foresight for. Allot of
      programers
      > productivity is spent getting around clunky API's (I know my time
      has).
      >
      > There is an old rule from NASA that for every bug not caught while
      the code
      > is been written ten times more effort is required to fix it if
      caught during
      > the testing stage, and hundred times more if caught after release.
      Without
      > having working software then how do you test properly? How do test
      in front
      > of real users?
      >
      > How do you know if you need to change, without having some form of
      working
      > software?
      >
      > ethnography style ... I would expeect field data to be welcome.)
      >
      >
      > How do you get field data on a API? Spirits :)
      >
      > James
      >
      > On Thu, Jul 31, 2008 at 4:13 PM, aacockburn <acockburn@...> wrote:
      >
      > > --- In agile-usability@yahoogroups.com<agile-usability%
      40yahoogroups.com>,
      > > "James Page" <jamespage@>
      > > wrote:
      > >
      > > >
      > > > If you take the meaning of Agile then it means been able to
      > > > change fast in a graceful manner. There is nothing stopping
      > > > you having beautiful screen designs at the start if that does
      > > > not impede you from throwing them away and starting again.
      > > > Agile is about dealing with the most pressing *real* issues
      > > > first.
      > > >
      > > > The test if something is Agile or not: is how fast it is to
      > > > change direction.
      > >
      > > I'll bite that bait ... it's a lot faster to change directions if
      > > you don't have to change both the visuals and the application
      > > logic.
      > >
      > > Alistair
      > >
      > >
      > >
      >
    • George Dinwiddie
      ... William, why do you say apparently not? Is not the text appearing on the screen part of working software no matter whether the text is compiled into
      Message 283 of 283 , Aug 21, 2008
      • 0 Attachment
        William Pietri wrote:
        > The team decides the highest priority is to fix that. So the whole team
        > spends the week rummaging through the content management system,
        > rewriting copy, changing labels, clarifying wording, and so on. Not a
        > line of code is written; no software is produced.
        >
        > Upon release, key metrics improve significantly. Users are happier,
        > signups are more frequent, retention goes up. Millions of extra dollars
        > will be made over the next year. By external measures, it is the most
        > useful week of work all year.
        >
        > Would the business call that a week with progress? Yes. Would the team
        > call that progress? Yes. Would that Agile Manifesto? Apparently not.

        William, why do you say "apparently not?"

        Is not the text appearing on the screen part of "working software" no
        matter whether the text is compiled into the object code or read out of
        some data store?

        Is this not an example of "satisfy[ing] the customer through early and
        continuous delivery of valuable software?"

        Is this not a case of "deliver[ing] working software frequently?"

        Is this not an example of "business people and developers [working]
        together daily?"

        Is this not an excellent example of a "team reflect[ing] on how to
        become more effective, then tun[ing] and adjust[ing] its behavior
        accordingly?"

        Your other example, where "eventually, after many months of work, they
        decide they can release," seems to violate several principles,
        particularly, "Agile processes promote sustainable development. The
        sponsors, developers, and users should be able to maintain a constant
        pace indefinitely."

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      Your message has been successfully submitted and would be delivered to recipients shortly.