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

Re: People, roles, and traits

Expand Messages
  • Andrew Lawrence
    Having worked with Jeff before, I had to make sure he wasn t referring to me with the phrase letting their code rot into an unmaintainable mass . He assures
    Message 1 of 28 , Aug 27 10:04 AM
    • 0 Attachment
      Having worked with Jeff before, I had to make sure he wasn't
      referring to me with the phrase "letting their code rot into
      an unmaintainable mass". He assures me he wasn't. :-)

      He did ask me to post a concept that both he and I sort of
      fell into in our years of designing.

      "Content" vs. "Application".

      In the software I have developed, we have often tried to
      stick to a "base application" code. This is where the
      architecture minded people flex their muscle. It is optimized,
      tight, and well-factored code that is the core of the entire
      application. Generally it is released on its own schedule,
      with numerous automated test cases against it. It could be
      considered the "foundation" or "framework" of the application
      as a whole.

      Then there is "content". This becomes code that relies
      on the foundation, or more importantly, the interface of
      the foundation, but then allows the "UI minded" people
      to flex their muscles to push the final application into
      something the user enjoys using.

      For the most part, this separation seems to calm the usual
      thrashing of architecture vs. UI. There is still the need
      for the foundation architects to pay attention to what
      the content folks are doing. If the content people are
      always having to work around certain aspects of the
      foundation, then the foundation needs to be adapted. It's
      a continual process through the length of the project.

      So much for lurking... now I'm into the fire.

      -- Andrew Lawrence
      andrew9990@...


      --- In agile-usability@yahoogroups.com, Philip Borlin <pborlin@c...>
      wrote:
      > Jeff Patton wrote:
      >
      > >I wonder if most developers see it the way you do? I've met a few
      > >that are the opposite - letting their code rot into an
      unmaintainable
      > >mass while they focus on the quality of the user experience. The
      > >people I'm thinking of started by doing html web page development
      and
      > >eventually moved to JSPs, then Java. They just came from a place
      > >where the look and feel of things mattered most, and have a hard
      time
      > >unsticking their heads from that place.
      > >
      > >
      >
      > But you need both architecture minded and UI minded people on your
      > project. The architect will push the code in the direction of
      > simplicity and elegance and the UI designer will push the UI into
      > something that the user enjoys using. Between the pushing of these
      two
      > parties compromises will unfold and the hope is to get the best of
      both
      > worlds.
      >
      > -Phil
    • Hugh R. Beyer
      [Andrew] In the software I have developed, we have often tried to stick to a base application code. This is where the architecture minded people flex their
      Message 2 of 28 , Aug 28 8:17 AM
      • 0 Attachment
        Message
         [Andrew] In the software I have developed, we have often tried to
        stick to a "base application" code.  This is where the
        architecture minded people flex their muscle.  It is optimized,
        tight, and well-factored code that is the core of the entire
        application.  Generally it is released on its own schedule,
        with numerous automated test cases against it.  It could be
        considered the "foundation" or "framework" of the application
        as a whole. 
         But how do you prevent what I've seen many times--which is where the "foundation" group decides to build the best and most bullet-proof architecture there ever was, and spends months working on it, overrunning deadline after deadline, producing baselevels which are unusable for one reason or another (often performance) until finally some other group does something quick to get their own project out the door--at which point they are declared the new "tactical" foundation and the architecure group is cancelled?
         
            Hugh
         
      • Andrew Lawrence
        ... Very interesting... come to think of it, the other group you mention is the exact situation I have been placed in, not once, but twice within the same
        Message 3 of 28 , Aug 28 11:21 AM
        • 0 Attachment
          --- In agile-usability@yahoogroups.com, "Hugh R. Beyer" <beyer@i...>
          wrote:
          > But how do you prevent what I've seen many times--which is where
          > the "foundation" group decides to build the best and most
          > bullet-proof architecture there ever was, and spends months working
          > on it, overrunning deadline after deadline, producing baselevels
          > which are unusable for one reason or another (often performance)
          > until finally some other group does something quick to get their
          > own project out the door--at which point they are declared the new
          > "tactical" foundation and the architecure group is cancelled?

          Very interesting... come to think of it, the "other group" you
          mention is the exact situation I have been placed in, not once,
          but twice within the same company!

          I guess I should clarify. The projects I have been involved with
          have never started out with a separation of application and content
          teams. Initially they are always the same group, and usually only
          a few people. The group has to build something to meet a deadline.

          But I have always tried, while within that group, to be able to
          wear the two different hats. Sometimes you can separate the
          application and content as you are going, other times you just have
          to keep it in mind and then come back to it later. This is where
          agile methods come into play. Iteration planning and a good view
          of priorities (what has to be done, and what can drop off) are
          essential.

          The result, is that after the initial deadline has passed, you are
          left with code that is very flexible for the next round -- which
          there always seems to be another round. Alistair Cockburn's book
          on Agile Software Development talks about software as a game -
          where a project usually has two goals: 1) deliver the software,
          and 2) create an advantageous position for the next game.

          So in essence, I don't think an intial stab at "let's take 3-6
          months to build a good foundation" ever works. You have to build
          an application front to back to meet a deadline. But you have to
          keep in mind the separation of "application" and "content" since
          it will make future life that much easier.

          -- Andrew
        • Cecilia Haskins
          ... ... working ... new ... agreed -- this is the place where finacial or other resource constraints usually drive what is and is not a good
          Message 4 of 28 , Aug 29 7:05 AM
          • 0 Attachment
            --- In agile-usability@yahoogroups.com, "Andrew Lawrence"
            <andrew9990@y...> wrote:
            > --- In agile-usability@yahoogroups.com, "Hugh R. Beyer"
            <beyer@i...>
            > wrote:
            > > But how do you prevent what I've seen many times--which is where
            > > the "foundation" group decides to build the best and most
            > > bullet-proof architecture there ever was, and spends months
            working
            > > on it, overrunning deadline after deadline, producing baselevels
            > > which are unusable for one reason or another (often performance)
            > > until finally some other group does something quick to get their
            > > own project out the door--at which point they are declared the
            new
            > > "tactical" foundation and the architecure group is cancelled?
            >
            > Very interesting... come to think of it, the "other group" you
            > mention is the exact situation I have been placed in, not once,
            > but twice within the same company!
            >
            > I guess I should clarify. The projects I have been involved with
            > have never started out with a separation of application and content
            > teams. Initially they are always the same group, and usually only
            > a few people. The group has to build something to meet a deadline.
            >
            > But I have always tried, while within that group, to be able to
            > wear the two different hats. Sometimes you can separate the
            > application and content as you are going, other times you just have
            > to keep it in mind and then come back to it later. This is where
            > agile methods come into play. Iteration planning and a good view
            > of priorities (what has to be done, and what can drop off) are
            > essential.
            >
            > The result, is that after the initial deadline has passed, you are
            > left with code that is very flexible for the next round -- which
            > there always seems to be another round. Alistair Cockburn's book
            > on Agile Software Development talks about software as a game -
            > where a project usually has two goals: 1) deliver the software,
            > and 2) create an advantageous position for the next game.
            >
            > So in essence, I don't think an intial stab at "let's take 3-6
            > months to build a good foundation" ever works. You have to build
            > an application front to back to meet a deadline. But you have to
            > keep in mind the separation of "application" and "content" since
            > it will make future life that much easier.
            >
            > -- Andrew

            agreed -- this is the place where finacial or other resource
            constraints usually drive what is and is not a good practice. Cecilia
          Your message has been successfully submitted and would be delivered to recipients shortly.