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

Re: [agile-usability] Re: Today's article on UseIt.com

Expand Messages
  • John Schrag
    ... I think you do it by embracing the Agile idea of refactoring . The problem has an exact engineering equivalent: how do you build a software app
    Message 1 of 76 , Nov 21, 2008
      Bonnie wrote:
      > Long-term architectural and UX consistency are concerns
      > that have been raised by CTOs and technical advisors I've worked with
      > - how do you embrace change while ensuring you're not producing an
      > inconsistent patchwork of features?

      I think you do it by embracing the Agile idea of "refactoring".  The problem has an exact engineering equivalent:  how do you build a software app incrementally without the architecture ending up as an inconsistent patchwork of modules?  (And, as a former programmer, I can tell you a lot of software ends up that way.)

      In other discussions on this topic, I've seen opponents of Agile proposing that unless you design everything up front, you won't have a consistent big picture.  I think that's a red herring --- if you *do* try to design everything up-front, you may have a consistent big picture, but it will almost certainly be the wrong big picture one.  How is that better?  One of the prime  advantages of Agile is making sure you don't commit to something big before you have all the information you need to do it right.

      In the last five years or so of working Agile, I've tended to work out a very loosely-sketched big picture in cycle 0, as well as doing a lot of the basic research.  As cycles go on, and we learn more, the basic research documents are updated incrementally  (my team keeps them in a wiki).  And as new features are designed, we always look at the environment of other features around.  Does the big picture still make sense?  Do we need to change some of the other features or design to make the new feature fit properly?  Can we remove old features, or combine several together into a single, more powerful feature?

      Agile engineers do this kind of thing all the time with the code, and call it "refactoring". I find using the same term for it helps the development team understand what you're up to.  *Not* refactoring tends to lead to redundant features and feature creep in general.

      -john schrag
    • Desilets, Alain
      ... that ... one ... http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivit y- ...
      Message 76 of 76 , Jan 9, 2009
        > > There are other studies (I don't have the exact quote) that show
        > > the difference between a top-notch developer and a run-of-the-mill
        > > is a factor of 10 or so.
        > The back up for that is here :-

        Thx James. I always assumed that this was indeed supported by actual
        studies, but still had a small nagging doubt that it might be one of
        those urban legends that start with "studies show that ...." ;-). This
        is a good reference which eliminates that doubt.

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