Re: Holistic, Rational, Scientific Development: An Outline
From: Andrew McDonagh (news_at_andrewcdonagh.f2s.com)
Date: 09/29/04
- Next message: Kurt: "Re: So let's build a router"
- Previous message: Mike Smith: "Re: Why Software Is Bad and What We Can Do to Fix It"
- In reply to: Universe: "Holistic, Rational, Scientific Development: An Outline"
- Next in thread: Universe: "Re: Holistic, Rational, Scientific Development: An Outline"
- Reply: Universe: "Re: Holistic, Rational, Scientific Development: An Outline"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 29 Sep 2004 22:05:25 +0100
Universe wrote:
>>>And as I see "rationalism" it's more so as I state in another post
>>>today: the ability of proven knowledge - that is *theory* - to
>>>rationally inform and *lead* our work practice.
>
>
> I differ from Webster's in stressing that reason, theory, reasoning
> conceptualization should play the *leading" role, in our activities
> while practice should verify.
>
> Directly opposed to that, philosophical pragmatism and empiricism that
> underlie XP places greater emphasis on the results of recent, or
> immediate practice. It favors the aphorism, "if it works do it".
'Applying' the XP practise do indeed favor gaining and using what ever
knowledge can be gained from the most recent work.
>
> Whereas I emphasize the value of studying prior, historical, or already
> summarized experience in what we are doing and applying lessons learned
> creatively according to specific context. This is the 1st part of what I
> mean by "theory leads".
But this sounds exactly like the approach that Beck et al took with how
projects they had previously worked upon and resulted in what we all
know as XP.
> The 2nd part of what "theory leads" is that our current activity should
> be mapped out in always amenable theory, ideas as a plan. "Amenable"
> plans means that they may modified, or replaced in toto during the
> course of project IID - iterative and incremental development.
>
> Amenable plans should largely be constructed based upon:
> ` ideas, theory, thinking, concepts, reasoning from prior activity in
> contextually similar and relevant circumstances
> ` ideas, theory, thinking, concepts, reasoning resulting from
> investigation, and discovery of the current project context, and
> goals.
>
> Plans may be modified based upon system user, management, domain expert,
> or developer feedback from activities during the course of the project.
> Projects should have:
> ` a panoply of mechanisms for eliciting and incorporating feedback
> during its IID
> ` multiple times of regularly scheduled feedback sessions between
> system users, management, domain experts, and or developers.
Isn't that what XP strives for, but traditional aapproaches discouraged?
>
> A 3rd related facet of this is that the project should evaluate, weigh,
> tradeoff and otherwise make decisions with a holistic, systems
> perspective.
> They should be made always after understanding and
> considering together as whole, all key relevant parts of the whole
> project. What is part and what is whole differs each kind of project
> decision. But both the particular whole and parts involved should
> identified and handled in the foregoing manner for all major project
> decisions.
Absolutely, even on an XP project the customer would take the same
approach when making decisions. And importantly, it happens all the
time, not just at the beginning or at major milestones.
>
> Of course this means employing a use case leading, model drive
> architecture approach as with UP and MDA at OMG. [See www.omg.com for
> details.]
From my experience I have to disagree.
>
> High level system design should explicitly be based upon or embed an
> object model of real actual domain entities and processes that a play
> and role insofar as they are relevant to project use cases as whole -
> project scope. There are a number of reasons this help create the most
> optimal OO designs, and I will detail in soon to follow posts over the
> next 2-3 days.
>
> Finally for completion the project should apply relevant contextually
> objective facts and a scientific: hypothesis, experiment, theory back to
> practice and so on approach.
>
> These are significant kind of rational holistic practices and viewpoints
> that a truly "scientifico-engineering" approach to software development
> takes.
>
> That is as opposed to the:
> ` piecemeal
> ` frequent stovepipe design cul-de-sac waste of resources turnaround
> ` part above whole designs and decisions
> ` coder-centric
> nature of XP project development.
>
> Again, for those whom haven't *actually* read up on the essentials of UP
> and MDA to best contribute to improving OO and software engineering,
> which should be the intent, the goal of discussion on these matters. It
> is at least as far as I am concerned.
Elliot, you may have posted intending to discuss ways of improving OO
and software engineering, but for me at least, it reads more like an UP
& MDA vs XP rant.
If you truly want to discuss ways of improving OO & software
Engineering, then can we at least stop the process wars that this group
is having....its akin to Unix vs Windows vs Mac... its also boring.
Andrew
- Next message: Kurt: "Re: So let's build a router"
- Previous message: Mike Smith: "Re: Why Software Is Bad and What We Can Do to Fix It"
- In reply to: Universe: "Holistic, Rational, Scientific Development: An Outline"
- Next in thread: Universe: "Re: Holistic, Rational, Scientific Development: An Outline"
- Reply: Universe: "Re: Holistic, Rational, Scientific Development: An Outline"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|