Lists Home |
Date Index |
Michael Brennan wrote:
> Thanks for the link. It's an interesting read. I would not agree that
> processes and methodologies are not important (which I don't think was the
> point of the paper, though I've heard this argued before).
I wouldn't agree either. We watched a company do their dough even though their
communication was excellent - they would fly team members around the country for
meetings at the drop of a hat, but lacked design and management skills.
> But I do think
> methodology should be lightweight. It should provide guidelines for people
> to assist them in their tasks, but it should not burden them or impose rigid
> laws on them.
I completely agree, but it's a very difficult balance to strike.
> I would also agree that the people factor tends to be neglected in most of
> the literature on software engineering and process improvement. I mentioned
> "Creating a Sofware Engineering Culture" by Karl Wiegers  in another
I saw your reference previously and thought to have a look for it. The idea that
the methodology may have less impact than communication leaves me with a
slightly uneasy feeling, even though I suspect it may be true. Nonetheless, even
a clunky methodology provides some less obvious benefits, such as client
confidence and a means of at least starting the project with all of the
development team on the same page. I guess the point is that everything that
helps a project lurch toward a sucessful completion is important, and it pays to
know what to look for.
Marcus Carr email: email@example.com
Allette Systems (Australia) www: http://www.allette.com.au
"Everything should be made as simple as possible, but not simpler."