Re: agile development and frameworks

Mike Gaab wrote:

>>Just don't write more code than the current iteration's features need.
>
> Easier said than done. This is contrary to what I have been taught.
> I have been taught to anticipate change by using a particular technique or
> pattern. It places me so far outside of my comfort zone that I think
> I am going to miss something. But when I consider implementing
> each feature set (story) in this manner I won't miss a thing. I will get
> exactly what the client and the team has asked for nothing more.
> What will be /missed/ is a bunch of structures that have been included
> to anticipate what the client might ask for next.

When you design the code for this iteration, you can't anticipate its future
extensions?

If the code will extend the same way it extends in this iteration, then
removing duplication (with an eye towards the anticipated design), you can
generally introduce abstractions that make the code easy to extend into this
iteration's features. So the next iteration's will be easy.

However, in the next iteration, the code may extend in a completely
different way. The best way to account for your time to your customer is to
_not_ charge for time, during this iteration, for those future extensions.
Your goal is to increase your customer's options in each iteration. Remove
code and features you don't need now, and if you must architect something
then architect the negative space between your structures.

Do not burden your customer with the cost of excessive design elements whose
value must amortize over time. That implies you must write lots of tests, so
you needn't fear change.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!


.

Relevant Pages

  • Re: agile development and frameworks
    ... >>>Just don't write more code than the current iteration's features need. ... > If the code will extend the same way it extends in this iteration, ... > removing duplication (with an eye towards the anticipated design), ...
    (comp.object)
  • Re: Virtual Functions in OO Analysis
    ... >>problem and the requirements is worth it. ... and one that requires iteration between the designers and ... into order of business value, and that this intrinsic business value ... is not only independent of the other features, ...
    (comp.object)
  • Re: agile/xp question (formal analysis)
    ... they learn from each iteration. ... > claiming that one should never use Product Managers or Business ... > Analysts in the Customer role. ... - sort features by business priority ...
    (comp.object)
  • Re: Question Unified Process
    ... >> replanning at every iteration, ... The result of the design process is a model. ... (Always break up your planning into features first... ...
    (comp.object)
  • Re: why java is not pure object oriented?
    ... DN> In Lisp then I want to extend language to support some cool feature ... DN> (special form of loop, coroutine, continuation or something else) I ... Actually, it's not so cool features, during Java learning my imagination ...
    (comp.lang.java.programmer)