http://qs321.pair.com?node_id=1130533


in reply to Re^5: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
in thread Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship

It's all about getting a tighter feedback loop on smaller chunks of work. It's meant to deal with specification drift, scope drift, and people talking past one another about the customers' needs.

RAD can and is achieved without the dogma, process-heavy intrusion, and the dumbing down of Agile/Scrum/whatever.

I've been practicing RAD for nearly 30 years quite successfully. As an individual developer; a lead of a small team; and as the architect of a large team of teams; the practice is essentially the same:

  1. Mock up the top level of the application to provide the application flow, leaving the next levels as apis to be fulfilled.

    The top level can then be demonstrated to the users, feedback taken and adjustments made whilst each of the apis at the next level are being implemented.

  2. Each of the next level apis are treated in essentially the same way. They are initially mocked up in terms of their internal apis.

    Once they are mocked up and compile; they can be plugged into the top level. Which verifies they accept the inputs it wants to give; and returns (mocked) values of the type/order that it expects.

    As each of the apis moves from mocked to implemented; the previous level acts as the test suite for this level; and this level acts as the test suite for the previous level.

  3. If a third or more levels are required; they are started as soon as the previous level has defined its requirements.

    Again, the lower levels are mocked up -- just taking and verifying inputs; and returning plausible values as outputs. Nothing more.

    And as soon as they are able to fulfill the interface to that limited level; they are plugged into the previous level.

The feedback loops between levels are short; change requirements feed down from the top as they happen; inconsistencies are detected immediately they arise; and are corrected immediately.

It works for any type of application; no matter how complex; or how large the overall team.

Individual teams are small, and only interface with those immediately above and below, so the typical humongous status meetings don't arise.

The design evolves as required and in parallel; loose coupled interfaces are enforced -- but fall out naturally; overnight integration builds tell everyone where things are and what needs immediate attention without all the extraneous process and paranoid navel inspection.

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
  • Comment on Re^6: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship

Replies are listed 'Best First'.
Re^7: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by mr_mischief (Monsignor) on Jun 15, 2015 at 23:11 UTC

    So you're building in small pieces with frequent feedback and rapid adjustments? I hate to tell you this, but that is very similar to bespoke agile development.

    I don't think you are against the goals of "agile" or against the principals espoused by the writers of The Agile Manifesto. It seems you share mostly the same goals, and dislike the pomp, ritual, zealotry, and rapacious consulting fees of the training coaches. Well, that's true I think of most people.

    As a method for estimating work and protecting developers from marauding stakeholders outside the team, I think having a company-wide buy-in to Scrum for example is a good thing. It's not going to make your developers produce better software. It just gets them clearer specs and more chance to focus on delivery. They can still deliver utter crap if that's what they are capable of producing and what your customers accept.

[reply]
      I hate to tell you this, but that is very similar to bespoke agile development.

      That was my point exactly. Except that it was being done for a decade or two whilst the Agile manifesto, and all its derivatives, were just twinkles in the eyes of their evangelists.

      And it doesn't need silly buzz words; uncomfortable meetings; violent transparency or coding by numbers to work.

      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
[reply]

        The authors of The Agile Manifesto I think agree more with you than with many of the process zealots selling books and classes about agile development. There has been a follow-up saying they never intended the formalization of their people over process rant into such strict processes, which makes sense.

        The actual processes are largely inspired by Japanese manufacturing techniques. They get labeled "agile" mainly because that's the hot word and the original manifesto authors didn't trademark the word to sell books and classes.

        I'm still unsure what part of any of this situation encourages you to keep saying that people who do test-first development or who have daily fifteen-minute status meetings are absolutely and definitely replaceable cogs who can't develop code and need to "code by numbers". That seems like one hell of an unsupported claim.

[reply]
Re^7: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by Anonymous Monk on Jun 15, 2015 at 22:54 UTC

    ... paranoid navel inspection.

    But you still do that in the shower?

[reply]

In Section Meditations