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

6528Re: [scrumdevelopment] Completeness definition

Expand Messages
  • Chris Brooks
    Mar 3, 2005
    • 0 Attachment
      On Thu, 3 Mar 2005 19:55:23 +0100, David H. <dmalloc@...> wrote:
      > > > >
      > > > > This is the sort of stuff I can live with and makes sense. I *have*
      > > > > wondered about the "Code has been refactored" requirement. What if
      > > > > code is well factored to start with? Do we always need to refactor?
      > > > >
      > > > Refactoring is a big part of Scrum and test driven development in my
      > >
      > > Scrum defines no engineering practices. That is not to say that
      > > refactoring or TDD isn't important, it is just not part of Scrum.
      > >
      > I beg to differ. But I guess that is purely philosohpical. To me it is
      > part of Scrum because scrum does define a methodology that leads to
      > certain processes. Maybe one could argue that it is more part of test
      > driven development than scrum. But then again, who cares :)

      I should clarify my original comment. Fowler's definition of
      refactoring is "the process of changing a software system in such a
      way that it does not alter the external behavior of the code yet
      improves its internal structure."

      My issue was with this statement as a suggested criteria for
      completness: "Code has been refactored". Refactoring describes a
      process, not an end state. I would rather make the criteria something
      like "Code is well factored" and describe a desirable state. To
      suggest that all new code written must be refactored is a bit strong,
      IMHO. Certainly there are cases were the initial implementation of
      software is reasonably well factored.

      Chris Brooks
    • Show all 15 messages in this topic