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


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

Different methodology; same goals. The reduction of the Art of Programming to a paint-by-numbers process with interchangeable machine parts. (Programmers)

That's been the attraction for management with every new process or programming method or language that ever gained a lot of buzz: the promise of being able to replace temperamental, expensive craftsmen with fungible, cheaper assemblers.

So if something gets a lot of buzz in industry magazines, I assume it's probably not particularly good for programmers or for the craft of good programming. It hasn't failed me yet.

Aaron B.
Available for small or large Perl jobs and *nix system administration; see my home node.

  • Comment on Re^4: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship

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

    Scrum, for one agile methodology, is not at all about replacing people with cheaper people. 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.

    Having two weeks or four weeks to deliver a minimum viable product, then increments of the same for new features to be added, is not something one should ask of a team of plug-in commodities. It takes a team some time to work together to even be able to estimate properly what they can deliver in that amount of time. Once the team is built, it should be left in place as much as possible.

    The practice of specifying every little thing up front can be handy if those specifications are done well and won't change. If the customer's needs or which needs take priority over other start to drift, then getting that feedback every few weeks becomes really valuable.

      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

        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.

        ... paranoid navel inspection.

        But you still do that in the shower?

Re^5: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by jeffa (Bishop) on Jun 12, 2015 at 00:14 UTC

    "the promise of being able to replace temperamental, expensive craftsmen with fungible, cheaper assemblers"

    Wait, are you suggesting that is the "promise" of Agile as well? Because that is not true: http://scrumreferencecard.com/Obstacles_To_Enterprise_Agility_255033.pdf

    "It is naive to think of human beings as resources. Adding people to a team will not reliably increase the intangible resources--and may detract from them. After a year of doing Scrum, one of my clients reported “Once a team is formed, we would rather lose a team member than add one!” In another case, when the Scrum team itself made the hiring decision, adding a new member went well. Even when giving the team hiring autonomy, it’s inadvisable to grow it much larger than seven people. In some circumstances, adding teams may result in more progress, if we’re mindful of the intangible resources"

    These methodologies are built FOR programmers and FOR their craft. Most coders find these practices enjoyable and wonder why they had not used them sooner. The managers are the ones that take more convincing.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    

      Craftsmen don't want to focus on methodologies; craftsmen want to be left alone to practice their craft. That's not to say there aren't methodologies that would be helpful for programmers; but I would expect them to develop and spread quietly through forums and word-of-mouth in the same way software improvements do, not through flashy marketing campaigns and company-wide rollouts.

      It's management that spends time thinking about methodologies, because tweaking methodologies is a major way management justifies its existence. I've seen management switch from salaried employees to contractors (and then back again a couple years later); from cubicles to open rooms to offices to cubicles; from email communications between team members to instant messenger to frequent personal meetings. I've seen management declare that all new software would be written in a certain language for maximum efficiency (in this case, Java, for the hope of "replaceable cogs" that I mentioned before). In every case, management insisted these changes would be critical for making everyone's job easier and raising productivity. In every case the programmers rolled their eyes and did their best to ignore it and get on with programming.

      So if you're saying programmers are excited about this particular methodology and are pushing it forward, while managers aren't interested in it....well, I guess there's a first time for everything.

      Aaron B.
      Available for small or large Perl jobs and *nix system administration; see my home node.

Re^5: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by BrowserUk (Patriarch) on Jun 12, 2015 at 00:46 UTC
    So if something gets a lot of buzz in industry magazines, I assume it's probably not particularly good for programmers or for the craft of good programming. It hasn't failed me yet

    See Re^5: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship :)


    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