Project Planning Software

William Attwood wattwood at gmail.com
Mon Feb 4 11:49:06 MST 2008


Hey Roberto, it's been awhile.  By cross-posting, I'm assuming you mean
posting the same message to more than one user group; am I correct?

You came across as attacking me without attacking me.  I'll do my best to
re-iterate without defending, as we're all allowed our opinions.

On Feb 4, 2008 11:17 AM, Roberto Mello <roberto.mello at gmail.com> wrote:

> On Feb 1, 2008 9:41 AM, William Attwood <wattwood at gmail.com> wrote:
> > Hello Locals.
>
> Hello William. It appears you don't know that cross-posting is frowned
> upon.
>
> >    I'm an organizational creative.  I like to diagram flowcharts prior
> to
>
> No idea what an "organizational creative" is.
>
> > tackling a project, and adjust them to meet changes as they happen.
>  This
> > seems to make it so management can see the project a lot easier than if
> I
> > was trying to explain the code workings to them.
>
> You seem to be saying that meshing software design, with a
> presentation of said design to management are the same thing, or that
> by doing the design in a "management-friendly" manner is beneficial.
>
> I don't think I agree with either of those statements, assuming that's
> what you meant. I find flow charts and boxes and other "I'm a visual
> person" type of design to be too slow and constraining. I use them for
> presentation and for a top-level documentation, but I don't design
> around them.



I follow the design out Methodology.  I design the data then the
application, not the application then the data.  In doing so, I like to
create my ER, UML, and/or ORM diagrams.  Not only do these help in a team
environment to understand the data and relationships, but they also help
when explaining to management the data relationships; if management wants to
see them -- mine does.  If I did not have the demand to see these diagrams,
I would do them less and program more, as I imagine you do.



>
>
> I find that often the "I'm a visual person and need boxes" speech
> means the programmer needs a crutch and can't seem to dig into the
> code without those crutches. Realize that I'm not saying that good
> documentation, including graphs, are bad.


That's an odd view.  Every developer has developed their own way to take an
idea and turn it into a program.  It just so happens that I have to
visualize the application, data, and relationships prior to creating the
program.  This is due to the way my memory is hard wired; through images.
I rely heavily on my Visual Memory in everything I do.  It seems you've
taken a different, more popular approach to programming that doesn't rely on
Visual Memory.



>
>
> -Roberto
> -Roberto
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>



More information about the PLUG mailing list