Re: [AM] justify modeling (Why Model?)

(responding to Scott P)

>> (Paul)
>| If one needs to write the code anyway, then the model is extra
>| cost.  Does it give extra value?  In reality, the rules of thumb
>| that decided when we should model, that were created 10
>| or 20 years ago, are now out of date because the relative
>| costs of modelling and coding have changed.  In truth, the code
>| *is* a model, and  much of the information one may produce
>| from a model could be produced from the working code.
>| 
>| Yes, there are still reasons to model, but there are now fewer
>| instances where these reasons apply.
>
> (Scott P)
> The point is to try to write the code once and do limited refactoring
> afterward, as opposed to writing it once, throwing it away, writing
> it again, throwing it away, etc., while you try to decide whether
> you're going at it the right way.  Models are cheaper than code,
> so it's MORE AGILE to do the early iterations in that form.

Where it is indeed more costly to refactor than to model in
advance, then model in advance.  Yet this is *not* always
the case.  It would be a wise approach to reduce both the
cost of changing the code once it is written, and the cost of
modelling in advance, then use whichever approach is
most efficient in the circumstances.


>| > ... The iteration is 1-2 orders of magnitude faster.
>| 
>| Yet you still need to produce the code.  Once you have the code,
>| you can check that it does what you want.  Agreed, in some
>| circumstances one doesn't know what code to write, and in
>| *this* case a model can help.
>| 
>| Agreed that in larger projects, the degree of coordination needed
>| increases the cost of changing code, and thus more modelling
>| is justified because it saves more in rework than it costs.
>
> The models are part of deciding what you want to do, both in
> terms of what the solution looks like on the outside (to the user)
> and what it looks like on the inside (what the pieces are and how
> they play together).

OTOH, if you find the need to model a lot, you might find that this
need can be reduced by taking forward smaller slices of
functionality at a time.  Your starting point will be the code that
already exists, whose functionality and purpose you are
already familiar with.  A small addition to this functionality
should not be hard to understand, and if it isn't hard to
understand, it will not need much, if any, modelling.  Many
people working this way do almost no modelling.  Writing
down the success criteria first (using TDD) gives an extra
clarity of purpose, further reducing the need for modelling.

This gives us an idea of where modelling would be more use;
where you are taking larger slices of functionality, where you
are not familiar with the purpose and functionality of the code 
that already exists, where the slice of functionality is a particularly
tricky problem.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------