Olin Lathrop wrote:
> There are certainly some ways that are bad most or all of the time.  There
> isn't the One Good Way though.  This depends on the project, people,
> customer, facilities, manager, and lots of other stuff too complicated to
> make rules about.

How about just describing a project that either went well, or was a 
failure -- and trying to analyze what were the contributing factors? Isn't 
this what learning is really about?


>> I sense a double standard, however. Both of you (Gerhard and Olin) at
>> one time or another advocated (very forcefully at times) a certain
>> way of programming, or a design practice.
>
> I thought we were talking about higher level software development 
> practises,
> not details like putting constants in-line, at the top of a file, or in a
> include file.

Sometimes a small change can make a big difference. So no, I don't think 
limiting the scope of discussion to higher leve development practices is a 
good idea.


>> "There are no hard and fast rules", but there are guidelines that say
>> that certain practices are better than others. Today for example, I
>> discovered that at Olin's place of work, they use whiteboards, and
>> keep notes by taking digital pictures
>
> On that day for that project.

Do you think it worked well? Would you use it again? Why, or why not?


>> do you see *any* disadvantages to this design practice?
>
> Sure.  First, it's not a design practice but a project management 
> practice.
> In this case everybody envolved got together to figure out what was left 
> to
> do, how much, and who needed to do it.  This was done interactively with
> everyone, including the customer, present.  It was done not only to get a
> idea of the work left, but also to give the customer a sense of where 
> things
> were at and buy-in from everyone present.  It was logical to write this 
> down
> on the whiteboard as the discussion progressed.  Various things were 
> erased,
> rewritten, added, deleted, etc as the discussion progressed.

That's how I've seen it used, and how we use it at work. I almost forgot, 
that's another great thing about a whiteboard -- erasing stuff is very easy 
(easier than erasing something written with a pencil).


> As for disadvantages, some people may not want to speak up in a meeting as
> apposed to when you ask them one on one, or they may be afraid to give the
> honest answer instead of what they think you or the customer want to hear.
> For some people its a distraction to be bothered with stuff that isn't 
> their
> problem and they don't care about.  To some customers, this would look 
> Micky
> Mouse.  A lot of collective time was also spent.  There are certainly 
> other
> ways to manage a project, each with their own advantages and 
> disadvantages.

I hear you. And yet in my experience, I haven't encountered these 
difficulties. We usually spend maybe one or two hours per week 
"whiteboarding" -- and it pays for itself many times over.


> I guess my main point is that project management style needs to be 
> flexible
> for the particulars at hand.  Gee, maybe it'll be more believable if it 
> were
> called Agile Management or something.  How about "Fleximent"?  Does that
> sound new-fangled drink-the-grape-coolaid good enough?

A rose by any other name... :-)

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist