Re: Tools was Re: [AM] A small success and a large irony

At 08:23 AM 2/12/2004 -0600, Scott P. wrote:

>| From: Scott Ambler<[email protected]>
>| Date: Thu, 12 Feb 2004 08:22:28 -0500
>|
>| Some thoughts on the tool issue:
>| http://www.agilemodeling.com/essays/simpleTools.htm
>|
>| - Scott
>
>Just a couple of thoughts in response to Scott A's essay.  Much of which
>amount to "I agree that using simple tools is good, but I think I
>disagree about the definition of "simple"...
>
>|  If you are modeling to understand something then the value isn’t in the
>| model that you create but in the modeling itself.
>---
>
>This implies that "understanding" is an irreversible state transition
>from not-knowing to knowing.

Sort of.  When you create small models you do sort of transition from one 
state to another, although there's nothing stopping you from going back again.


>  Many of us find that understanding of
>complex relationships or interactions is transitory and that retaining
>the model helps retain the understanding.

If there is value in doing so, then you should, particularly if that's the 
best approach available to you.  If there are better ways to work, do those.



>---
>| My rule of thumb is that the greater the amount of uncertainty
>| surrounding the issue that you are modeling the greater the flexibility
>| you will want in your tools, therefore the simpler your tools need to
>| be.
>---
>
>As noted previously, hand-drawn diagrams are simple, but the high cost
>of redrawing them may be a barrier to change.

I've never actually seen that in practice.


>  Tools that are lithe,
>well-suited to purpose, and well-integrated, may make your modeling more
>agile.  I can draw MSCs with our tools MUCH faster than I could draw
>them by hand, AND I can easily modify them, I export them to other
>tools, suck out lists of entity names as text, etc.

If that's the case, then do so.  But are you modeling with others when 
you're doing that, or are you by yourself?



>---
>| For example, when I am first exploring how I intend to build a screen I
>| will often use Post-It notes, sticking them to the nearest flat surface
>| (a desktop, a whiteboard, …) that I can find. Post-Its are easy to work
>| with, you can write brief descriptions on them or little sketches, and
>| easy to move around.  Furthermore they stay where you put them because
>| of the glue on their backside. Post-Its are great at the beginning of
>| screen design because you can get a feel for the layout very quickly,
>| adding and removing widgets quickly.
>---
>
>Post-its are a great tool.  Our UI designers use them extensively.  On
>the other hand, I can make text boxes in Visio as fast as I can make
>Post-its, I can move them around as easily, they remain sticky forever

That's nice, but are you working with your stakeholders when you're doing that.

The goal isn't to create a model, it's to understand their needs.


>(unlike Post-its), and [the killer] I can mail the result to somebody
>else, or print it in different sizes, or clone it as a base for
>exploring a variation, or put it under version control so I can remember
>the steps that led to the current state...

That's nice too, but you lose the value of inclusiveness with the 
post-its.  Make the trade-offs that are best for your team.



>---
>| perhaps my organization’s process insists on the development of
>| detailed screen specifications before any coding can begin (clearly not
>| a very agile process)
>---
>
>As noted elsewhere, I think the agility should have occurred in
>designing the screens and flows, which should happen before you go to
>code.

Yes, spending a couple of minutes doing so makes sense.


>   I don't see anything un-agile in designing the screen layout
>before you code it, unless you're totally into cowboy coding ("I may not
>have gone to design school, but I know a good screen when I code it
>up.")  Usability is important - it needs to be designed in and
>validated.  Getting it right often requires many iterations and
>more-or-less completely tearing up the paradigm interaction.  That's
>usually too expensive and too slow to do in code.

Depends on your tools, but if you need to do this then you should look 
around for tools that allow you to do so.


>On the other hand, the last half of the essay, on CASE tools and tool
>selection, is almost all good stuff and definitely worth reading and
>internalizing.  I think the list of cons and pros reflects a litte bias
>against tools

Perhaps, but then again I've been using a wide range of tools for a lot of 
years so perhaps that's just experience coming through.


>("time lost waiting" surely is offsetting some manual
>process that would probably take longer, "migration costs" should be
>compared with costs of manual translation, "maintenance of the model" is
>only a cost if you choose to maintain it,

If I'm not choosing to maintain it then I'd toss it away.  There'd also be 
little motivation in this case for me to use a complex tool, unless it 
generated code for me.


>which you would only do if you
>were getting continuing value out of it, and the "Benefits" section
>fails to mention integration of multiple views that keeps them in synch
>automatically when at least some kinds of changes are made.

I've found little value in keeping things in sync.  Everybody talks about 
this, yet it just doesn't seem to be all that important in practice because 
people can generally figure out what's going on.

- Scott 

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