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

If a story is small, its implementation is fast enough that any possible model for the story is quickly superceded for purposes of communicating with the client, especially for purposes of feedback, refinement and eventual acceptance.  So, you must be talking about more global models.
 
Maybe you are talking about a model of an architecture to support all the stories.  Such a model represents technical decisions that the customer should not concern themselves with.  Agility would seem to call for the developers modeling the least amount of architecture possible until a few iterations of implementing isolated stories and obtaining feedback converges the system evolution to the point where we can be confident of the appropriate architecture.  Some call this letting the architecture evolve.  Modeling it after it evolves can help us make it more uniformly consistent and help all the developers agree on its shape. 
 
Or maybe you are talking about a domain model?  I would argue again that it is more agile to allow domain models to evolve and converge in the same sense as the architecture.
 
Premature use of an persisted model for communication can be a trap that makes it harder for us to eliminate our poor initial guesses from all the minds we communicated the model to.

	-----Original Message----- 
	From: Patrick James Nelis [mailto:[email protected]] 
	Sent: Mon 2/2/2004 11:34 AM 
	To: [email protected] 
	Cc: 
	Subject: RE: [AM] justify modeling (Why Model?)
	
	

	If the model serves as the communications vehicle with the client,
	it may survive several iterations of the code, before the point of
	diminishing returns sets in.  The model may be the best vehicle to
	describe to the client what is changed and why.  It also serves as
	a means to communicate with a large team of persons, so that the
	project manager can be assured that the team is aboard before the
	solution is presented to the client. 
	
	Pat
	
	-----Original Message-----
	From: Steven Gordon [mailto:[email protected]]
	Sent: Monday, February 02, 2004 12:48 PM
	To: [email protected]
	Subject: RE: [AM] justify modeling (Why Model?)
	
	
	Would you agree to the assertion that the less complex the story,
	the sooner that modeling the story and its implmentation hits the
	point of diminishing returns?  Or do you have to model all the
	stories before you can start designing and implementing any story?
	
	-----Original Message-----
	From: Scott E. Preece [mailto:[email protected]]
	Sent: Monday, February 02, 2004 10:41 AM
	To: [email protected]
	Subject: Re: [AM] justify modeling (Why Model?)
	
	
	
	I phrased the statement badly.  Some of the modeling goals simply
	aren't met by code, so there would still be value in modeling even
	if code were cheaper than modeling.  However, in practice, code
	isn't cheaper than modeling, because the model is an abstraction
	of the code.
	
	My own rule of thumb is that a design should involve an order of
	magnitude fewer symbols than the implementation of the design (for
	large systems, the architecture design should be another order of
	magnitude more abstract).  A model should be at that level of
	abstraction, so you can do several of them and still be cheaper
	than code.
	
	>From my point of view, the goal is to be able to iterate the
	design
	before you do code, because the design is smaller and, therefore,
	cheaper to change, so your iterations can be much faster.  You can
	do substantial amounts of validation on the models without
	creating code that would have to be changed.
	
	This should make sense even to an agilist (and certainly to an
	agile
	modeler) - you do those cheap, lightweight models, walk through
	them in various ways to validate them against your stories (use
	cases), revise or replace them, all in the course of a modeling
	session.  The iteration is 1-2 orders of magnitude faster.
	
	The usual rule of diminishing returns sets in at some point - it
	becomes more expensive to add more detail to the model (increasing
	its size and
	fragility) than it would to go to code.  If you're doing things
	right, you have done enough exploration and validation at that
	point that you can expect to not have to rework the design too
	radically once it's been written.
	
	scott
	
	| From: Daniel Brenner<[email protected]>
	|
	| Scott E. Preece wrote:
	| > In all these cases the working premise is that the model is
	much
	| > cheaper and quicker to produce than actual code and,
	therefore,
	| > allows you to produce the design (both internal design and
	external
	| > design) in rapid iterations.
	| exaggerated: if code is cheaper then forbear from modelling? And
	even
	| when you did model you still have no serving code (again
	exaggerated:
	| isnt that a waste of resources? (time and money)). Or is the
	gained
	| benefit worth it?
	
	
	--
	scott preece
	motorola urbana design center (il67), 1800 s. oak st., champaign,
	il  61820 
	e-mail: [email protected]       fax:    217-384-8550
	phone:  217-384-8589    cell: 217-433-6114      pager:
	[email protected]
	
	For more information about AM, visit the Agile Modeling Home Page
	at www.agilemodeling.com
	
	For more information about AM, visit the Agile Modeling Home Page
	at www.agilemodeling.com
	-
	
	For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
	
	
	
	
	
	


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
--^----------------------------------------------------------------