Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
Agile introduces effective processes to groups who haven't already stumbled upon them, or haven't learned them from experienced team members.

I think that's a very fair summation. I'd go further and say that it does what pretty much all commercially sold methodologies do: it promises to short-circuit the learning process.

But there are (at least) two problems with that:

  1. The calculator for kids syndrome: dependancy.

    Whilst providing preteens with calculators appears to give them a head start for a few years; once they get to college age; that head start often results in a stall. One which many of them will never recover from.

    Look at a high school math paper from the early 90s and if you look closely, you might notice something strange. (You probably have to come from the pre-calculator era to do so though.)

    The way the questions are constructed -- whether they are simple sums or the wordy 'problems' form of question -- they are intended to be solved by someone wielding a calculator.

    The differences are subtle; but for example; in the pre-calculator era, the numerical quantities in questions not directly aimed at testing basic arithmetic skills; were often carefully chosen so that the arithmetic required was relatively simple, if you were approaching the problem in the correct way.

    Ie. where division was required, denominators and enumerators would usually cancel to simple, single digit reductions; powers and roots would cancel to avoid the need to actual calculate either; signs would balance out; and so on.

    In this way, the test was about knowing or deriving the right formula and plugging the values in in the right places; not about re-testing the basic maths skills to calculate the final number(s).

    With the advent of calculators, with them doing the actual calculations, paper setters no longer had to look for these simplifications; and so the kids never learnt to do the cancellation steps.

    Role forward to college age (and the real world) and start dealing with probabilities or Taylor series expansions and the like; where instead of canceling out common factorial terms, or reducing by canceling power terms above and below; the kids try to calculate the values in full. With the consequence that intermediate terms exceed the range of their calculators; and they are dead in the water.

  2. The unrecognised problem syndrome.

    When you reduce the learning process to a recipe-style set of steps; or que-card process; it fails to equip the learner with the learning-from-your-mistakes experience.

    There is a popular TV reality program in the UK called MasterChef. Amateur chefs trying to produce professional (Michelin Star) standard dishes. At various stages the competitors are given the same recipes, ingredients and time to produce a recipe that the viewers have previously seen prepared by a professional chef. Then they are compared.

    Given the same inputs, there are people that assume that they should all be able to produce the same outputs. They don't. The differences, often very marked, come down to ethereal, almost immeasurable things, like palette, experience and practice. Even an eye for color, artistic flair and a steady hand under pressure.

These are things that can't be short-circuited. They cannot be taught, they must be learnt. They cannot be instilled; they must be acquired.

Applied rote, without room for: learning by your mistakes; or master/apprentice mentoring; and by presenting all work in the singular form of user-stories; you may short-circuit a few months or a couple of years off the early learning process to obtain acceptable productivity more quickly; but you also introduce a plateau that can never be surmounted. There is no room in the system for the gifted to rise above that plateau; and no way for the level of that plateau to rise.

For the company, provided they can maintain a low-level of costs, which they can because there is no basis for individuals to become worth more than the standard rate; and replacing those who feel they want more becomes a simple process because the intake requirements are so low, this is good. Known costs * numbers = fixed overhead. Exactly what the accountant wants.

For the programmer looking for a career, it is all bad, unless they are one of those that would never progress beyond the most basic level anyway.

Present the 'products' of these methodologies -- programmers who expect all the work to be presented to them in the form of user-stories; and to work through each work item by a rote process of: if this do that; if this do that; -- with any task that does not comply with their expectations; and they are lost; because all the learning that was short-circuited -- how to gather requirements; how to prioritise those requirements; how to adjust and adapt their tools and working practices to the process of solving those requirements -- leaves them ill-equipped or unequipped to transition to the new reality.

It creates 'crisis fodder'. Young, willing, enthusiastic, (usually male) programmers that follow rote, slog through, burn long, and hard, and out.

In wartime, they are called grunts.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

In reply to Re^3: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship by BrowserUk
in thread Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship by eyepopslikeamosquito

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others chilling in the Monastery: (3)
    As of 2019-04-20 13:00 GMT
    Find Nodes?
      Voting Booth?
      I am most likely to install a new module from CPAN if:

      Results (109 votes). Check out past polls.

      • (Sep 10, 2018 at 22:53 UTC) Welcome new users!