Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.
- --- Mike Beedle <beedlem@e...> wrote:
>Steve McConnell is listed at the SWEBOK site not only as one of the
> Just about all the 70s, 80s, and 90s top
> influenciers in software development sponsor
> now agile methods:
> Parnas, Yourdon, Constantine, Lister, DeMarco,
> Weinberg, Glass, Gilb, Boehm, Booch,
> Jacobson, McConnell, and of course Cunningham,
> Beck, Sutherland, Cockburn, Fowler, Schwaber,
> Sutherland, Coplien, Coad, Highsmith, Martin,
> ... oh, too many more to list.
> My point is: there are hardly anyone left who
> is who in software development that is not
> an advocate of agile software development.
12 members of the "Industrial Advisory Board", but as one of only
three members of the "Panel of Experts" that advises said Board. His
prominence there coupled with the cited absence of support in the
SWEBOK material might suggest that he is, at best, a luke-warm friend
of the movement.
A brief review of his site (www.construx.com) suggests that, while he
seems to honor XP practices and the word "Agile" (the latter only
from a distance), he makes little effort to further either movement
except for an attempt to market his own flavor of XP via a
proprietary framework called CxOne. See his white paper
his proprietary "CxOne" process to XP "along with a look at how CxOne
can assist XP projects". His company will be happy to sell you
their "CxOne Extreme Programming toolkit" which "gives you all the
materials you need to run a successful XP project."
His company's decription of the CxOne software engineering framework
(http://www.construx.com/cxone/) seems almost to go out of its way to
avoid use of the word "agile", substituting it with a whole string of
adjectives that retain its essence: "lightweight, tailorable,
modular, and scalable".
The only reference I could find there to the agile _movement_ is in a
copy of his editorial entitled "Common Sense" from the July/August
2001 issue of IEEE/Software in which he says:
"One contribution of the agile programming movement is to cast a
critical eye toward prevention and ensure that projects do not spend
more on prevention than they would need to spend on cure. On balance,
I think this common sense maxim does apply to software, but we need
to be careful not to overextend it, i.e., "Moderation in all things."
Could we perhaps conclude that Mr McConnell might fear charges of
1.) a conflict of interest if he were to promote XP for SWEBOK?
2.) trying to promote "common sense" as an engineering discipline if
he were to promote agile methodolgies by name?
- -----Original Message-----
From: Fabian Ritzmann [mailto:usefri@...]
> Need to bring this back on topic for this list. :-)Oh, I don't know -- we are still sort of on topic.
> --- Fabian Ritzmann <usefri@...> wrote:We call tests by the user "acceptance tests" or ATs.
> XP as I understand it uses unit tests and system
> tests, unit tests for unit testing and system tests for
> whatever the users want to test, including quality
> aspects like performance, reliability, etc.
I think this is a valid definition across XP and
Scrum but I don't know if other agile methods call
them the same way.
> The combination is very powerful:Fabian wrote:
> * test as _specification_ from Test-First, and
> * program as executable _specification_ from
> functional programming
> Both strategies drive development more into the
> quantifiable _what_ space, much more than worthless
> "exhaustive requirements documents" or "models".
> Perhaps, this is what we need to concentrate in
> software architecture -- in patterns that tell us
> _what_ to program and that are executable,
>The principle problem is that provable (and executable)True. In our view, the need for acceptance tests
>specifications don't help if the specification is wrong.
>And we all know that specifications always change,
>that's why we do Scrum or another Agile development
>method. Of course that shouldn't keep anybody from
>improving the way we are programming these days.
conducted through people-2-people interaction
never goes away for the exact reasons you list
(and regardless the programming styles used):
- making sure that the specification is not wrong
- making sure that we keep up with changes
for the specification
- making sure that the user experience is
comfortable i.e. timely, convenient, beautiful, etc.
It is just easier, faster and even more economical
in some paradigms of programming to do the above