[
Lists Home |
Date Index |
Thread Index
]
> From: Marcus Carr [mailto:mrc@allette.com.au]
<snip/>
> This is getting even further off-topic, but Rick Jelliffe
> sent me this pointer
> the other day. It reflects the way that he manages the
> developers of Topologi
> products and if you accept the basic premise, it casts quite
> a different light
> on the use and importance of methodologies. Even if you don't
> accept it, at the
> very least it illustrates the difficulty and imprecision of picking a
> development strategy for a project. See
> http://members.aol.com/humansandt/papers/nonlinear/nonlinear.htm
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). 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. The team must be able to exercise its own judgement as to what
they must do to succeed. But they also must have clear guidelines on what
they must deliver to each other and to others outside the team, not just in
terms of the software, but in terms of documents that can be used by
testers, documenters, or future development teams who must maintain or
enhance the system.
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 [1] in another
post. One of the reasons I love this book is it stands out in the field of
software engineering books because of its emphasis on the people factor.
Note the word "culture" in the title. There is a great deal of emphasis in
the book on the political and cultural aspects of process improvement, and
on the critical importance of the people in ensuring success. No methodology
can substitute for that.
Someone else in another post mentioned Martin Fowler. That reminded me of
another one of my favorite books: "UML Distilled: Applying the Standard
Object Modeling Language" [2]. Though it is ostensibly about methodology, it
has plenty of "best practices" advice, and Fowler also strongly advocates
keeping the methodology lightweight and allowing project teams the
flexibility to do the right thing.
[1]
http://www.amazon.com/exec/obidos/ASIN/0932633331/qid=1010695396/sr=1-2/ref=
sr_1_10_3/107-7533056-8280547
[2]
http://www.amazon.com/exec/obidos/ASIN/020165783X/qid=1010708520/sr=8-1/ref=
sr_8_71_1/107-7533056-8280547
|
