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

Re: [XP] Tool to compute Technical Debt as a Percentage and a Dollar amount

Expand Messages
  • Steven Gordon
    ... Of course, everything always depends. ... And there is a lot of grey area in between, depending on how much technical debt the project has accumulated. ...
    Message 1 of 7 , Mar 31, 2010
    • 0 Attachment
      On Wed, Mar 31, 2010 at 1:35 AM, thierry henrio <thierry.henrio@...>wrote:

      >
      >
      > Hello Steve
      >
      >
      > On Wed, Mar 31, 2010 at 3:56 AM, Steven Gordon <sgordonphd@...<sgordonphd%40gmail.com>>
      > wrote:
      >
      > >
      > > I like to use the term duplicative instead of duplicated. Duplicative
      > code
      > > is rarely 100% identical, just very similar.
      > >
      > You right
      >
      >
      > > Figuring out what small transformations to make to one or both pieces of
      > > code in order to create some exactly identical piece(s) that can be
      > > extracted into shared methods via automated refactorings, as well as
      > > writing
      > > unit tests for those extracted methods and verifying that nothing was
      > > broken
      > > in the process could easily take 2 hours.
      > >
      >
      > It depends ?
      >

      Of course, everything always depends.


      > You see 2 duplicative blocks in a clean code file, you move a few
      > statements
      > so that automated refactoring succeeds, and existing tests tell you the
      > tale
      > : 5 mins
      > You see 2 duplicative blocks in a legacy code file...
      > Write characterization tests : 8 hours, and duplication is still there
      > (serious)
      >

      And there is a lot of grey area in between, depending on how much technical
      debt the project has accumulated.


      >
      > Now I value a simple cost model, because I can understand it
      > Then, I support it, till I have more knowledge to propose better
      >

      Maybe the cost model should have variable instead of fixed costs, so the
      project team can substitute their best guesses based on the state of the
      project and can update those costs as the state of the project changes
      (hopefully, improves giving lower costs).

      SteveG


      >
      > Regards, Thierry
      >
      >
      >


      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.