Re: OOP/OOD Philosophy

"krasicki" <Krasicki@xxxxxxxxx> wrote in message
news:1120457495.193559.256250@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> > This frustrating truth is largely responsible for the Extreme
>> > *whathaveyou-usually-Programming* phenomenons. With a straight face,
>> > these proponents assert that if design is not egalitarian and if
>> > companies don't respect it then -snip, snip- out with it except for
>> > perfunctory lip-service.
>>
>> How many XP teams have you worked with?
>
> Why do you ask? The methodology is well-documented. It is considered
> a lightweight methodology is it not. It cannot be lightweight unless
> it is lighter somewhere. What is lighter? The sum programming is the
> same, correct?
>

It is an agile methodology because it allows for change to occur. The WAY
in which you do design can enable the team to respond to change, or can
create artificial barriers to change. If change is normal, then creating
artificial barriers is "swimming upstream." This creates cost and produces
difficult choices. XP, Scrum and other agile methods attempt to address the
underlying problem by changing the way in which software is produced,
thereby removing the artificial barriers to change.

Is this lighter? I don't think so. XP has much more rigor than waterfall.
The practices require training and reinforcement. Most agile processes are
lighter on "ceremony" but not on rigorousness.

Even Scrum, which is my area of practice, requires training for all members.
I've worked on a project that used FDD for requirements, Scrum for
management, and TSP/PSP for software construction. (In that case, the goal
of TSP/PSP was to create better estimates for the feature stories that were
managed by the scrum in a sprint.) Our design document grew to ~80 pages
long, and was kept up to date by the dev team (something often forgotten in
traditional waterfall projects). Our use case document was of similar size.
There were no short cuts.

We delivered the functionality that the customer desired, when they desired
it. We worked normal working hours most of the time. Our code was
thoroughly tested by a professional and independently managed test team and
our triage process, while rapid, was just as rigorous as most waterfall
projects. We cut the cost of development by an estimated 40% and delivered
four full iterations to production in a 9 month window.

Where did the savings come from? That's easy. The IEEE reported in 2001
that surveys of users have shown that nearly 50% of all features in a BDUF
(Big Design Up Front) commercial software project are not used by the users.
HALF. Working in IT, I can say that the number is probably closer to 35%
for custom software, but that number is still huge. 35% of the features is
35% of the time spent writing code, 35% of the time spent testing code, 35%
of the time spent planning and delivering and documenting. It's a LOT of
work for features that no one uses.

By using Feature Driven Development during planning, so that the customer
knows that actual cost of each feature, and by involving the customer at
every step and demonstrating the features on each sprint, the customer
chooses the features to develop, and helps to guide each feature until it is
actually valuable. That cuts about 35% of the extra effort out of every
iteration. That's our savings.

These methodologies are well documented, but so is Object Oriented design...
yet here we are, offering ongoing mentoring on object oriented development.
No one really learns an idea by hearing a self-professed expert, especially
an author in a book, stating a series of facts and assumptions. I believe
that people learn through their fingertips and their mistakes and their
personal moments of revelation and reflection. If you get a chance to work
on an agile team, whether XP or Scrum or Crystal (etc), you may find that
you'll pick up a bit more understanding of what Agile means in practice.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.

Relevant Pages

  • Re: XP Requirement Analysis?
    ... staged delivery ... In customer oriented practices it goes on at ... nope...though refector mercilessly to be a design, ... so I think the 'new' features are. ...
    (comp.object)
  • Re: XP, a Criticism
    ... > So we understand the necessary design better. ... the customer does not make requests for modifications to features ... the customer does not request new features during or after development. ... Given that these things happen so often on projects the aim of XP (or at ...
    (comp.object)
  • BEA is looking to hire a Customer-centric J2EE Engineer in San Jose:
    ... CUSTOMER CENTRIC ENGINEER - WebLogic Integration ... Write design and functional specifications for the required ... product features and enhancements. ...
    (comp.lang.java.developer)
  • BEA is looking to hire a Customer-centric J2EE Engineer in San Jose:
    ... CUSTOMER CENTRIC ENGINEER - WebLogic Integration ... Write design and functional specifications for the required ... product features and enhancements. ...
    (comp.lang.java.programmer)
  • BEA is looking to hire a Customer-centric J2EE Engineer in San Jose:
    ... CUSTOMER CENTRIC ENGINEER - WebLogic Integration ... Write design and functional specifications for the required ... product features and enhancements. ...
    (comp.lang.java.databases)