Re: OO Software Project Entropy Question.

• Previous message: Universe: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
• In reply to: Universe: "Re: OO Software Project Entropy Question."
• Next in thread: Phlip: "Re: OO Software Project Entropy Question."
• Reply: Phlip: "Re: OO Software Project Entropy Question."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 11 Aug 2004 05:02:21 GMT

Universe wrote:

> JXStern wrote:

> > Fixing bugs is time well spent.
> >
> > It's the time putting the bugs in, that is wasted.

Hehehe.

> > >2. The introduction of the newer more modern techniques for software
> > >development (i'm thinking of Agile/Extreme etc] means that the
> > >mini-cycles as mentioned above are more likely to occur.
>
> XP/Alliance practices is characterized by a coding effort that lacks
> guidance by at least a minimally overall design plan.

[If that were true] so what? The results generally seem to show a low bug
rate and frequent deliveries...

It's not true, because XP recommends both a Release Plan and whatever
incidental planning a team agrees on. XP is a minimal framework, not maximal
limits.

> I.e. a plan
> that sketches an outline of at least the significant areas of the
> system based upon at least minimally overall prior investigation. [And
> intelligent engineers hardly take prior design as written in stone].

That's called an "Architectural Spike". Changing the names helps take the
emphasis on getting design right very early. Following your system, if you
get the design right early, you are screwed.

> This kind of "fly the by the seat of ones skirt" is as old as the more
> amateurish trends distinguished themselves viz a viz the more
> scientific/engineering, systems oriented approach from the very
> earliest days of modern electronic based programming began in '40's.

Without Agile practices, software engineering projects occupy a spectrum,
from excessive planning to undisciplined hacking.

GUI implementation trends toward the hacking end, lead by vendors' tools
that make GUI programming appear as easy as painting. Their tools
irresistibly link painting and coding to full-featured debuggers, and
neglect hooks to enable testing. These biases resemble old-fashioned
manufacturing methodologies that planned to over-produce hardware parts,
then measured them all and threw away the defects. Both speculative planning
and endless hacking risk extra rework and endless debugging.

Agile projects rise above that spectrum. We apply discipline to the good
parts of planning and hacking. We carefully plan to write many tests, until
new features are as easy as hacking - without the low design quality, high
bug rate, and inevitable decay. Agile projects become useful early, add
value incrementally, and maintain their value.

> > >What effect do these methods have on the levels of entropy in the
> > >software project - is it reduced or increased or is there no focus
> > >given to it - why ?
>
> An approach that takes creation of systems mainly as an exorcize in
> promoting spontaneity, can't but increase en tropic property of motion
> toward greater spontaneity - away from nodes of order to the sprawl of
> disordered spontaneity.

Some teams carefully write design plans, hoping to prevent later rework.
Such designs, once implemented, often resist unplanned changes.

Test coverage makes inspiration, intuition, spontaneity, and collaboration
safe. Relentless testing changes the kinds of communication a project can
leverage to get things done. Everyone knows Agile teams reduce their
paperwork burden, from requirements gathering to source comments. Common
work areas, shared code ownership, self-documenting tests, and laziness are
only parts of the reason.

Time spent "perfecting" an object model before implementing it delays
feedback, so use a "good enough" object model, and implementation procedures
that frequently review the model and maintain its flexibility. Agile
processes use constant team interactions to target a balance between too
little and too much formality.

Given a hard problem, TDD generates a solution, with a firm design hosting
flexible bug-free features, sooner than expected. This is why Agile
processes fear too much abstract design planning. Complexity that's too easy
to add becomes hard to remove.

> > It's mostly defined away. Some time/iterations should be allocated to
> > rework. eg, slack time, in classic project management. Only when the
> > slack is exceeded are you officially into "entropy".
>
> With XP/Alliance entropy is defined away from being a pejorative
> because in fact the en tropic state is what they are striving for.
> The camps promote system creation precisely as emergence from en
> tropic conditions.

Those who research XP itself - instead of its online verbiage and few
books - all report this effect: The more you refactor, the sooner you reach
a design that doesn't need more refactoring.

"Designing" means organizing the relations between the structure of objects
in memory and their behavior in time. Structure is bone, behavior is muscle,
and perfecting their design is difficult. The best way to seek simplicity is
to start with it.

The most important kind of duplication to fold is definitions of behavior.
Folding them together forces structures to grow new flexibilities. Mature XP
projects do _not_ refactor mercilessly, despite engineers are _required_ to
refactor when they see poor code quality. They don't. Adding new features
requires extending the existing design, just as if it had been brilliantly
planned.

> > >3. Following on to question two - given the older techniques/methods
> > >that were in use before these methods came about [became mainstream] -
> > >is there a comparison that can be made.
>
> Sure, I believe I just gave one comparison and others have other
> angles of objective comparison. Formalization of the amateurishness
> embodied in XP/Alliance doesn't then just blow everything else up so
> much that its comparison with the repeatable, purposefully seeking
> improvement via lessons learned, tactically iterative, and
> incremental, yet strategically systems oriented software engineering
> approach anchored in the scientific method.

I thought XP was a repeatable, purposefully seeking improvement via lessons
learned, tactically iterative, and incremental, yet strategically systems
oriented software engineering approach anchored in the scientific method.

All practices support that, together. You can't debate them in isolation.
But the most important one is naturally TDD. There's simply no comparison to
other processes.

When engineers interact with programs and source code, each operation is an
experiment. Engineers form a mental model of an application, and make a
hypothesis, attempting to predict an experiment's outcome. They perform the
experiment, compare its results to their prediction, and adjust their mental
model.

The biggest difference is what happens to the hypothesis, experiment, and
evidence afterwards. Are they thrown away, or added to the application's
constraints?

Some folks debug every experiment.

I test every experiment.

Debugging pushes behavior back and forth, with less constraints.

My tests are experiments that tune behavior, then lock it down.

For each big change, some programmers remember a handful of experiments, and
run the debugger over them.

For every small upgrade, I make tiny edits. After each one, I re-perform
every previous experiment, instantly.

Over my projects' lifecycles, I trade many long hours debugging for each few
minutes writing tests. TDD applies the "scientific method" by inverting
traditional software engineering techniques. The hypothesis comes _first_.

My response to your next reply will be, "How often do you find yourself in
the debugger hunting some ellusive problem, Elliott?"

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

• Previous message: Universe: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
• In reply to: Universe: "Re: OO Software Project Entropy Question."
• Next in thread: Phlip: "Re: OO Software Project Entropy Question."
• Reply: Phlip: "Re: OO Software Project Entropy Question."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]