Re: OOP/OOD Philosophy

Hi Nick. In my embedded comments (and this will apply to everything we
correspond about, I will sometimes criticize Microsoft in general and I
want it made clear that all such comments have zero to do with you
because i truly enjoy your responses. So take a deep breath if and
when I give Microsoft heartburn;-)

Nick Malik [Microsoft] wrote:
> "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.

It is agile because the term 'extreme' as been so over-exposed that the
audience for this stuff evaporated. So, to be honest it is called
agile to remove the tarnish of the extreme labeling AND to emphasize
peppiness rather than dwell on the ever-present short-comings of the
pseudo-methodology.

Numerous OOD methodologies handle change much better than the agile
proponents will have you believe. The agile practices are no more
adept at change than anything else. What agile sells as response to
change is really immedite gratification. IOW, because everything is
held close to the actual coding everytime a marketing rep sneezes the
code can reflect pneumonia.

This is not responsible change management. This results in chaos and I
have seen it in profoundly big companies whose platitudes, awards, and
self-serving hype disguise the fact that beneath the covers employees
were agile enough to artificially meet deadlines to cash in on bonuses
while the quality of the software remains dubious to this day. Two
weeks ago I came across multiple instances of Y2K errors introduced to
code after the year 2000.

Agile to me means slippery and dodgy - I don't like it and it is
unacceptable in mission critical scenarios. Today many corporations
have had such fun laying off and off-shoring applications that no one
seems to remember that if they collapse or are incorrectly functioning
there will be unpleasnat consequences.

> 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.

Nick, I find this argument convenient but uncompelling. Design is
about many things. It is about playing thought experiments on sytems
and sub-systems to optimize and analyze the choices in the field of
possibility. The design techniques give us a short-hand to try ideas
before a line of code is written and in some cases it can automatically
generate that code.

It is also a blueprint of the system so that architects who have to
integrate one system into another when a corporate buyout occurs can
make sense of two systems.

It is also an inventory of parts, authorizations, licences, and so on.

It is also an audit trail of how it is suppossed to work so that
malicious behavior can be identified and isolated.

It is expensive to do but it is expensive not to do. Change management
is easier and more certain in systems employing front-end design
effectively.


> 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.

Well, if the only issue was producing code you'd have a winner. Code
has never been more than, say, 10% of systems building time and even
less cost although hardware is obscenely cheap these days so that cost
may differ. Software is becoming increasingly expensive as the
short-sighted cost cutting of design and documentation are taking their
toll and the cacophony of bad software development ideas, frameworks,
and techno-babble take its toll.

>
> Is this lighter? I don't think so. XP has much more rigor than waterfall.

XP has more waterfalls than waterfall ever had. More rapids, typhoons,
and sharks as well. I would be astonished if you could compare the
biggest XP project's rigor with the smallest government development
project for any military sensitive project. The feasibility study
alone would trump your entire XP enterprise.

XP thrives in the loosey goosey, let's pretend playscape of corporate
America where petty empires are built around in efficient applications
that ask for a piece of data that's retrieved from a database.

It's very hard to screw that up but that screwing happens so often that
even XP seems a relief to these environments. It is incompetence and
not the methodology that is to blame here.

> 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.

This should be a clue that change management is not a function of
rigorous design practice.

>
> 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.

Nine months is a long time these days depending on the application of
course. A luxury that most commercial companies will not tolerate.
three month business cycles dictate development cycles and castrate any
creative processes that design entails.

>
> 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.

IEEE should know that design is not an end user deliverable. And IEEE
should ask where the requests for unused features come from. I once
had a teacher who posed the eternal student question, "How long should
my report be!?" He replied, "Long enough to cover the subject but
short enough to be interesting". It seems there's a corollary there
foe software development.

Software engineers *have to* cover the subject yet make the application
easy enough to use.

On a personal note, I run Windows. There are libraries of documented
features I don't use. Send Bill an e-mail complaining that his product
could be cheaper without a browser and media player and whatnot.

Bill put WordPerfect under with esoteric features Three people needed
and millions didn't.

> 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.

SOME one uses them or they wouldn't be requested (unless you're talking
about perfunctory stuff needed to be be added so that Microsoft will
brand the application compatible).

>
> 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.

Maybe. But up front design eliminates asking this question iteratively
for eacgh sprint. That's my additional savings (we're price choppers
we are).
>
> 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.
>

No doubt. Thanks for the dialogue - people do learn here as well.

cheers,

Frank

.

Relevant Pages

  • =?windows-1252?Q?www=2Eelectronics=2Dmac=2Dsony=2Ecom___Motorola_KRZR_K1_Phon?= =?windows-12
    ... Product Features and Technical Details ... the KRZR K1 is the definitive handset for those who ... design, you get Bluetooth wireless technology, an integrated music ... detailing and premium materials shrouded within a distinctive metallic ...
    (alt.cellular.verizon)
  • Re: Code generation - Was: AOP in PHP - Was: OO in PHP
    ... It's called meta programming and though the concepts ... else (or there is no performance problem at all), ... There is much design humbug with respect to C++ and Java ... More features usually means more code. ...
    (comp.lang.php)
  • Re: OOP/OOD Philosophy
    ... in which you do design can enable the team to respond to change, ... Even Scrum, which is my area of practice, requires training for all members. ... We delivered the functionality that the customer desired, ... that surveys of users have shown that nearly 50% of all features in a BDUF ...
    (comp.object)
  • Re: Newbie object design questions
    ... A good profitable business needs to adapt to a changing ... And before you jump on that, I am saying that these "features" ... rather it leverages frameworks. ... IMHO it undermines the true usefulness of oo design. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: XP, a Criticism
    ... The root principle of emergent design is "remove duplication". ... removal enforces abstractions that make similar features easy to add. ... Put Code-and-Fix in another corner. ...
    (comp.object)