Tom Fulton wrote:
Here is a specific example, on which I was called by a "Certified Scrum Master". I noticed in a group of classes that some code was doing type-specific functionality in an if/else kind of structure, and observed that it was an opportunity to use the Template Method pattern to allow the subclasses to "do their thing". The overall structure was defined at the superclass level, and each subclass had the ability to perform one or more steps in the algorithm according to their type. It was, to me, a classic case of using a Design Pattern to clean up an obviously bad structure in the first place, and to provide a good basis for future changes...and I think of Design Patterns as kind of "tactical" design tools, as opposed to "strategic" design decisions. I estimated that it would take about an hour to code and maybe half that to test. Anyway, the Scrum Master made it very clear that we should not do anything that was not specifically called for as part of a deliverable, and that the definition of the deliverable was to be viewed as that of functionality, not (as he put it) "nice to haves".
Tom Fulton wrote:Thanks for your reply, Tim. I have to ask what you mean by "design debt", however. The seems to be used in the sense of "the need to redesign/refactor", but how does the design debt become incurred? Or am I misunderstanding the term?