Agile Mythology
Edward Berard
General Dynamics (GD). For eight hours a day, five days a week, over a
period of six months, we trained GD's engineers in various software
engineering disciplines. Each short course typically lasted one week,
and some lasted as long as five weeks.
Some of the books we used as training materials would be recognizable by
many of today's software developers, and included:
* Gerald Weinberg's "The Psychology of Computer Programming"
* Glen Myers's "The Art of Software Testing"
* Fred Brooks, Jr.'s "The Mythical Man-Month"
As part of the development-related courses, I would routinely ask the
class, "When was the last time you worked on a project where there were
not changes?" The usual reaction from the class was laughter intertwined
with shouts of "Never!"
Change was a normal part of any serious software development/enhancement
effort at the time, just as it is today. In the mid-1970s, I had been
introduced to both the concept of "change management," and several tools
that could be used to automate the process of change management. Having
worked on large financial applications, I became well-aware that some
thought had to be put into change requests, the testing of changes, and
the sequencing of introduction of the changes.
The class participants expected changes to be both frequent and
voluminous on all of their projects. Even though most of them were
probably using a classic iterative waterfall lifecycle approach, this
did not impede the constant introduction of changes.
During the testing courses, we routinely talked about the importance of:
* Knowing how you were going to test a feature, prior to implementing
that feature
* Automating the testing process, and what types of off-the-shelf
testing tools could be used in the process
Throughout almost all of the training, we emphasized such things as:
* Never adding a feature unless the customer specifically asked for
it. (Students were routinely told to avoid "gingerbread," "window
dressing," and "gold plating.")
* Simplicity.
* The concept of "group responsibility," as well as "group
ownership."
* The importance of the impact of human psychology on team building,
testing, and the entire software engineering effort.
* The tailoring of both technology and techniques to the actual
environment in which the students would be working.
If I could take many of the statements and discussions currently
appearing in the "agile forums" back to 1979, I would wager that there
would be a great deal of confusion amongst my students.
Mythology is a tool that humans have used for centuries to "explain"
things that they do not understand. Today's agile advocates have
assembled a large number of myths to explain away some things that
they obviously do not understand, or have chosen to ignore.
-- Ed
P.S.: Please note that my emphasis here is the way non-agile approaches
are characterized by agile advocates. I am purposly avoiding
a discussion on the merits of any particular agile technique or
methdology.
--
Edward V. Berard | Voice: (901) 309-1912
The Object Agency, L.L.C. | Fax: (901) 755-5622
2965 Cane Creek Drive | E-Mail: e...@toa.com
Germantown, Tennessee 38138 | WWW: http://www.toa.com
Ronald E Jeffries
>Mythology is a tool that humans have used for centuries to "explain"
>things that they do not understand. Today's agile advocates have
>assembled a large number of myths to explain away some things that
>they obviously do not understand, or have chosen to ignore.
>
> -- Ed
>
>P.S.: Please note that my emphasis here is the way non-agile approaches
> are characterized by agile advocates. I am purposly avoiding
> a discussion on the merits of any particular agile technique or
> methdology.
Ed,
Your history is reminiscent of mine. What I'm wondering is just what
myths you are working to bust?
Thanks,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Phlip
> Twenty-five years ago (1979), I was part of a training team working at
> General Dynamics (GD). For eight hours a day, five days a week, over a
> period of six months, we trained GD's engineers in various software
> engineering disciplines. Each short course typically lasted one week,
> and some lasted as long as five weeks.
> * Knowing how you were going to test a feature, prior to implementing
> that feature
This is profoundly different from writing the tests and the code at the same
time, and _predicting_ the result of each test run. Those predictions
reinforce your mental model of the code. (And TDD works whether or not you
have planned any of your design up front.)
TDD changes everything. Modern Agile teams can take shortcuts that
old-fashioned Agile teams could not.
> * Automating the testing process, and what types of off-the-shelf
> testing tools could be used in the process
Buying testing tools is different from growing them with your project. An
OTS purchase is an up-front design decision; it's not always right.
> Throughout almost all of the training, we emphasized such things as:
>
> * Never adding a feature unless the customer specifically asked for
> it. (Students were routinely told to avoid "gingerbread," "window
> dressing," and "gold plating.")
This is somewhat different than the ancient lean development concept of a
"customer liaison".
> * Simplicity.
This is somewhat different than emergent design based on folding definitions
of behavior to introduce new structural flexibilities.
> * The concept of "group responsibility," as well as "group
> ownership."
This has a tiny difference with the "bills of rights", which purport to
separate responsibility and authority cleanly.
> * The importance of the impact of human psychology on team building,
> testing, and the entire software engineering effort.
Sigh. There are just so many ways those who expound such things can get it
so twisted. But I suppose I'm about to hear, "Oh, we had a 'sustainable
pace' concept in the 1970s too! Therefore Agility is nothing new."
Some folks have lead very sheltered lives!
> * The tailoring of both technology and techniques to the actual
> environment in which the students would be working.
"students"?
> P.S.: Please note that my emphasis here is the way non-agile approaches
> are characterized by agile advocates. I am purposly avoiding
> a discussion on the merits of any particular agile technique or
> methdology.
Mystification works both ways. When you have experience working an XP
project, your reports of similarities and differences between its systems
and those of the 1970s will then be credible. You would then have something
to contribute. Until then, making a career of endlessly gainsaying the
vehicle of Agility, not its payload, is very sad.
However, I can make it useful to me. I seem to think that more people to
this day do code-and-fix than waterfall. Anyway to get thru to them could be
a Good Thing, regardless of its vehicle.
Please critique the following. I feel I have worked hard to exclude mythos
and revisionism from it. I do suspect nobody was doing it in the 1970s, but
I wasn't programming then so I wouldn't know. TDD is a new concept that
changes everything.
----8<-------------------
Agility
The best metaphor for software agility is its closest analog in hardware
agility. Lean Development by the Poppendiecks explores that metaphor very
well. Software assembly costs less than hardware, as it's weightless and
proton free. Source code's ease of change provides many false paths away
from good designs.
This essay mixes common metaphors: Driving, airplane takeoffs, hill
climbing, etc. Like Peter Merel's metaphor, "The Tao of Extreme
Programming", from the book Extreme Programming Examined, this chapter,
alone, will not teach you how to implement and practice Agility. It shows
what to expect and observe as a team follows specific techniques found in
any of the dozens of fine books on these subjects. Metaphors are bridges
between concepts; each leads to a different aspect of the same thing.
Feedback
Information, metrics, senses, knowledge, and results revealing a project's
current state, in real-time, are priceless. Software development is murky
and mysterious by nature, and must force down the cost of high-quality
feedback.
Development follows two nested cycles. Writing source code to implement
features is the inner cycle, and deploying versions to users is the outer
cycle. If feedback from tests drives the inner cycle, then feedback from
users can steer the outer cycle.
The best feedback is gains in users' productivity.
Some projects don't automate tests for all their code, so they can only
afford to manually test every few weeks, or less often. That impedes
improving users' productivity. Inner cycle delays compound outer cycle
delays.
Some projects implement their features in order of technical difficulty, not
business priority. That also delays improving user productivity. Users must
wait, then they might request rework. Outer cycle delays compound inner
cycle delays.
Tests create feedback to drive Agile projects' inner cycle, permitting
frequent software releases to create feedback to steer the outer cycle.
A project becomes Agile when the rate that
feedback collects information about the
current position exceeds the rate
a team changes that position.
A car, driving on a dark stormy night, needs headlights that illuminate
things farther away than the driver's reaction time and safe turning radius.
Visibility relieves stress.
To lower the cost of change (and reduce that reaction time) Agile projects
automate tests and run them relentlessly. While writing code, automatically
test everything relevant to a module after the fewest possible edits; say 10
at the most. Only perform small, incremental edits that immediately return a
project to a useful state.
To lower the odds of reworking a project's features (and to boost those
headlights), frequently release useful versions to users. But don't release
bugs. Relentless testing trades long hours debugging for short minutes
writing tests, enabling frequent releases.
Oil and maintain your project's test machine, to lower the cost and boost
the value of each test run, and to back up the team's courage. Testing is
hard to learn. Any source code lacking tests risks delaying feedback. Teams
need experience, practice, communication, and ambition to automate a test
for any kind of situation.
Communication
Projects written by more than one programmer can scale beyond solo efforts -
if everyone communicates. There are three general kinds of communication;
writing, speech, and test cases. Each has costs and benefits, but
traditional teams often get their balance wrong.
Some teams carefully plan designs to prevent later rework. Such designs,
once implemented, might resist unplanned changes. Projects that plan their
designs before implementing them might reject ideas to improve designs that
occur too late.
Some teams construct modules in relative isolation. They plan narrow
interfaces, take these plans to separate offices, thrash code for a long
time, and then try to integrate. Low-quality feedback is worse than none.
Teams need communication, and might mistake paperwork for it. Some
programmers pride isolation to defend their creative process. So some
projects plan their designs for a long time, and some projects reduce the
paperwork burden by only planning interfaces, and allowing programmers to
implement unplanned modules in isolation.
Test coverage makes inspiration, intuition, 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. Laziness, common work areas, shared code ownership, and
self-documenting tests 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.
Agile teams set a very low threshold before changing code. Formal
documentation could never hit a moving target. Design Smells are feelings or
attitudes about code quality, which may or may not link to rational
explanations. Engineers who smell them are required to refactor and see if
the design gets better, and required to use feedback from reviewers and
tests.
Big changes performed in tiny steps, testing every few edits, decouple
objects from their neighbors, and cohere objects with their test cases.
Test-Driven Development is a design technique. Changing minimal code while
passing tests confirms that code's design quality.
Testing the act of changing code fundamentally shifts how our industry
teaches good designs. Books like Design Patterns show good solution
instances, frozen in time. Books about Agility assist the search for good
designs, integrated with activities that pay for the search.
Tight & automated feedback, and high-bandwidth communication within a team,
increase the odds of preventing errors. Unnoticed errors lead, later on, to
long bug hunts in code that may have since grown more complex. Agile teams
complete features in small batches.
Feature requests doled out a few at a time - tokenized as User Stories -
prevent complexity. We only advance designs in small increments, fitting
each new requirement in with the existing ones closely and irrefutably.
Software engineers implement each User Story by writing its simplest
abilities first, then coding advanced ones while refactoring their code
together.
Given a hard task, solve the simplest
condition within it. To invent a language,
make it print("Hello World") first. Solve
for several simple cases, then merge the
solutions to solve the general case.
When mathematicians write advanced proofs, such as for geometries that
generalize to any number of dimensions, they first solve a specific proof
for 2D, then a proof for 3D, then for 4D. Armed with these experiences, and
proofs, they merge duplication into a single generic proof for ND.
(Leaving only the ND proof in the textbooks, to show off, turns math books
into such light pleasant relaxing reading material.)
"Designing" means organizing the relations between the structure of your
objects in memory and their behavior in time. Perfecting this design is a
hard task, too. The best way to seek simplicity is to start with it.
Simplicity
Designing reconciles conflicting requirements. Each conflict is an
opportunity for complexity. The book Notes on the Synthesis of Form by
Christopher Alexander presents the best rationale for designing in small
increments. In software, "small" means 1 to 10 edits before hitting the test
button. Perform the smallest, simplest change you can that returns the
project to working condition, but with a slightly different design, or
slightly more abilities.
Designing on paper makes the steering wheel very loose (no tests to provide
tactile feedback), darkens the headlights (no reviews of live code), and
accelerates (because designs on paper are too easy to change). Planning
designs generates very high rates of change without constraints, propelling
our vehicle into the dark, toward a goal that might be wrong, and toward
unseen obstacles.
Organic Design grows a solution, starting from the simplest case. A
statement grows long, and becomes a block. The block sprouts into a
function, which becomes a class. Crowded classes split by affinity,
responsibility, and authority into modules.
This freedom can make adding features too easy. Feedback-driven systems need
checks and balances to dampen perturbations.
As engineers add features, the Onsite Customer role reviews them, and
censors any low-priority details that should not affect velocity. Onsite
Customers are authorized to request ambitious features if they accept the
responsibility to monitor and analyze those features' growth into live code,
and to suggest simplifications and corrections. In exchange, engineers are
authorized to change source code freely, if they accept the responsibility
to make features easy for Onsite Customers to specify and monitor. Projects
grow Customer Acceptance Tests to provide custom feedback for each feature.
All experienced programmers remember diligently working on features, with
complex internal logic and complex external displays, which users then never
used. High-quality feedback and aggressive Scope Control reduce the odds of
wasting time, both inside the application's internal logic and outside its
GUI. Frequently demonstrate your new features to your Customers, as you
create them, and when they tell you a feature is now finished, don't argue.
Only implement features the Onsite Customer has scheduled for the current
iteration.
Onsite Customers sort User Stories by business value.
A project must finish its primary set of features before working on a
secondary set. For the first few iterations, only the primary ones get any
design attention, coding attention, or tool support. Reviewing an
iteration's results assists adding new User Stories to the stack, and
assists resorting the stack before the next iteration.
Some projects start by guessing which tools they will need, then buying
them. Even if an organization already bought a given tool, adding it to a
project is still a purchase, expecting a cost of ownership lower than return
on investment. If you delay an acquisition until simple code reveals the
need for it, you might never need to acquire. If you do, your well-factored
code will specify the exact tool you need, and will insulate other modules
from the change. After replacing a module, all your tests must still pass.
Delay expensive decisions until the last cheap moment.
Some Agile literature admits a diagnosis of nebulous or rapidly changing
requirements indicates an eXtreme Programming prescription. This sophistry
appeases those with positive experiences converting relatively motionless
requirements into planned designs before implementing them. But we don't
care if all the requirements are carved in granite.
Source code supporting the primary features, written
first, experiences the most test runs over its remaining lifetime.
Finished primary features assist specifying new secondary
features, so their details reinforce the primary features.
All roads lead to Rome.
Refactors invest secondary features into the primary
features' code, amplifying the testing pressure that
constrains the primary features.
Implementing features by business priority is a
design technique.
Without tests, adding new features destabilizes old code. So without tests,
we can't promise our customers that they can safely request any feature
next. Without tests, we might need to see all the requirements, to work on
the hardest technical problems first. Without tests, the customer can't
easily steer in real-time toward a business goal.
Courage
Without test-first and refactoring, clients think they must assemble as many
program requirements as they can afford to have written. This effort snarls
all relative business priorities together, making Scope Control impossible.
It obscures opportunities for simplification. Designing and implementing
many features at once is very hard, leading to our industry's reputation for
very large failures. Putting tests in front of development's inner cycle
permits an outer cycle of incremental feature growth. That relieves the
customer of the responsibility to predict the future and guess which
complete set of features will maximize productivity.
Traditional teams who write tests last, after writing the target code,
duplicate effort. They debug to remove the bugs that tests would have
prevented, and they lose opportunities for tests to constrain designs. And
they may duplicate effort by collecting metrics to see how many different
paths the tests cover. When tests force every path to exist, coverage
metrics stay high as a side effect of rapid development.
When tests drive development and make changes safe, the search for the set
of features that maximizes users' productivity becomes a simple
hill-climbing algorithm. The customer always fearlessly picks the steepest
slope from the current location. This simplifies requirements gathering,
because implementing the features with high business value teaches how to
specify the lower value features, so they support the higher ones.
Relentless testing over incremental changes enable Agile projects to:
* accept feature requests in any order, at any time
* release any Integration to Quality Control and beyond
* minimize the time between specifying a feature and using it.
A project's client steers with feature requests, getting the most important
ones first. The sooner these features help users add value to their own
endeavors, the sooner our project lifts off the runway and sustains itself.
Teams must remain technically and mentally prepared to fearlessly change
anything.
The eXtreme Programming literature revolves around a list of 12 practices,
forming a minimal but safe process. Some projects need more than those 12.
Doing those minimal practices will teach if your team needs more practices
faster than doing more or different practices will teach that you should
only do the 12.
Time to Market
The only "evidence" that XP "works" is the rate programming shops learn
Agility. Honest businesses are systems for collecting scientific data - they
just call it "money".
XP attends to the most common risks to velocity:
* long bug hunts
* delays before releasing
* reworking previously deployed features.
To speed development while preventing long bug hunts, XP recommends
Test-Driven Development, which treats the lack of an ability as a minor bug,
and writes a test to capture that bug before killing it. The supporting
practices are Merciless Refactoring, to paint yourself into corners and then
cut new doors; Simple Design, to avoid wasted engineering efforts; Pair
Programming, to learn about each change; Common Code Ownership, to minimize
political or esthetic reasons not to change code; a System Metaphor, to
shorten sentences, and Continuous Integration, to merge code changes before
they conflict.
To avoid delays before releasing, XP teams do not just release often, they
Release Frequently, typically every two weeks, rain or shine. (Some releases
don't go all the way to real users. Each one need only demonstrate a
hypothetical productivity boost.) Whole Teams know each release's status
non-verbally, and have the mandate to automate as much of their workflow as
possible. The business side reviews and extends Customer Acceptance Tests to
show exactly what features each release contains. Teams who Frequently
Release must face disturbing issues, like installers, and incrementally
develop their scripts.
To avoid rework, XP teams boost user productivity early and often. The
Planning Game sorts User Stories in order by business value. This is a
hill-climbing algorithm - a search for the maximum productivity boost from
the current position. On hills without secondary peaks, the shortest path up
is always the steepest path from any point. In the space of programming, a
hill-climbing algorithm encounters no secondary peaks if all application
features can deform smoothly and continuously. Simple Design, Merciless
Refactoring, and Test-Driven Development enable designs and features to
change freely.
Notice the fixes for those risks overlap. That's the point: The XP Practices
are all "best practices" when used alone - in moderation. Put together, they
bind and reinforce each other, permitting extreme use without overhead.
Questions about practices have answers in other practices. A Sustainable
Pace also prevents long bug hunts.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Phlip
> Your history is reminiscent of mine. What I'm wondering is just what
> myths you are working to bust?
Don't you see, Ron? If you read between the lines of the up-front philosophy
section of any of the (40 or so) Agile books now available, they _all_ say
we invented this stuff in the late 1990s, and everyone only did Waterfall
before then!
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
John Roth
"Ronald E Jeffries" <ronje...@acm.org> wrote in message
news:fk4af0d32or1pgt02...@4ax.com...
> On Wed, 14 Jul 2004 04:12:47 -0500, Edward Berard <e...@toa.com> wrote:
>
> >Mythology is a tool that humans have used for centuries to "explain"
> >things that they do not understand. Today's agile advocates have
> >assembled a large number of myths to explain away some things that
> >they obviously do not understand, or have chosen to ignore.
> >
> > -- Ed
> >
> >P.S.: Please note that my emphasis here is the way non-agile approaches
> > are characterized by agile advocates. I am purposly avoiding
> > a discussion on the merits of any particular agile technique or
> > methdology.
>
> Ed,
>
> Your history is reminiscent of mine. What I'm wondering is just what
> myths you are working to bust?
Edward's been at this stand for a while, and I think he missed
the point in this presentation as well (from the June 17, 2003
meeting of Atlanta Spin)
http://www.cc.gatech.edu/SPIN/ver002/Archives/jun2003.ppt
John Roth
John Roth
"Edward Berard" <e...@toa.com> wrote in message
news:140720040412471981%e...@toa.com...
[snip]
I sometimes wonder how it's possible to miss the obvious,
until I miss it again and again. The obvious isn't always.
There is one vast and glaring difference between software
development cira 1970 and software development cira
2004.
In 1970 the overwhelming majority of us were developing
software in environments where you got one compile and
test cycle a day - if you were lucky. There were a few
exceptions, but they didn't affect the majority, and they
didn't influence "standard development methodology."
In 2004, the overwhelming majority of software development
is done on personal workstations where you have an
edit, compile and test cycle that's measured in minutes.
Until you (and everyone else) deals with the effects
that one simple and blindingly obvious difference has
on appropriate software development methodology,
nothing else is going to make sense.
The "standard" development methodology out there
was an appropriate way of dealing with an environment
where you could get one compile and test a day. It leads
to late and over budget projects, burned out developers,
dissatisfied users and buggy products. This isn't recent,
it did that in 1970 too. If anything, the situation is marginally
better today than it was then.
It's completely inappropriate for an environment where
you can get an edit, compile and test cycle in a couple
of minutes.
John Roth
Phlip
> Edward's been at this stand for a while, and I think he missed
> the point in this presentation as well (from the June 17, 2003
> meeting of Atlanta Spin)
>
> http://www.cc.gatech.edu/SPIN/ver002/Archives/jun2003.ppt
You can't judge a book by its cover, Ed.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Phlip
> If there is anything at all new-ish, it's that the worldwide pool of
> software developers is 100x larger now than it was circa 1980, and
> though there was never any lack of people looking for the silver
> bullet of magical technology/methodology, I think that such magical
> solutions are more supported by practitioners today, for whatever
> psycho-socio-economic-anthropological reasons.
I visited an XP team once, doing their quilting bee thing. They were sitting
in a ring around pair stations, with two keyboards and mice each. I don't
think they had these ergonomic factors in the 1970s.
They integrated every 10 to 90 minutes. They had their iteration tasks
written on posters on the walls around them. They all used test first,
refactoring, etc.
They had one stretch of whiteboard, devoted to two "bugs". One was a request
that a certain operation run faster, and the other covered an omission in an
off-the-shelf library.
The team was only 6 months old. They had satisfied a greenfield project,
with very high level engineering requirements, at a much faster velocity and
lower bug rate than their company had ever experienced before.
_None_ of this was around 30 years ago. Many pieces, of course, were there.
But the results - high velocity and low bug rate - certainly weren't.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Phlip
> Phlip wrote:
> >In practice, one runs the tests every 1~10 edits, trending toward 1. But
one
> >integrates every 10 to 90 minutes, trending toward the 90.
> >
> >Please try to tell us that running tests so often is bad, or
> >micromanagement, or something we did with punched cards in the 1970s.
>
> It's bad.
Running tests frequently is bad.
Running tests after the fewest possible edits is bad.
Running tests and successfully predicting the result of each run is bad.
Running tests and frequently predicting a green bar is bad.
I don't think even Ed would agree here.
I can't read more. You aren't serious.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
JXStern
>> >Please try to tell us that running tests so often is bad, or
>> >micromanagement, or something we did with punched cards in the 1970s.
>>
>> It's bad.
>
>Running tests frequently is bad.
Running tests too frequently is a waste of time and breaks the
developers concentration, which can have even a greater cost.
>Running tests after the fewest possible edits is bad.
It is trivial to show that the optimal plan is to run tests after the
greatest possible number of edits. The problem is knowing just what
number balances cost and benefits. The smallest number is unlikely to
be that number, at least *all* of the time.
Probably half my builds and test regressions are because I need a
break and the process is automated and looks productive, but that's
rather a different emphasis than you give things.
>Running tests and successfully predicting the result of each run is bad.
I don't know that one "predicts" the result of a test.
>Running tests and frequently predicting a green bar is bad.
Sometimes I prefer to predict a blue arch.
>I can't read more. You aren't serious.
Get your glasses checked, and don't call me Shirley.
J.
Phlip
> Phlip wrote:
> >> >Please try to tell us that running tests so often is bad, or
> >> >micromanagement, or something we did with punched cards in the 1970s.
> >>
> >> It's bad.
> >
> >Running tests frequently is bad?
OOoh, I can't resist! Not when the DOD has joined Microsoft and Time
Ragazine to use XP!
http://www.stsc.hill.af.mil/crosstalk/2004/07/index.html
http://www.stsc.hill.af.mil/crosstalk/2004/07/0407Starrett.html
http://www.stsc.hill.af.mil/crosstalk/2004/07/0407Top5_OneSAF.html
Just oooone more flame, and that's ALL!
> Running tests too frequently is a waste of time and breaks the
> developers concentration, which can have even a greater cost.
Don't blame your slow tests on us micromanagers!!!
<snip, unread>
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
fletch
>
> >Mythology is a tool that humans have used for centuries to "explain"
>
Whaddya got?
Phlip
> Ronald E Jeffries wrote:
> > Edward Berard wrote:
> >
> > >Mythology is a tool that humans have used for centuries to "explain"
> >
> > What I'm wondering is just what myths you are working to bust?
>
> Whaddya got?
The myth that XP relies on myths to propagate?
Just some background: Berard tried to name his own version of Waterfall
after himself - BOOM - and then propagate it. Because processes that rely on
a select few "architects" to design things, up front, add amazing risk,
anybody who can't BOOM as well as Berard goes bust.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
JXStern
>> >> >Please try to tell us that running tests so often is bad, or
>> >> >micromanagement, or something we did with punched cards in the 1970s.
>> >>
>> >> It's bad.
>> >
>> >Running tests frequently is bad?
>
>OOoh, I can't resist! Not when the DOD has joined Microsoft and Time
>Ragazine to use XP!
>
>http://www.stsc.hill.af.mil/crosstalk/2004/07/index.html
>http://www.stsc.hill.af.mil/crosstalk/2004/07/0407Starrett.html
?
>http://www.stsc.hill.af.mil/crosstalk/2004/07/0407Top5_OneSAF.html
Integration every eight weeks, dude.
>Just oooone more flame, and that's ALL!
>
>> Running tests too frequently is a waste of time and breaks the
>> developers concentration, which can have even a greater cost.
>
>Don't blame your slow tests on us micromanagers!!!
"Too frequent" is the problem, Torchboy.
><snip, unread>
Keep doing that, it's what you're good at.
J.
fletch
> "Edward Berard" <e...@toa.com> wrote in message
> news:140720040412471981%e...@toa.com...
>
> [snip]
>
> software in environments where you got one compile and
> test cycle a day - if you were lucky. There were a few
> exceptions, but they didn't affect the majority, and they
> didn't influence "standard development methodology."
I was watching Sesame Street in 1970. At the time I saw a guy with a
broken arm try to race someone else climbing up a tree. He fell from
about 30 feet up, he went too far out on the branch he was hanging
from, hit a couple more branches on the way down. Did I mention he
already had a broken arm?
>
> In 2004, the overwhelming majority of software development
> is done on personal workstations where you have an
> edit, compile and test cycle that's measured in minutes.
But we still have staff meetings once a week. It's possible to write
a plan in an agile way, using agile communication channels. I'm sure
some folks did it agile in 1970, in the same way we still work today
using extremely narrow communication channels.
>
> Until you (and everyone else) deals with the effects
> that one simple and blindingly obvious difference has
> on appropriate software development methodology,
> nothing else is going to make sense.
I can compile 500 times a day if I chose, yet still cannot just walk
in and talk to the developer across the hall. That channel is not
available, it's mined. Just like they mined the customer channel.
>
> It's completely inappropriate for an environment where
> you can get an edit, compile and test cycle in a couple
> of minutes.
But if they could compile once a day, couldn't they show a feature
once every couple days?
Nick Landsberg
> JXStern wrote:
>
>
>>Phlip wrote:
>
>
>>>>>Please try to tell us that running tests so often is bad, or
>>>>>micromanagement, or something we did with punched cards in the 1970s.
>>>>
>>>>It's bad.
>>>
>>>Running tests frequently is bad?
>
>
> OOoh, I can't resist! Not when the DOD has joined Microsoft and Time
> Ragazine to use XP!
>
> http://www.stsc.hill.af.mil/crosstalk/2004/07/index.html
> http://www.stsc.hill.af.mil/crosstalk/2004/07/0407Starrett.html
> http://www.stsc.hill.af.mil/crosstalk/2004/07/0407Top5_OneSAF.html
>
Speaking of micromanagement, and especially
since DOD is mentioned above ... and, to
put a slightly non-techie but hopefully
humorous twist to this discussion ...
One nightmare which I have when I consider TDD
is how bureaucrats and the "process police" might
twist it around.
I can just envision something like this in a process
document (cue "Twilight Zone Theme" here):
<start fictional document excerpt>
Every development shall use TDD. Becuase TDD is
a "test first" methodology, no one shall
be permitted to code until they have submitted
the failed results of the first test for approval
using Electronic Form Q3942-A - "Initial Test
Failure Report" (latest revision).
The supervisor (or supervisor's delegate as designated
on form D1732-P - "Partial Delegation of Authority") shall
file an approval using EForm Q3942-B "Initial Test Failure
Approval". Only upon receipt of EForm Q3942-B shall the
developer proceed with any coding.
The results of each subsequent test must be recorded on
either EForm Q3944-A - "Report of Intermediate Failed Test Results"
or EForm Q3944-B - "Report of Intermediate Successful
Test Results" and filed in the project's test report repository
as defined in document TR1732 - "Requirements for Test
Report Repository."
No one shall be permitted to submit
any code to the system integration team until
such time as all forms Q3944-A have been reviewed
by their supervisor (or supervisor's designated delegate),
at which time said supervisor (or supervisor's
designated delegate) shall file EForm Q3947. ...
[In a different document]
... Our methodology requires developer testing
at periods ranging from 10 to 90 minutes.
The number of forms Q3944-A submitted by
each developer will be tracked and deviations
from the expected norm (as defined in document
QM737 - "Quality Metrics Management") shall be investigated
by the supervisor (or the supervisor's designated delegate)
and reported using form Q9132, along with an explanation as
to why the deviation occurred. ...
etc., etc. ... ad nauseum.
<end document excerpt>
(Now you can turn off the "Twilight Zone" theme music. :)
If you think this is farfetched, yes. I exagerrated
a bit, but not a whole lot when you consider a
bureaucracy as large as the DOD.
In my opinion, such bureaucratic BS as above would effectively
negate any and all benefits from following TDD.
(It would take longer to file the friggin' electronic paperwork
than to run the tests!)
If you don't think this could happen, you haven't
worked in a large company. :) It is a danger both
to be aware of and beware of. Especially so if your
shop is going out after something like TL9000 certification
where you have to document your process and prove
that you are following the process.
(By the way, as I have stated before. I am neither a proponent
nor opponent of TDD. In my opinion it has a certain appeal,
but I have just not gotten my head around how it scales
to large developments, e.g. > 25 develepors, and where
compiles take hours rather than seconds, so I reserve
the right to be a skeptic :)
NPL
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Phlip
> I was watching Sesame Street in 1970. At the time I saw a guy with a
> broken arm try to race someone else climbing up a tree. He fell from
> about 30 feet up, he went too far out on the branch he was hanging
> from, hit a couple more branches on the way down. Did I mention he
> already had a broken arm?
That sounds a little violent for Sesame Street, but then they were ahead of
their time with Ernie & Bert's domestic partnership situation...
I saw the first episode the first time it aired, before Big Bird had a
forehead.
> I can compile 500 times a day if I chose, yet still cannot just walk
> in and talk to the developer across the hall. That channel is not
> available, it's mined. Just like they mined the customer channel.
Get out of my office I'm working!
> But if they could compile once a day, couldn't they show a feature
> once every couple days?
No. Track the cost-benefit ratios.
If the cost of one compile and test run is higher than the cost of reading
source, drawing diagrams, and designing, then doing the latter increases the
benefits of the former.
However, modularity lowers the costs of incremental tests. If TDD generated
your one little module - say 200 punched cards - and if you have a card
reader on your desk, then you could develop that module by running only its
tests, not everyone's tests. This would raise the cost of integration, so XP
in general is still impossible with punched cards.
All those situations skew the results in favor of heroism. Those capable of
extracting the maximum value from each compilation get rewarded.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
fletch
So 25 years ago you did agile. I believe you. So did I. But could
you have put up a headline or not buried your attack in a
pre-supposition, giving Mr P. a far too easy opportunity to practice
Gentle Art Syntonics :-) , but ah I see you are just drawing them
out...well that's pure genius
Phlip
Stop it! You're scaring me!
> No one shall be permitted to submit
> any code to the system integration team until
> such time as all forms Q3944-A have been reviewed
> by their supervisor (or supervisor's designated delegate),
> at which time said supervisor (or supervisor's
> designated delegate) shall file EForm Q3947. ...
>
> [In a different document]
> ... Our methodology requires developer testing
> at periods ranging from 10 to 90 minutes.
> The number of forms Q3944-A submitted by
> each developer will be tracked and deviations
> from the expected norm (as defined in document
> QM737 - "Quality Metrics Management") shall be investigated
> by the supervisor (or the supervisor's designated delegate)
> and reported using form Q9132, along with an explanation as
> to why the deviation occurred. ...
>
> etc., etc. ... ad nauseum.
>
> <end document excerpt>
>
> (Now you can turn off the "Twilight Zone" theme music. :)
I can't! I'm turning into Bob Geldof in the movie "The Wall"! I put on the
uniform! I take the stage! I salute the hammer flags!! and I ... I ...
[TTTO "California Uber Alles" by the Dead Kennedys]
(with a steady march beat..)
I am Phlip, and I'm here to say
Your regime will change today.
Your every edit.. you.. will.. test.
Only work 8 hours a day.
Make the corporations pay.
Users tell you what to do.
And your pair will like it too!
Agility-ya, Uber Alles
Agility-ya, Uber Alles
Uber Alles, Agility-ya
Uber Alles, Agility-ya
Design is dead long live design.
Merciless refactoring.
You will never own your code.
Frequently changing your mode.
Close your eyes can't happen here:
Extreme consultants drawing near!
Analysis will come back you say?
Test & code or you will pay.
Test & code or you will pay!
Agility-ya, Uber Alles
Agility-ya, Uber Alles
Uber Alles, Agility-ya
Uber Alles, Agility-ya
(slowly)
Now it's two thou-zand and four.
Knock knock at your front door.
The Agile Aliance's Secret Police
Bringing snacks that you must eat!
Worshipping simplicity.
Bow before the Great Yagni.
You can code up more tomorrow
Send a release from your white tower!
Can't analyze you go to fast;
All you need is "All Tests Passed"!
You'l be sacked you little schlep
When you mess with Dictator Beck.
When you mess with Dictator Beck!
Agility-ya, Uber Alles
Agility-ya, Uber Alles
Uber Alles, Agility-ya
Uber Alles, Agility-ya
> If you think this is farfetched, yes. I exagerrated
> a bit, but not a whole lot when you consider a
> bureaucracy as large as the DOD.
> In my opinion, such bureaucratic BS as above would effectively
> negate any and all benefits from following TDD.
> (It would take longer to file the friggin' electronic paperwork
> than to run the tests!)
On a lighter note, modern infantry divisions are the epitome of agility.
They deploy in small teams, target specific short-term objectives, and use
constant radio feedback to adapt a swatch of potential plans to actual
battlefield situations.
I suppose they could use a better "OnsiteCustomer" concept...
> (By the way, as I have stated before. I am neither a proponent
> nor opponent of TDD. In my opinion it has a certain appeal,
> but I have just not gotten my head around how it scales
> to large developments, e.g. > 25 develepors, and where
> compiles take hours rather than seconds, so I reserve
> the right to be a skeptic :)
Scaling is the point. All the published TDD tutorials, including my own,
show <3kloc projects. TDD throws down after the feature count goes over a
few hundred points, but new features are /easier/ to add than the first few.
Thats why you hear the detractors constantly whine "yeah, you guys just do
small projects, so you think it works". If a project packs full of features,
but doesn't _feel_ big... darn.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
fletch
> On Thu, 15 Jul 2004 03:16:25 GMT, "Phlip" <phli...@yahoo.com> wrote:
> >> >Please try to tell us that running tests so often is bad, or
> >> >micromanagement, or something we did with punched cards in the 1970s.
> >>
> >> It's bad.
> >
> >Running tests frequently is bad.
>
> Running tests too frequently is a waste of time and breaks the
> developers concentration, which can have even a greater cost.
>
> >Running tests after the fewest possible edits is bad.
>
> It is trivial to show that the optimal plan is to run tests after the
> greatest possible number of edits. The problem is knowing just what
You're both doing similar things. A lot of edits is a continuity for
Mr. Stern and creates focus, little edits and tests is a continuity
and creates focus for Mr. Phlip.
Discontinuity for Mr. Stern is running tests, however, Mr. Phlip
simply experiences increased focus (needs more focus) in having to
patch together a distributed gob of code because nothing is testable.
So the pattern for Mr. Stern is focus-break-focus-break-focus-go-home,
the pattern for Mr Phlip is focus-focus-focus-focus-go-home.
Mr. Stern, you appear to be taking far to many breaks--now get back
to work.
Nick Landsberg
> Nick Landsberg wrote:
>
[Many attempts at humor by both of us snipped :) ]
>
>
> Scaling is the point. All the published TDD tutorials, including my own,
> show <3kloc projects. TDD throws down after the feature count goes over a
> few hundred points, but new features are /easier/ to add than the first few.
>
Now this claim I will wholeheartedly endorse! (If the original
system were decently designed in the first place, but that's
another discussion.)
Using a really trivial example -
Requirement: Add a new user-class ("coffee-club administrator")
and a set of permissions for that user-class.
My first thought (with or without the discipline of TDD)
would be to run the current code and try to specify user
"joe" as belonging to that new user class. It had better fail!
I will not bore the readership with the followup steps to
that. I'm sure we're all aware of them.
NPL
> Thats why you hear the detractors constantly whine "yeah, you guys just do
> small projects, so you think it works". If a project packs full of features,
> but doesn't _feel_ big... darn.
>
--
fletch
> fletch wrote:
>
> > Ronald E Jeffries wrote:
>
> > > Edward Berard wrote:
> > >
> > > >Mythology is a tool that humans have used for centuries to "explain"
> > >
> > > What I'm wondering is just what myths you are working to bust?
> >
> > Whaddya got?
>
> The myth that XP relies on myths to propagate?
Ah, then I'll just rebel against the myth that there is a myth that
XP relies on myths. Nobody seems to have pissed in that corner of the
room yet...
> Just some background: Berard tried to name his own version of Waterfall
> after himself - BOOM - and then propagate it. Because processes that rely on
> a select few "architects" to design things, up front, add amazing risk,
> anybody who can't BOOM as well as Berard goes bust.
Can you blame him? He's just doing what everyone else is--trying to
reinvent their profession.
fletch
> fletch wrote:
>
[...]
>
> > But if they could compile once a day, couldn't they show a feature
> > once every couple days?
>
> No. Track the cost-benefit ratios.
>
> If the cost of one compile and test run is higher than the cost of reading
> source, drawing diagrams, and designing, then doing the latter increases the
> benefits of the former.
>
> However, modularity lowers the costs of incremental tests. If TDD generated
> your one little module - say 200 punched cards - and if you have a card
> reader on your desk, then you could develop that module by running only its
> tests, not everyone's tests. This would raise the cost of integration, so XP
> in general is still impossible with punched cards.
>
> All those situations skew the results in favor of heroism. Those capable of
> extracting the maximum value from each compilation get rewarded.
Please expand on this to the problem of why we still don't do XP with
unlimited compile and test.
Say it's a real expensive proposition to do budgets, so those who can
extract maximum yield from budget process gets rewarded. Planning is
rewarded.
But then, senior mgmt doesn't care about the CPU cycles used up by
all your compiles, so they have no appreciation for such things.
They care about expensive things. Value==how much something costs.
Where does it leave you if you bring the cost of delivering the same
value under their radar screens, with a different business
proposition, with open source, or just a halfway-reasonable
implementation?
How do I justify my salary if implementations aren't going to cost
much, if anything, and don't require the complex big ticket
proprietary monolithic drag-n-drop SOA-hype-driven middleware
technology that failed recently.
Phlip
> Please expand on this to the problem of why we still don't do XP with
> unlimited compile and test.
Who's "we"?
> Say it's a real expensive proposition to do budgets, so those who can
> extract maximum yield from budget process gets rewarded. Planning is
> rewarded.
>
> But then, senior mgmt doesn't care about the CPU cycles used up by
> all your compiles, so they have no appreciation for such things.
> They care about expensive things. Value==how much something costs.
> Where does it leave you if you bring the cost of delivering the same
> value under their radar screens, with a different business
> proposition, with open source, or just a halfway-reasonable
> implementation?
>
> How do I justify my salary if implementations aren't going to cost
> much, if anything, and don't require the complex big ticket
> proprietary monolithic drag-n-drop SOA-hype-driven middleware
> technology that failed recently.
Ask JXStern!
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Edward Berard
Jeffries <ronje...@acm.org> wrote:
> On Wed, 14 Jul 2004 04:12:47 -0500, Edward Berard <e...@toa.com> wrote:
>
> >Mythology is a tool that humans have used for centuries to "explain"
> >things that they do not understand. Today's agile advocates have
> >assembled a large number of myths to explain away some things that
> >they obviously do not understand, or have chosen to ignore.
> >
> > -- Ed
> >
> >P.S.: Please note that my emphasis here is the way non-agile approaches
> > are characterized by agile advocates. I am purposely avoiding
> > a discussion on the merits of any particular agile technique or
> > methodology.
>
> Ed,
>
> Your history is reminiscent of mine. What I'm wondering is just what
> myths you are working to bust?
Ron,
First, let me distinguish between "Agile" (with an upper-case "A") and
"agile" (with a lower-case "a").
-> "Agile" (with an upper-case "A") refers to those approaches
favored by the "Agile Alliance," regardless of whether the
approaches actually result in better software, or any other
of their promised benefits.
-> "agile" (with a lower-case "a") refers to approaches that
can accommodate change with relative ease, without unduly
sacrificing reliability, efficiency, modifiability,
understandability, and other desirable software characteristics.
Sometimes these two different "agiles" can accurately be used to refer
to the same thing. Sometimes each of the two "agiles" cost roughly the
same to execute. Still, there are frequently large differences in their
respective costs and effectiveness.
Here are a few myths that I would like to see busted:
-> Non-Agile approaches, by definition, do not accommodate changes
very well.
-> Non-Agile approaches, by definition, do not seriously consider
testing until very late in the development/enhancement effort.
-> Non-Agile approaches, by definition, do not use automated testing
tools and techniques.
-> Non-Agile approaches, by definition, do not check for extraneous
features.
-> Non-Agile approaches, by definition, seek out complex "solutions"
as opposed to simple, straightforward, and inexpensive solutions.
-> Non-Agile approaches, by definition, discourage effective and
pragmatic communication among management, technical staff, the
customer, and others.
-> Non-Agile approaches, by definition, discourage group ownership
and group responsibility.
-> Non-Agile approaches, by definition, ignore the human element
in team building, testing, management, and the entire software
engineering effort.
-> Non-Agile approaches, by definition, do not allow for tailoring.
-- Ed
Phlip
> Here are a few myths that I would like to see busted:
Experience is inadequate to bust nearly anything, but here goes.
> -> Non-Agile approaches, by definition, do not accommodate changes
> very well.
The Agile approaches I have seen make source that can't accommodate changes
extraordinarily unlikely.
> -> Non-Agile approaches, by definition, do not seriously consider
> testing until very late in the development/enhancement effort.
> -> Non-Agile approaches, by definition, do not use automated testing
> tools and techniques.
In my experience, no project had automated tests before I started learning
TDD. (My experience is pathetic.)
The reader is advised to learn how comparisons work in tutorials. Comparing
Agility to quasi-agile systems is weak. Comparing them to their anitpodes is
useful. Agile literature, that I have read, does not say "all projects
before Agility never tested".
Citation?
> -> Non-Agile approaches, by definition, do not check for extraneous
> features.
Again, you are making up a "definition" for something the Agile literature
declines to define.
> -> Non-Agile approaches, by definition, seek out complex "solutions"
> as opposed to simple, straightforward, and inexpensive solutions.
In this case, they do. When an analyst proposes a high-level solution to the
client, without code, this challenges the client to understand OO goodies.
If the analyst can point to inputs going in here, in a format the client
understands, and similar outputs there, the client may nod. But that
diagram, by nature, obscurred the opportunities for simplification that
implementing stories in a client-specified order could have found.
I'm not saying such procedures are exclusive, either. I'd rather have
"implement stories in a client-specified order" in the books, though, more
prominently.
Practitioners of TDD reliably report surprise how soon a design stops
changing, and supports new features (of the same kind) as extensions.
> -> Non-Agile approaches, by definition, discourage effective and
> pragmatic communication among management, technical staff, the
> customer, and others.
>
> -> Non-Agile approaches, by definition, discourage group ownership
> and group responsibility.
>
> -> Non-Agile approaches, by definition, ignore the human element
> in team building, testing, management, and the entire software
> engineering effort.
>
> -> Non-Agile approaches, by definition, do not allow for tailoring.
You could take any book advising any practice, and accuse it of apply the
"non-X approaches, by definition, do not advise what we advise" template.
How else could a book describe its goals?
What, besides promoting XP, is the point of this experiment? Could some book
about Agility possibly appease you by leaving out all its contrary examples,
or would you react only to the word "Agile" on its cover?
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Ilja Preuß
> -> "Agile" (with an upper-case "A") refers to those approaches
> favored by the "Agile Alliance," regardless of whether the
> approaches actually result in better software, or any other
> of their promised benefits.
Could you please elaborate on what you mean by this?
That is, what would a process look like that
- seriously considers testing before very late in the
development/enhancement effort,
- uses automated testing tools and techniques,
- checks for extraneous features,
- seeks out simple, straightforward, and inexpensive solutions,
- encourages effective and pragmatic communication among management,
technical staff, the customer, and others,
- encourages group ownership and group responsibility
- addresses the human element in team building, testing, management, and the
entire software engineering effort, and
- allows for tailoring
and wouldn't be called Agile?
Thanks!
John Roth
> In article <fk4af0d32or1pgt02...@4ax.com>, Ronald E
> Jeffries <ronje...@acm.org> wrote:
>
> > On Wed, 14 Jul 2004 04:12:47 -0500, Edward Berard <e...@toa.com> wrote:
> >
> > >Mythology is a tool that humans have used for centuries to "explain"
> > >things that they do not understand.
Not a good definition of the term as it's used professionally, but it'll
do for today.
> > >Today's agile advocates have
> > >assembled a large number of myths to explain away some things that
> > >they obviously do not understand, or have chosen to ignore.
Which agile advocates. Please be specific.
> > >
> > > -- Ed
> > >
> > >P.S.: Please note that my emphasis here is the way non-agile approaches
> > > are characterized by agile advocates. I am purposely avoiding
> > > a discussion on the merits of any particular agile technique or
> > > methodology.
> >
> > Ed,
> >
> > Your history is reminiscent of mine. What I'm wondering is just what
> > myths you are working to bust?
>
> Ron,
>
> First, let me distinguish between "Agile" (with an upper-case "A") and
> "agile" (with a lower-case "a").
>
> -> "Agile" (with an upper-case "A") refers to those approaches
> favored by the "Agile Alliance," regardless of whether the
> approaches actually result in better software, or any other
> of their promised benefits.
>
> -> "agile" (with a lower-case "a") refers to approaches that
> can accommodate change with relative ease, without unduly
> sacrificing reliability, efficiency, modifiability,
> understandability, and other desirable software characteristics.
>
> Sometimes these two different "agiles" can accurately be used to refer
> to the same thing. Sometimes each of the two "agiles" cost roughly the
> same to execute. Still, there are frequently large differences in their
> respective costs and effectiveness.
>
> Here are a few myths that I would like to see busted:
Before I deal with each of these points independently, I'd like to
make a global comment. These things are phrased in such
a way that they can't be successfully contradicted, since a single
example, no matter how atypical, would be enough to demonstrate
your point.
If I was into scoring rhetorical points, I could stop right here.
However, since I'm not, I'll continue on and comment on some
of the actual issues.
> -> Non-Agile approaches, by definition, do not accommodate changes
> very well.
The key here is the phrase "very well." What's "well enough?" I'd
contend that a sufficiently nimble approach is one that ends with
a system that meets the customer's needs, and hasn't had to dump
lots of change requests because they would be too hard to do,
too expensive, or were presented too late in the development
cycle. Also, it doesn't passively discourage change requests because
"everybody knows" that they won't be accepted, so why go through
the motions.
Now, this is obviously open to discussion. However, when I match
up the XP approach to change requests to that of other processes
I've seen, the difference is drastic. In XP, a feature request (a story)
is in one of three statuses: pending, being worked on, or complete.
"Being worked on" is one to three weeks. If it's pending, a change
to it costs as close to nothing as possible, considering that there is
some record keeping, discussion and investigation involved. In
particular, there's no preexisting design document or requirements
document that needs to be changed.
If it's complete, then a change to it costs whatever it would have
cost to do it that way in the first place.
This last point needs a bit of expansion. One of the key points in
XP is that the work product must be kept at the same level of
design integrity for the entire length of the project. In other words,
"bit rot" or "code degradation" or whatever you want to call it
are not allowed to occur. That takes a radically different approach
than the typical one of defining and the building the defined product.
The summary point here is that in XP, change is regarded as normal,
and the product itself is crafted to allow change at any point in the
project, while in most other formal methodologies I've seen change
is regarded as something that has to be carefully managed (hence the
common term "change management.")
> -> Non-Agile approaches, by definition, do not seriously consider
> testing until very late in the development/enhancement effort.
The key phrase is "consider". Most places I've worked, I've had to do
a "test plan" as part of either the requirements or the design document.
That's sufficient to motivate the use of the word "consider."
In those same shops, I've usually done unit testing immediately after
completing writing the unit involved. However, integration testing
and all the other testing happened later, sometimes very much later.
I would consider that typical, but it's by no means universal in
either direction. Microsoft is probably the best known example
of a company that does daily integration, and which makes an
attempt to insure that the daily builds pass some level of testing.
They also have to take relatively leasurely alpha and beta test
cycles to get the product up to production quality.
XP (as well as other Agile approaches) take the stand that the
result of each iteration (sprint, heartbeat, whatever you want to
call it) is a production quality deployable.
Being able to finish each and every work session with your work
product completely integrated and tested to production quality is
sufficiently different from *any* other process I have ever heard
of that I find it baffling how anyone could think that standard
methodologies are comparable. (That's XP, by the way, not other
Agile methodologies.)
> -> Non-Agile approaches, by definition, do not use automated testing
> tools and techniques.
Huh? I have no idea where this comes from. The claim isn't
that they don't. The claim is that they don't insist on 100.0%
automated and repeatable tests.
Manual testing is endemic. Even in shops where I automated my
unit testing, I sometimes had quite a difficult time managing to check
in the test scripts and get other people to use them.
> -> Non-Agile approaches, by definition, do not check for extraneous
> features.
Again, I don't know where this comes from. There are certainly
shops that do, but "feature creep" and "feature bloat" is so common
that those are standard industry terms.
> -> Non-Agile approaches, by definition, seek out complex "solutions"
> as opposed to simple, straightforward, and inexpensive solutions.
I've seen both. However, one measure I've seen quoted is that
45% (approximately) of the features in a typical application are
not used, and another 26% are seldom used. I don't take this to
mean that there is a pervasive practice to pare systems down to
just what's necessary to meet the real needs of the customer.
That doesn't mean that some shops don't do this. I expect that
some do.
> -> Non-Agile approaches, by definition, discourage effective and
> pragmatic communication among management, technical staff, the
> customer, and others.
In my years in the industry, I've been in all types of communication
environments, from ones where I've been actively prevented from
talking to the people who knew what they wanted, to ones where
I was more or less grudgingly allowed. I've never been in an
environment (other than agile environments) where there was a
domain expert and business expert on site to answer questions
and make sure the effort was going in the right direction.
> -> Non-Agile approaches, by definition, discourage group ownership
> and group responsibility.
Well, it depends on what you mean by "group ownership." In XP,
it means that anyone can change any piece of code at any time if
it's needed for the work they're doing.
I've been in a lot of environments where anyone could be assigned
to work on anything in the unit, however that didn't mean that we
had the authority (let alone the expectation) of changing something
that someone else was working on without negotiating with them.
> -> Non-Agile approaches, by definition, ignore the human element
> in team building, testing, management, and the entire software
> engineering effort.
Some of them certainly seem to be designed for R. Daniel Olivaw.
Again, though, that's all over the map.
> -> Non-Agile approaches, by definition, do not allow for tailoring.
Huh? Tailoring what?
To summarize, in a couple of your bullet points, I think the XP
practice is sufficiently different from the overwhelming majority
of practice that "by definition" is possibly a good term.
In the rest of the cases, I simply don't know where you're coming
from. The statements are simply not true in my experiance, and I
know of no one that seriously claims that they are.
John Roth
Phlip
> That is, what would a process look like that
> - seriously considers testing before very late in the
> development/enhancement effort,
> - uses automated testing tools and techniques,
> - checks for extraneous features,
> - seeks out simple, straightforward, and inexpensive solutions,
> - encourages effective and pragmatic communication among management,
> technical staff, the customer, and others,
> - encourages group ownership and group responsibility
> - addresses the human element in team building, testing, management, and
the
> entire software engineering effort, and
> - allows for tailoring
> and wouldn't be called Agile?
He means lots of projects were agile before Agile, and implies that all the
Agile books claim they were not. /Argumentum ad argumentum/.
When describing agility for GUI projects, I put this as neutrally as
possible:
"Without Agile practices, software engineering projects fall along an axis,
with excessive planning at one end, and undisciplined hacking at the other.
GUI implementation trends towards 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 axis. 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 and high bug
rate. That permits teams to become useful early, and then add value
incrementally."
Notice I said "Without Agile practices". With the caps. I did not say
"before the Agile Alliance met". (And I don't strictly "believe in" the
Agile Alliance, but it's mostly harmless.)
I'm certain he has not tried TDD yet personally. It really is an innovation.
Uncle Bob just posted this comparison:
"Finding your balance is an interesting journey. When I first saw TDD
done (Kent and I did a little pair programming in 1999.) I was
flabbergasted at how tiny the cycles were. I refused to believe that
such tiny cycles were necessary. However, I'm also an amateur martial
artist; and one of the things they teach you very early in Martial
arts is to imitate the teacher without question until you are sure you
know what questions to ask.
"So for several months I tried to keep my cycles as small as Kent's
were. That was hard, and took a lot of practice. Eventually I got
pretty good at it. Then I started "feeling my oats" and decided to
play with the cycle length. I found that when I made the cycle length
longer than a few minutes I got caught in nasty situations where
sometimes I wasn't able to test for 30 min to an hour. I found that I
needed to pull out the debugger and step my way through a tangle. So
I shortened my cycles back up. Since then I've been finding my cycles
getting shorter and shorter; and I don't find that it takes any longer
to do it that way."
If Uncle Ed would post, "I tried TDD, in very short cycles, with its
designing goals, and I..." he would boost his credibility.
If Uncle Ed instead insists on posting "I know enough about martial arts I
don't need to actually learn it, much less try to match what my instructor
does", then his complaints are not worth replying to.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Scott Kinney
"Ilja Preuß" <i...@iljapreuss.de> wrote in message
news:40fad7f5$1...@news.totallyobjects.com...
Actually, any sensible project manager uses this process
regardless of their religion, oops, software development
methodology.
Phlip
> > > Edward Berard wrote:
> > > >Today's agile advocates have
> > > >assembled a large number of myths to explain away some things that
> > > >they obviously do not understand, or have chosen to ignore.
>
> Which agile advocates. Please be specific.
Me! Me me me!
> Now, this is obviously open to discussion. However, when I match
> up the XP approach to change requests to that of other processes
> I've seen, the difference is drastic. In XP, a feature request (a story)
> is in one of three statuses: pending, being worked on, or complete.
> "Being worked on" is one to three weeks. If it's pending, a change
> to it costs as close to nothing as possible, considering that there is
> some record keeping, discussion and investigation involved. In
> particular, there's no preexisting design document or requirements
> document that needs to be changed.
Sorting features by business priority is common to all Agile systems. They
don't just say "frequent releases".
If any programming books that don't call themselves Agile say that too,
props.
Some _do_ deny it!
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Ronald E Jeffries
You are barking up a non-tree. I suspect that no one in the big-A
Agile would deny that any small-a agile method had those flaws.
To be small-a agile, a process would almost of necessity need to do
all those thngs.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Ronald E Jeffries
not imagine that only the half-dozen named processes are small-a
agile. We generally believe that there is an infinity of agile
methods, although there are similarities.
Now then ...
On Sun, 18 Jul 2004 12:46:12 -0500, Edward Berard <e...@toa.com> wrote:
> -> Non-Agile approaches, by definition, do not accommodate changes
> very well.
If an approach does not accomodate changes well, then it is surely not
agile and would also not be Agile.
>
> -> Non-Agile approaches, by definition, do not seriously consider
> testing until very late in the development/enhancement effort.
If an approach leaves testing until the end, it is unlikely to be able
to be shipping good software from the beginning, which is a core
element of agile processes.
There could be exceptions, such as an agile process that relied on
intensive inspection rather than testing. I've never seen such a
thing, but I can imagine it.
>
> -> Non-Agile approaches, by definition, do not use automated testing
> tools and techniques.
See above.
>
> -> Non-Agile approaches, by definition, do not check for extraneous
> features.
I take this to mean that non-Agile approaches do not properly
prioritize, but I'm not sure.
In any case, there are many projects, agile and otherwise, that
prioritize. A project that does not prioritize could still be agile in
its development approach, just stupid in its selection of features.
>
> -> Non-Agile approaches, by definition, seek out complex "solutions"
> as opposed to simple, straightforward, and inexpensive solutions.
I am gritting my teeth here to keep from screaming "STRAWMAN" at the
top of my lungs.
An approach which did seek out complex solutions could not possibly be
agile in my opinion. Seeking out simple solutions is not sufficient to
agility.
>
> -> Non-Agile approaches, by definition, discourage effective and
> pragmatic communication among management, technical staff, the
> customer, and others.
An approach without effective and pragmatic communication is unlikely
to be agile.
>
> -> Non-Agile approaches, by definition, discourage group ownership
> and group responsibility.
An approach without group ownership and responsibility is less likely
to be agile.
>
> -> Non-Agile approaches, by definition, ignore the human element
> in team building, testing, management, and the entire software
> engineering effort.
Nearly every reasonable approach, agile or not, pays some attention to
the human element, often in very effective ways. It is hard to imagine
an agile approach without this characteristic.
>
> -> Non-Agile approaches, by definition, do not allow for tailoring.
Absurd accusation. Surely every agilista has studied CMM and RUP, and
knows that these approaches, whether installed in an agile fashion or
not, are required by their inventors to be tailored.
I do not see your point. No one I know believes these things. Everyone
I know believes that there are many good ways to be agile, and some of
us even believe that approaches we'd all agree to be non-agile are
sometimes appropriate.
Aside from impugning the lot os us with absurd accusations about
things we neither believe nor say, what's your point?
Jeff Grigg
> -> Non-Agile approaches, by definition, [lots of things]
I wonder where you're getting your definitions. I think that the
Agile Manifesto is the most widely accepted and appropriate definition
of what agile methodologies are. But as I read it, I see four values
that if you have all four, you're agile, while if you're missing any
one, you're not. So by that definition, a non-agile approach could
share any one to three values with agile approaches, but still be
non-agile.
_ _ _
"We are uncovering better ways of developing software by doing it and
helping others do it.
"Through this work we have come to value:
"Individuals and interactions over processes and tools
"Working software over comprehensive documentation
"Customer collaboration over contract negotiation
"Responding to change over following a plan
"That is, while there is value in the items on the right, we value the
items on the left more."
_ _ _
So a non-agile approach could value Individuals and Interactions,
Working Software, and Customer Collaboration, but insist on Following
a Plan rather than Responding to Change. Another non-agile approach
could value Responding to Change, but focus on Processes and Tools
over Individuals and Interactions." Both would be non-agile -- in
different ways.
So I have a hard time saying that *all* non-agile approaches share
properties A, B, C, D, E, etc... ...as there are so many different
ways to get it wrong. ;->
Scott Kinney
>
>
> If Uncle Ed instead insists on posting "I know enough about martial arts I
> don't need to actually learn it, much less try to match what my instructor
> does", then his complaints are not worth replying to.
>
Actually Uncle Ed is posting (and I'll continue the martial arts metaphor)
"Please stop telling me you invented the jab. You didn't. If you have
insight into new
techniques or methods that will improve my jab, I'll listen. Have a little
respect, though. I've hit people with a jab before, and I know it works.
Lessons
that start by claiming jabs thrown without your special technique were
worthless will not be taken seriously."
Edward Berard
Jeffries <ronje...@acm.org> wrote:
> The capital A Agile people whom I know -- and I know most of them -- do
> not imagine that only the half-dozen named processes are small-a
> agile. We generally believe that there is an infinity of agile
> methods, although there are similarities.
Good.
> Now then ...
>
> On Sun, 18 Jul 2004 12:46:12 -0500, Edward Berard <e...@toa.com> wrote:
>
> > -> Non-Agile approaches, by definition, do not seriously consider
> > testing until very late in the development/enhancement effort.
>
> If an approach leaves testing until the end, it is unlikely to be able
> to be shipping good software from the beginning,
You and I are in agreement on this point. I would, however, make the
point stronger by stipulating that:
-> Test Driven Development (TDD), as it is described in the
literature, and frequently discussed in Agile forums, is
inadequate on its own. However, if I could get people to
routinely ask themselves how they might test for the
presence or absence of a particular feature, and all
critical legal combinations of customer-requested features,
that would be a major step forward in many shops.
-> There is the matter of Kent Beck's statement, i.e.:
"How good the design is doesnšt matter near as much as whether
the design is getting better or worse. If it is getting better,
day by day, I can live with it forever. If it is getting worse,
I will die."
One might ask for a clarification on what exactly is "good
software from the beginning" in this light? (I am guessing
that it should be taken to mean "as good as we can make it
under the circumstances.")
> which is a core element of agile processes.
Are you saying that "if a process does not do TDD, then it is not
'agile' (upper or lower case 'A')?"
> There could be exceptions, such as an agile process that relied on
> intensive inspection rather than testing. I've never seen such a
> thing, but I can imagine it.
I would say that "Fagan-style inspections," along with several other
forms of inspections, are a type of testing. However, I would also
say that such inspections, on their own, are insufficient for
adequate testing of (both code and non-code) software.
> > -> Non-Agile approaches, by definition, do not use automated testing
> > tools and techniques.
>
> See above.
As someone who has designed, tested, and shipped a lot of software
(over 1,500,000 lines at last count), I cannot imagine developing
or enhancing a software product without automated testing tools.
My experiences in this area go back (literally) 30 years.
I have also spent a considerable amount of time working with
organizations, helping them set up testing policies, procedures,
tools, guidelines, and plans.
Ignoring effective use of automated testing techniques causes
serious problems as the size and criticality of the software
application increases. I have seen more than one organization
that was very reluctant to put in fixes/enhancement because they
had no automated testing, and feared undesirable side effects.
> >
> > -> Non-Agile approaches, by definition, do not check for extraneous
> > features.
>
> I take this to mean that non-Agile approaches do not properly
> prioritize, but I'm not sure.
This is another way of saying "you aren't going to need it" (YAGNI).
Of course, you can also mix in prioritization problems.
> In any case, there are many projects, agile and otherwise, that
> prioritize. A project that does not prioritize could still be agile in
> its development approach, just stupid in its selection of features.
Again, you and I are in agreement.
> > -> Non-Agile approaches, by definition, seek out complex "solutions"
> > as opposed to simple, straightforward, and inexpensive solutions.
>
> I am gritting my teeth here to keep from screaming "STRAWMAN" at the
> top of my lungs.
Greetings fellow gritter. :-)
I have exactly the same reaction when I read articles that contrast
"complex implementations" with "radical simplicity."
> An approach which did seek out complex solutions could not possibly be
> agile in my opinion. Seeking out simple solutions is not sufficient to
> agility.
> >
> > -> Non-Agile approaches, by definition, discourage effective and
> > pragmatic communication among management, technical staff, the
> > customer, and others.
>
> An approach without effective and pragmatic communication is unlikely
> to be agile.
Could an approach not recognized by the Agile Alliance, encourage
effective and pragmatic communication among management, the technical
staff, the customer, and others?
> > -> Non-Agile approaches, by definition, discourage group ownership
> > and group responsibility.
>
> An approach without group ownership and responsibility is less likely
> to be agile.
Could a non-Agile approach encourage group ownership and group
responsibility?
> > -> Non-Agile approaches, by definition, ignore the human element
> > in team building, testing, management, and the entire software
> > engineering effort.
>
> Nearly every reasonable approach, agile or not, pays some attention to
> the human element, often in very effective ways. It is hard to imagine
> an agile approach without this characteristic.
Reading the "Manifesto for Agile Software Development," one sees
the obvious emphasis that Agile approaches place on the human element.
However, I would like to think that there are "at least a few"
non-Agile approaches that also positively consider and emphasize the
human element.
> > -> Non-Agile approaches, by definition, do not allow for tailoring.
>
> Absurd accusation. Surely every agilista has studied CMM and RUP, and
> knows that these approaches, whether installed in an agile fashion or
> not, are required by their inventors to be tailored.
Would that the accusation really was absurd. Unfortunately, I keep
running into people who insist that this is not the case. Many of the
agilistas that I have encountered, who claim to be familiar with
CMM and RUP, talk about them as if the concept of tailoring does
not exist.
Both Agile and non-Agile approaches alike appear to suffer from
tailoring problems. Software practitioners, their managers, and
their customers frequently exhibit a love-hate relationship with
approaches/methodologies.
-> On one hand, they may complain about "technical straightjackets"
that unfairly restrict their "creativity." Stories of the
"process police" are yet another symptom.
-> On the other hand, when told to make their own decisions,
based on an adequate set of heuristics, many of these same people
seek out "fill-in-the-blanks" and/or "one-size-fits-all"
solutions.
Believe me, I will be making frequent use of your "agilista" quote.
> I do not see your point. No one I know believes these things. Everyone
> I know believes that there are many good ways to be agile, and some of
> us even believe that approaches we'd all agree to be non-agile are
> sometimes appropriate.
>
> Aside from impugning the lot os us with absurd accusations about
> things we neither believe nor say, what's your point?
My point is that I am still encountering people who believe these myths,
and, unfortunately, the myths form the basis of many "technical" and
managerial decisions.
Phlip
> You and I are in agreement on this point. I would, however, make the
> point stronger by stipulating that:
>
> -> Test Driven Development (TDD), as it is described in the
> literature, and frequently discussed in Agile forums, is
> inadequate on its own. However, if I could get people to
> routinely ask themselves how they might test for the
> presence or absence of a particular feature, and all
> critical legal combinations of customer-requested features,
> that would be a major step forward in many shops.
Yes. So make doing that as easy as possible.
> -> There is the matter of Kent Beck's statement, i.e.:
>
> "How good the design is doesnšt matter near as much as whether
> the design is getting better or worse. If it is getting better,
> day by day, I can live with it forever. If it is getting worse,
> I will die."
>
> One might ask for a clarification on what exactly is "good
> software from the beginning" in this light? (I am guessing
> that it should be taken to mean "as good as we can make it
> under the circumstances.")
The best feedback is gains in end user productivity.
Simple Design -> Frequent Releases -> Early Feedback.
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.
Contrarily, the temptation may arise to write code, not clean it up, and
release it. Don't. Within this system, the cost of change remains low as
each release's own code quality does not degrade. So, under the
circumstances that you should not guess (generally) what features the next
iteration will schedule, don't write proactive designs.
In practice, folks plan all the time, but not enough to cause a speedbump if
the onsite customer changes direction.
Notice: I said "within this system, the cost of change..." I did not say
"all other systems raise the cost of change curve". Within this system, if
you disturb one practice, such as refactoring to clean up the current design
before adding features, all the other practices make the cost of change
curve skyrocket.
> Could an approach not recognized by the Agile Alliance, encourage
> effective and pragmatic communication among management, the technical
> staff, the customer, and others?
If it walks like a duck, quacks like a duck...
> Reading the "Manifesto for Agile Software Development," one sees
> the obvious emphasis that Agile approaches place on the human element.
That manifesto was (past tense) an attempt at agreement among learners about
what it was they were learning.
> My point is that I am still encountering people who believe these myths,
> and, unfortunately, the myths form the basis of many "technical" and
> managerial decisions.
Does their code suck?
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Ronald E Jeffries
>> An approach which did seek out complex solutions could not possibly be
>> agile in my opinion. Seeking out simple solutions is not sufficient to
>> agility.
>> >
>> > -> Non-Agile approaches, by definition, discourage effective and
>> > pragmatic communication among management, technical staff, the
>> > customer, and others.
>>
>> An approach without effective and pragmatic communication is unlikely
>> to be agile.
>
>Could an approach not recognized by the Agile Alliance, encourage
>effective and pragmatic communication among management, the technical
>staff, the customer, and others?
The Agile Alliance does not "recognize" or otherwise bless
"approaches". Various members of the Alliance have described their own
software development approaches in varying degrees of detail, and have
sometimes given them names. These particular approaches are not
believed to be, nor are they intended to be, a complete compendium of
all possible agile approaches.
If there is a distinction to be drawn between agile and non-agile, it
would not be that agile favors effective communication and non-agile
does not: all published methods favor effective communication as far
as I know. The distinction would more likely be based in the focus on
actual running software as a key element of communication, starting
from the beginning of the project.
There is no suggestion, as your thread-starting post seemed to say,
that only agile methods desire communication, or that some
long-standing method might not have good communication.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Ronald E Jeffries
>> > -> Non-Agile approaches, by definition, discourage group ownership
>> > and group responsibility.
>>
>> An approach without group ownership and responsibility is less likely
>> to be agile.
>
>Could a non-Agile approach encourage group ownership and group
>responsibility?
In short, yes, but I need to reframe the question and context.
You have used big-A Agile here. I assume that that term is meant to be
all those and only those methods published by certain members of the
Agile Alliance and no others.
Again, there is no implication by the Alliance or its members that it
has listed all possible agile methods, or that all methods not created
by its members are non-agile, or that all methods created before some
date are non-agile, or any other such statement. The Alliance's
purpose is to support the general notion of agility.
One might also ask whether a non-agile (lower case) method could
support group ownership and responsibility. We have no agreed
definition of "non-agile", and I think we're unlikely to get one. We
might possibly come to a shared agreement on some informal metrics
whereby we could generally agree that this method (or this practice)
was more conducive to agility than that one.
In that light, we can imagine creating the least agile method we can
think of. Then we could add group ownership and responsibility to it
and still agree that it was still very close to non-agile.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Ronald E Jeffries
>> Nearly every reasonable approach, agile or not, pays some attention to
>> the human element, often in very effective ways. It is hard to imagine
>> an agile approach without this characteristic.
>
>Reading the "Manifesto for Agile Software Development," one sees
>the obvious emphasis that Agile approaches place on the human element.
>
>However, I would like to think that there are "at least a few"
>non-Agile approaches that also positively consider and emphasize the
>human element.
Again you use big-A Agile as if there were no other agile methods but
those written by the Agile Alliance and its members. This is not the
case.
There is no implication made by the Alliance or its members that other
methods, even non-agile ones, never consider the human element. I
suspect that most of us believe that many published methods offer a
different balance on this element, and other elements, than we as a
group might recommend.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Ronald E Jeffries
>My point is that I am still encountering people who believe these myths,
>and, unfortunately, the myths form the basis of many "technical" and
>managerial decisions.
I often run into people who believe that it is reasonable to expect
all software developers to "nail down requirements", "nail down the
design", "code the design", "test the code", and ship a reliable
product, containing all predicted features, on time, and on budget.
Now that's a myth worth discussing and worth removing from the mythic
pantheon.
I've never run into a senior member of the "agile community" who seems
to believe the myths you stated, and I'm not sure I've even
encountered folks who are less experienced who would support them as
you wrote them.
You myths seem to me to center on one notion: that there are big-A
Agile methods, with names, and that no other method but those could
possibly be agile.
There are surely people who believe, at least over some range of work,
that a given named method is "best". I'm aware of no one who holds to
your myths or even a few of them.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Ronald E Jeffries
>I wonder where you're getting your definitions. I think that the
>Agile Manifesto is the most widely accepted and appropriate definition
>of what agile methodologies are. But as I read it, I see four values
>that if you have all four, you're agile, while if you're missing any
>one, you're not. So by that definition, a non-agile approach could
>share any one to three values with agile approaches, but still be
>non-agile.
It depends what we mean "agile" to mean. We might mean "all those
methods which share these values, and no others". Probably a lot of us
do believe that without all those values you're not likely to get
agility.
But the word, especially in lower case, has to do with responsiveness
to change. I suppose it is possible, in principle, to have a method
that's responsive to change yet doesn't include one or more of those
values. In practice, I'd say it's quite unlikely. :)
Ronald E Jeffries
>> which is a core element of agile processes.
>
>Are you saying that "if a process does not do TDD, then it is not
>'agile' (upper or lower case 'A')?"
Perhaps we might look at my whole sentence rather than one clause:
>>If an approach leaves testing until the end, it is unlikely to be able
>>to be shipping good software from the beginning, which is a core
>>element of agile processes.
It is shipping good software from the beginning which I take to be a
core element of agile processes.
My sentence says nothing about TDD. TDD is a good practice on its own.
It is used by many developers in many situations. It is one way of
doing some of the testing practices of Extreme Programming (one
particular agile method).
I'm not sure that TDD is even "core" to XP, though it is a very strong
practice that I'd recommend to everyone.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Ronald E Jeffries
>I have exactly the same reaction when I read articles that contrast
>"complex implementations" with "radical simplicity."
Please post links to a few such articles, I'd like to read them.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Edward Berard
Jeffries <ronje...@acm.org> wrote:
> On Mon, 19 Jul 2004 10:58:40 -0500, Edward Berard <e...@toa.com> wrote:
>
> >I have exactly the same reaction when I read articles that contrast
> >"complex implementations" with "radical simplicity."
>
> Please post links to a few such articles, I'd like to read them.
Ron,
First, thank you for taking the time to respond to my questions.
I found your answers to be useful.
For some links to some "teeth-gritting articles," check out the
bibliography to my "Misconceptions of the Agile Zealots" article:
http://www.toa.com/pub/Misconceptions.zip
To see even more mythology, check out the "Agility and Classical
Software Project Management" thread in this newsgroup.
Jeff Grigg
>> Your history is reminiscent of mine. What I'm wondering is just
>> what myths you are working to bust?
--- Edward Berard <e...@toa.com> wrote in message...
> Here are a few myths that I would like to see busted:
Given my understanding of the agile community, I too would like to
poke a hole in the myths you list, popping them open like overfilled
balloons. However, if they were reworded to say non-Agile or non-XP
approaches "have generally turned out to..." then I'd probably agree
with them, rather than deny them.
_ _ _
[First, I'd like to apologize for misunderstanding your post when I
first saw it: Google is having problems, and portions of this thread
keep disappearing and reappearing. So I couldn't find the whole
thread for a while.]
_ _ _
The first and most significant problem I have with the myths, as
listed, is that they all say, "Non-Agile approaches, by
definition,...". As I see it, the definition of
"non-(capitol-A)-Agile approaches" are those that value *ONE* (or
more) of the right things over the left things in the following list.
This definition doesn't allow us to say much or conclude much about
non-Agile approaches. In effect, we can't compare Agile to non-Agile
by definition; it's only useful to compare them by how they're
implemented in the real world.
The Agile Manifesto:
http://www.agilemanifesto.org/
"[...] we have come to value:
"Individuals and interactions over processes and tools
"Working software over comprehensive documentation
"Customer collaboration over contract negotiation
"Responding to change over following a plan"
> -> Non-Agile approaches, by definition, do not accommodate changes
> very well.
This has generally been my experience. It's hard to accommodate
changes, during a development project, if you have detailed long term
plans. And it's generally hard to change existing code, and designs,
without good test plans -- preferably automated.
> -> Non-Agile approaches, by definition, do not seriously consider
> testing until very late in the development/enhancement effort.
While not absolutely true, many "phasist" approaches do emphasize a
testing phase near the end of each project.
> -> Non-Agile approaches, by definition, do not use automated testing
> tools and techniques.
This one is just silly:
Automated Regression Testing has been around for longer than I've been
in the industry (and that's a long time). Mainframe batch jobs have
been tested this way for many years.
Further, there's a large market today for automated regression testing
tools. My experience is that most projects don't use them very well,
but XP or even Agile in general could hardly claim exclusive use of
automated regression testing.
> -> Non-Agile approaches, by definition, do not check for extraneous
> features.
>
> -> Non-Agile approaches, by definition, seek out complex "solutions"
> as opposed to simple, straightforward, and inexpensive solutions.
XP, in particular, emphasizes these points more strongly than any
other approach I've ever seen. Every approach I've ever seen tries to
arrive at the simplest possible solution to any given problem. But,
as a practical matter, from what I've seen, XP delivers solutions that
are far simpler than those offered by other approaches. During
iterative development, XP routinely delivers solutions that are
simpler than necessary to meet later requirements. This saves time
and money because (1) they later requirements may be deferred,
canceled or changed, (2) deferring complexity saves time and money
now, and (3) sometimes the simple solution actually works in the
complex case, in spite of everyone's expectations to the contrary.
> -> Non-Agile approaches, by definition, discourage effective and
> pragmatic communication among management, technical staff, the
> customer, and others.
>
> -> Non-Agile approaches, by definition, discourage group ownership
> and group responsibility.
Not by definition, but I've often seen these things happen.
> -> Non-Agile approaches, by definition, ignore the human element
> in team building, testing, management, and the entire software
> engineering effort.
No one sets out to ignore the humans who are operating the systems.
But often an excessive focus on tools and techniques, such as UML,
sends people down a road where they lose focus on the human elements.
> -> Non-Agile approaches, by definition, do not allow for tailoring.
I agree with others that this is a silly claim. A common criticism of
RUP is that you can tailor it to be anything at all, from hacking to
waterfall to XP. And a common criticism of XP is that you can't
tailor it at all; you're stuck with the 12 practices, as written.
Now a common failing of RUP, CMM, and other highly configurable
approaches is that some people are tempted to "do it all." (Actually,
some people are tempted to force someone else to do it all. ;-)
Anyway, there was another good thread around somewhere recently saying
that adaptability, the approaches openness to tailoring and
customization, is orthogonal to agility, the ability to respond to
changing business requirements. I kinda' like this idea.
Phlip
> For some links to some "teeth-gritting articles," check out the
> bibliography to my "Misconceptions of the Agile Zealots" article:
>
> http://www.toa.com/pub/Misconceptions.zip
Mystification works both ways.
When Cockburn and Highsmith write "Too often, software engineering and
rigorous process adherents confuse process and competence," they are not
denying any forty-year history of process experts advising to put people
before process. (This stuff goes all the way back to the reactions to
Taylorism.)
They are reporting what they have seen real managers do in real companies.
You cannot argue, "Clearly that's impossible, because those bosses should
have read all these old books!"
And you also cannot argue that reporting their direct experiences represents
mystification on behalf of promoting their point. As they experience bosses
reading old books and doing the right thing, I respect their writings to
reflect this, as I do yours.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Jeff Grigg
> -> Test Driven Development (TDD), as it is described in the
> literature, and frequently discussed in Agile forums, is
That may be true. But you can go pretty darn far with just Test
Driven Development.
> I would say that "Fagan-style inspections," along with several other
> forms of inspections, are a type of testing. However, I would also
> say that such inspections, on their own, are insufficient for
> adequate testing of (both code and non-code) software.
I think the Clean Room development community would disagree with the
assertion that inspections are insufficient.
But, on the other hand, I don't think that the Clean Room approach is
agile.
_ _ _
>>> -> Non-Agile approaches, by definition, discourage effective and
>>> pragmatic communication among management, technical staff,
the
>>> customer, and others.
>
> Could an approach not recognized by the Agile Alliance, encourage
> effective and pragmatic communication among management, the technical
> staff, the customer, and others?
In my experience, all software development approaches, all the way to
waterfall, attempt to "encourage" such communication. However, when
it comes down to measuring the level and quality of such communication
on real projects, I think there has generally been a significant
difference between Agile and non-Agile approaches. There may be
exceptions, but I think the trend is clear.
>>> -> Non-Agile approaches, by definition, discourage group
ownership
>>> and group responsibility.
>>
>> An approach without group ownership and responsibility is less
likely
>> to be agile.
>
> Could a non-Agile approach encourage group ownership and group
> responsibility?
Yes, absolutely. And it's possible for teams with strong individual
ownership and responsibility to be very [small-a] agile.
But which is the "rule," and which is the exception?
> My point is that I am still encountering people who believe
> these myths, and, unfortunately, the myths form the basis of
> many "technical" and managerial decisions.
If the assertions were worded as "I've generally found that most
non-Agile approaches fail at X, while XP and some other Agile
approaches succeed," instead of "By definition, non-Agile approaches
always fail at X", then I'd think that most of the assertions could be
a firm bases for good technical and managerial decisions. I've
generally found most of the anti-Agile rhetoric to be much worse -- as
in more false and misleading.
Jeff Grigg
>> Twenty-five years ago (1979), I was part of a training team working at
>> General Dynamics (GD). [...]
--- "Phlip" <phli...@yahoo.com> wrote...
> Please critique the following. I feel I have worked hard to exclude mythos
> and revisionism from it. I do suspect nobody was doing it in the 1970s, but
> I wasn't programming then so I wouldn't know. TDD is a new concept that
> changes everything.
>
> [ -- LOTS and lots of really good stuff clipped here -- ]
Very nice post Phillip. Good reading, and potentially highly educational. Thanks!
- jeff
Ronald E Jeffries
>> >I have exactly the same reaction when I read articles that contrast
>> >"complex implementations" with "radical simplicity."
>>
>> Please post links to a few such articles, I'd like to read them.
>
>Ron,
>
>First, thank you for taking the time to respond to my questions.
>I found your answers to be useful.
>
>For some links to some "teeth-gritting articles," check out the
>bibliography to my "Misconceptions of the Agile Zealots" article:
>
> http://www.toa.com/pub/Misconceptions.zip
>
>To see even more mythology, check out the "Agility and Classical
>Software Project Management" thread in this newsgroup.
Um, Ed. I'm asking for links to articles contrasting "complex
implementations" with "radical simplicity". Your paper's bibliography
lists some 56 pages of items, about 11 items per page, or
approximately 616 items. One can only marvel.
As it happens, I am familiar with a number of these items and they are
not on topic. In the interest of time, I renew my request for links to
articles contrasting "complex implementations" with "radical
simplicity".
At a higher level, if "higher" is the word I'm looking for, I'm
wondering what the point of this might be. I'm aware of no one who
really believes the things you say that "agile zealots" believe. Whom
are you refuting, to what end?
Further, I'm questioning the whole big-A little-A notion. No one I
know has claimed that the Agile Alliance, or any other subset of the
agile software community, lists, could list, or wants to list all the
"officially agile" methods. Most of us, under even mild interrogation,
would assert that there is a practical infinity of agile methods, far
more than the total number of projects going on at any given time in
the universe.
So what's the point?
Thanks,
Ilja Preuß
> I wonder where you're getting your definitions. I think that the
> Agile Manifesto is the most widely accepted and appropriate definition
> of what agile methodologies are. But as I read it, I see four values
> that if you have all four, you're agile, while if you're missing any
> one, you're not. So by that definition, a non-agile approach could
> share any one to three values with agile approaches, but still be
> non-agile.
Is agility (or even Agility) really a binary property? Could it be that a
project that fails somewhat on one of the values simply is likely to be
*less* A/agile than one that shined in all four?
Cheers, Ilja
Ilja Preuß
> So what's the point?
I have the feeling the point is that you don't have to value
"Individuals and interactions over processes and tools
"Working software over comprehensive documentation
"Customer collaboration over contract negotiation
"Responding to change over following a plan
to be able to embrace change.
I am far from sure, though.
Regards, Ilja
Phlip
> Ronald E Jeffries wrote:
>
> > So what's the point?
>
> I have the feeling the point is that you don't have to value
>
> "Individuals and interactions over processes and tools
> "Working software over comprehensive documentation
> "Customer collaboration over contract negotiation
> "Responding to change over following a plan
>
> to be able to embrace change.
I'l try:
Ed's point (in abstentia) is that all the "Agile" books ride a wave of
enthusiasm based on re-hashing old ideas under new labels, while
simultaneously decrying all old ideas as "traditional" methodologies.
Well... Duh!
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Laurent Bossavit
> To see even more mythology, check out the "Agility and Classical
> Software Project Management" thread in this newsgroup.
Are you referring to the post (of Ron Ruble) which started that
relatively short thread ? If so, my perception was different - that
didn't read like mythology to me, it came across as an attempt at
constructive inquiry. Could you please point out the mythology ?
Edward Berard
Jeffries <ronje...@acm.org> wrote:
> Um, Ed. I'm asking for links to articles contrasting "complex
> implementations" with "radical simplicity". Your paper's bibliography
> lists some 56 pages of items, about 11 items per page, or
> approximately 616 items. One can only marvel.
>
> As it happens, I am familiar with a number of these items and they are
> not on topic. In the interest of time, I renew my request for links to
> articles contrasting "complex implementations" with "radical
> simplicity".
One article that specifically mentions "complex implementations" and
"radical simplicity" is contained in the October 1998 issue of
Distributed Computing. See the table in the right hand column on
page 28. I believe that you are listed as one of the authors.
I would also like to think that you would grant me that the article
is long on hype and very short on specifics.
> At a higher level, if "higher" is the word I'm looking for, I'm
> wondering what the point of this might be. I'm aware of no one who
> really believes the things you say that "agile zealots" believe. Whom
> are you refuting, to what end?
I run into this stuff all the time. However, I am glad to see that
those at the top (yourself included) are putting some distance between
themselves and some of the "old time, Agile rhetoric."
Although, there is not much directly regarding simplicity, I found
the following quote (lifted from "A Metric Leading to Agility") to
be interesting. I am interested, for example, in the basis for the
belief that "the features aren't tested, and often don't really run
at all." While I know that ths is true for some non-Agile projects,
I also know that it is not a requirement.
"Waterfall-style projects 'deliver' things other than RTF early on.
They deliver analysis documents, requirements documents, design
documents, and the like, for a long time before they start delivering
features. The theory is that when they start delivering features, it
will be the right features, done right, because they have the right
requirements and the right design. Then they code, which might be
considered Delivered Software, but not Running Tested Features,
because the features aren't tested, and often don't really run at
all. Finally they test, which mostly discovers that the RTF progress
wasn't what they thought."
(To be fair, you did mention elsewhere in the same article that you
were not intending to be fair.)
> Further, I'm questioning the whole big-A little-A notion. No one I
> know has claimed that the Agile Alliance, or any other subset of the
> agile software community, lists, could list, or wants to list all the
> "officially agile" methods. Most of us, under even mild interrogation,
> would assert that there is a practical infinity of agile methods, far
> more than the total number of projects going on at any given time in
> the universe.
I am very glad that you said that.
> So what's the point?
There are several points, but let me just mention two of them (for the
moment):
1. Too often, people seek out "black and white" answers for questions
that have virtually an infinity of gray-scale answers. (See, e.g.,
some of the recent discussions of "An XP Detector?" on Yahoo's
Extreme Programming mailing lists.) While I am sure that you,
Robert C. Martin, Kent Beck, A. Cockburn, and a number of others
are quite comfortable with "shades of gray," a significant portion
of the developers out there are not. It is these people who keep
giving me grief.
2. Far too many Agile advocates appear to think that conjuring up a
fantasy of what something might be like is the same thing as
actually understanding the phenomenon. (Sadly, this problem is
not limited to the Agile community.) The "Agility and Classical
Software Project Management" thread is an especially vivid
example of this problem. I have had encounters with managers
who actually believe those kinds of things. It is often not
until I get out a 1970s era project management text book and
force them to read it that they begin to see the
misrepresentations.
Thanks for your input.
Ilja Preuß
> Although, there is not much directly regarding simplicity, I found
> the following quote (lifted from "A Metric Leading to Agility") to
> be interesting. I am interested, for example, in the basis for the
> belief that "the features aren't tested, and often don't really run
> at all." While I know that ths is true for some non-Agile projects,
> I also know that it is not a requirement.
Notice that he didn't wrote "non-Agile" but "Waterfall-style". AFAIK, the
common definition for Waterfall *is* that the Testing phase starts after the
Implementation phase?
For "not running at all", it's what I experienced, too - it might not even
be integrated at all. The "often" might imply that it's not a "requirement",
though.
> "Waterfall-style projects 'deliver' things other than RTF early on.
> [...]
> which might be considered Delivered Software, but not Running
> Tested Features, because the features aren't tested, and often
> don't really run at all. Finally they test, which mostly discovers
> that the RTF progress wasn't what they thought."
Cheers, Ilja
Robert C. Martin
>First, let me distinguish between "Agile" (with an upper-case "A") and
>"agile" (with a lower-case "a").
RUN FOR THE HILLS! Case has become significant in defining Agility!
(Sorry, I couldn't resist. No offense intended. I haven't even read
the rest of the article.)
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
sirgilligan
First, sorry to get into the discussion late and not to have read any
further than this article yet... but I would like to throw in my ideas
as well.
First let me say that I feel this is going to lead to more arguments
than anything because we all have experienced different things.
Example, I was on many waterfall projects in the mid '80s up to now
and I personally have unit tested my code before integration from day
one because of the benefits it gave me as a developer. So, I was
entrenched in waterfall, yet I was unit testing. During the C++ days I
would also "bullet proof" my code prior to being code complete. During
bullet proofing one thing I would do is add "assert"s to the the code
everywhere that there was no "if" or conditional logic checking for
correct values, preconditions, etc. Waterfall never asked for this.
Now, own to some myths below:
>
> -> Non-Agile approaches, by definition, do not accommodate changes
> very well.
This statement is true in my experience. All change was done during
the analysis and design phase, hard docs were made and signed off, and
then development began. Any design flaws became dead ends and caused
code quality to become a slave to the bad design. Any changes
propagated more special subsystems. To say it short, it was the
opposite of Domain Driven Design because you could not refactor into a
ubiquitous(sp?) langauge or any of the other things mentioned in DDD.
>
> -> Non-Agile approaches, by definition, do not seriously consider
> testing until very late in the development/enhancement effort.
True once again. Testing began after a significant portion of the
functionality was complete. This meant that they were testing for
bugs, not testing to see if the developers had hit the target AND
there were no bugs (V&V). The developers would often say, "Don't test
that yet, it is not done." Come on, you have said it or you have heard
it!
>
> -> Non-Agile approaches, by definition, do not use automated testing
> tools and techniques.
I disagree. The tools and techniques were crude, but they were there.
Lots of scripting and on Window's GUIs there were tools that spied on
the windows messages and could record them and play them back.
>
> -> Non-Agile approaches, by definition, do not check for extraneous
> features.
True. I have seen this many times. Programmer's cool ideas were easily
introduced and included. Testing accepted them, and then the ripple
effect of updating documentation, etc...
>
> -> Non-Agile approaches, by definition, seek out complex "solutions"
> as opposed to simple, straightforward, and inexpensive solutions.
Not true. There were many that proposed the old KISS principle. Keep
it simple, Stupid.
>
> -> Non-Agile approaches, by definition, discourage effective and
> pragmatic communication among management, technical staff, the
> customer, and others.
From my experience this is VERY true. This is the breeding ground for
the distrust amongst PM and Dev.
>
> -> Non-Agile approaches, by definition, discourage group ownership
> and group responsibility.
Didn't see any discouragement that comes to mind off hand. However, it
didn't discourage empire building either, and empire building is what
seemed to thrive over group ownership and team building.
>
> -> Non-Agile approaches, by definition, ignore the human element
> in team building, testing, management, and the entire software
> engineering effort.
Yep. I have seen this in most places I have worked. However, I have to
state that I have seen this happen on the agile teams as well.
>
> -> Non-Agile approaches, by definition, do not allow for tailoring.
>
> -- Ed
Ron Ruble
"sirgilligan" <sirgi...@yahoo.com> wrote in message
news:c1de56dc.04072...@posting.google.com...
> Edward Berard <e...@toa.com> wrote in message
news:<180720041246129113%e...@toa.com>...
>
> First, sorry to get into the discussion late and not to have read any
> further than this article yet... but I would like to throw in my ideas
> as well.
> First let me say that I feel this is going to lead to more arguments
> than anything because we all have experienced different things.
> Example, I was on many waterfall projects in the mid '80s up to now
> and I personally have unit tested my code before integration from day
> one because of the benefits it gave me as a developer. So, I was
> entrenched in waterfall, yet I was unit testing.
Many people did and do unit test in classical development.
There are a number of problems with -how- most people unit
test in a classical environment.
1: the unit tests performed are -very- rarely comprehensive.
people test what they belive they changed. If they can't see
the applicability of a test to the changes that they -believe-*
they have made, they don't re-run the test. Completely
automated, easy to run tests avoid this problem.
* this goes back to testing at -very- small intervals. It's
easy, if you don't run an automated test every few
minutes, to forget that you made a small change in
another function or module. Often these small changes
add up to a problem.
2: The tests usually are non-trivial to run. Maybe it
requires stubbing out some code here, or changing a
compile flag there. If it isn't absolutely trivial to run the
test, it tends to be postponed. I'm becoming a -big-
fan of "hit the button and look for green" testing.
> During the C++ days I
> would also "bullet proof" my code prior to being code complete. During
> bullet proofing one thing I would do is add "assert"s to the the code
> everywhere that there was no "if" or conditional logic checking for
> correct values, preconditions, etc. Waterfall never asked for this.
> Now, own to some myths below:
Unfortunately, assertions have very real limits. Often
they have side effects that can hide errors, and an
assertion is only capable of detecting a condition if
the condition evaluates to true as you test. CUJ has
had many articles on this over the last few years.
They wouldn't bother if it weren't something that
occupies a lot of developer attention.
> > -> Non-Agile approaches, by definition, do not use automated testing
> > tools and techniques.
>
> I disagree. The tools and techniques were crude, but they were there.
> Lots of scripting and on Window's GUIs there were tools that spied on
> the windows messages and could record them and play them back.
Ehhh....The tools were not quite the same deal. They
supported testing primarily for full-on Q/A testing rather
than frequent unit testing during development. At least
in my experience with non-xUnit type testing tools.
> > -> Non-Agile approaches, by definition, seek out complex "solutions"
> > as opposed to simple, straightforward, and inexpensive solutions.
>
> Not true. There were many that proposed the old KISS principle. Keep
> it simple, Stupid.
I would tend to agree. The tendency toward complex
solutions, in my experience, is not due to the classical
methodologies as much as other factors in modern
development environments and platforms. Much of
this seems to be driven by the vendor desire to be
"your one-stop everything shop"
> > -> Non-Agile approaches, by definition, discourage effective and
> > pragmatic communication among management, technical staff, the
> > customer, and others.
>
> From my experience this is VERY true. This is the breeding ground for
> the distrust amongst PM and Dev.
And users. I've seen a -lot- of hostility from users
due to overzealous attempts to control the communications
channels.
> > -> Non-Agile approaches, by definition, discourage group ownership
> > and group responsibility.
>
> Didn't see any discouragement that comes to mind off hand. However, it
> didn't discourage empire building either, and empire building is what
> seemed to thrive over group ownership and team building.
One thing in agile methods that I think defuses some of the
ownership aspects is the tendency to group features in business
order and take them to completion quickly once they are
begun. If a feature doesn't become the focus of on user
rep or programmer or clique for an extended period once
we start to produce it, people don't seem to have time to
get attached to it.
> > -> Non-Agile approaches, by definition, ignore the human element
> > in team building, testing, management, and the entire software
> > engineering effort.
>
> Yep. I have seen this in most places I have worked. However, I have to
> state that I have seen this happen on the agile teams as well.
Well, the human element is both the most important and the
hardest to manage correctly.