http://www.perlmonks.org?node_id=1130110


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

Welcome to the future.

That's what they said about SSADM back in the '80s. I rejected that back then; and I was right. Who's heard of it now?

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

If you can reduce your programmer rolls to lots of Lil'boxes all made out of Ticky-Tacky then they can be managed as numbers in a spreadsheet.

No stars; commoditised salaries; zero-hours contracts. An out-sourceable resource, purchased on a world-wide spot market at the cheapest price.

Management has been falling for the hype for decades; and each new generation of programmers are all too ready to sign up with relish.

It may be your tomorrow; but its not mine. I did my time. Good luck.


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^3: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship

Replies are listed 'Best First'.
Re^4: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by aaron_baugher (Curate) on Jun 12, 2015 at 00:05 UTC
    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.

      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

      "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.

      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
Re^4: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by shmem (Chancellor) on Jun 13, 2015 at 12:05 UTC

    I fully agree. Instead of writing up stuff myself - a link: Why “Agile” and especially Scrum are terrible which is a nice read.

    TOC excerpt:

    Specific flaws of “Agile” and Scrum
    1. Business-driven engineering
    2. Terminal juniority
    3. It’s stupidly, dangerously short-term
    4. It has no regard for career coherency
    5. Its purpose is to identify low performers, but it has an unacceptably false positive rate
    6. The Whisky Googles Effect
    7. It’s dishonestly sold

    tl;dr:

    Agile is a tool and mindset which doesn't foster individual or collective joy in business, but to extort maximum profit from programmers in the name of effectiveness, without regard for the very foundations of the latter: individual strenghts, weaknesses, handicaps, genius; and it invades privacy, which is a requirement to grow.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

      I wouldn't be surprised if that author saw or even experienced most or all of what he wrote about. But I have experienced nearly none of it. It seems plausible that Agile/Scrum could be used that horribly.

      I'm not an Agile fanboy. Fighting Agile fandom or just making fun of it is not uncommon for me at work. This is an annoying part of Agile in a lot of places, but I tolerate it because I can also use the "fan" aspect to ease adoption of process improvements (and because this and other negative aspects of Agile don't outweigh the positive aspects, IME).

      Much of what he wrote is nearly opposite of what I've experienced with Agile. For example, I've never seen the tracking of individual contributor progress used in a way even close to what he describes as the purpose of that. One of the more dramatic benefits I've seen from Agile is the ability to greatly reduce non-direct management's focus on the productivity of individual contributors. The regular, short delivery cycles and several planning elements contribute to Business/Product being able to better predict schedules, which reduces their motivation to micro-manage into within-team concerns.

      Most teams I've been on did not even track individual progress nor productivity within Agile most of the time. When it was done, the purpose was simply to counter-act the common problem where a software developer gets "stuck" on a task and repeatedly thinks that they are 90% done while the time spent grows to many times the original estimate. And those times, the point was not even for the team lead to track individual productivity, but to get the developer to realize much more quickly how "stuck" they were so that they would stop trying to "push through" to finish their current approach but instead take a step back and realize a change was needed (I found that swapping tasks with another developer often just solved such problems).

      The criticisms that Agile does not cater well to senior developers and long-term projects with significant design requirements and also encourages the build-up of technical debt are more realistic. These are areas where you have to push back against Agile, but even more so, against Agile zealotry. I often laugh when I see again how several of my co-workers who aren't Agile zealots but are Agile fans are just unable to admit that aspects of Agile actually contribute to such problems (insisting that only the mis-application of Agile can be blamed).

      But it is certainly not true that Agile makes such problems inevitable. We have Agile zealots here and lots of Agile fans and we have many teams. Most teams have somebody very senior that is very highly appreciated. Many teams have quite successfully taken on projects that took years to develop very complex systems.

      My experience is that the really big projects are actually more likely to be successful with Agile than without it. The problems with Agile and large, complex projects are not trivial. But they are less likely to balloon into project killers, IME, than the classic problems that lead to such a high failure rate for large, complex computer projects.

      I did leave a previous job, in part, because I was not being successful in pushing for fairly minor process changes to prevent the build-up of technical debt. That was in the context of Agile. But the real problem there was that the person at the top of that company was notably bad at empowering those under him and this attitude rolled down hill. Empowering at the bottom is the single most important principle for success, in my opinion. The people closest to the problem are the ones best able to make good decisions about dealing with the problem. Agile had actually made the tech debt problem less bad than it used to be there. But the tech debt problem in the end was indeed the classic form that can happen with Agile.

      One part of the write-up you linked to may reveal a major source of the perspective presented:

      Scrum and Agile represent acknowledgement of the idea that emergency powers must sometimes be given to “take-charge” leaders who’ll do whatever they consider necessary to get a job done, leaving debate to happen later.

      That is the opposite of empowering at the bottom. In that environment, no set of principles will be able to lead to a good system. I've never seen Agile run in something even close to that manner. And the principles of Agile actually contradict such an approach. Straight from the founding Agile principles we have "Projects are built around motivated individuals, who should be trusted". (I suppose you could misread that as "around motivated leaders, who should not be questioned", but that is not how it was meant and is not how I've ever seen it interpreted.)

      So somebody worked in a tyrannical environment where they used many Agile principles and practices. And that was horrible. They also completely rejected one key Agile principle. So such horribleness is certainly not inevitable with Agile. I believe that things being horrible is pretty much assured (eventually) by the tyranny. I see no reason to deny that, in that environment, some Agile principles and/or practices contributed to the horror. But I don't think that actually says much about Agile.

      - tye        

        There is a lot in this subthread about "it's not like that"; but nothing about what it is really like.

        Not that anyone will care, but all I originally asked was "On the ground, in practice, what is achieved by the Agile process -- stand ups, sticky notes et, al -- that isn't (not can't be) achieved without it?".

        I was interested in hearing what people who actually used it, but aren't necessarily Kool Aid drinkers, felt about it in real world use.

        Same way that I asked my neighbour who had solar panels fitted to his roof, how he was getting on after a year.

        I am a skeptic about them -- in this country, with our weather at fixed angles that weren't designed to capture sunlight and that can't track the Sun -- I consider the sales pitch that I've listened through a couple of times and been forced to cut short about once a week for the last five years, as close to a bare faced lie as I ever had pitched to me.

        I don't believe the hype; but I'm always interested to listen to real experience from the trenches.

        In my neighbours words: "it isn't saving me a huge amount; but it hasn't cost me anything; and I'm doing my bit for the environment.".

        The first Solar Panel salesman that opens with: "You won't save a lot; but it won't cost you anything", just might catch my attention.

        Somewhere between the sales pitch and the anecdotal bad experience; is what most people actually experience; and it was that I was interested in. Logic is rarely polemic.

        Update:It's also worth noting the fifth word of the title of this series of threads; hence why I thought I might get a straight response from eyepopslikeamosquito; but gave clear indication of my stance and leave to ignore. Which he has. Which I respect.


        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

      That is pure opinion editorial. No facts, no actual examples, and not one of the hypothetical anecdotes matched my experiences; I read the follow up post too and much of his would be insight was exactly the opposite of what I experienced at Amazon, for example. It’s not a computer science writing. It‘s personal philosophy blog posts.

      His logorrhea is only matched by his lack of meaningful, helpful, coherent conclusions, for example: Conclusion : Middle management is … both the solution and the problem. … rather than declaring the whole concept obsolete [we must\ figure out how to get good at it.

      You know what that kind of fluff and that ouroborian logic sounds like to me…? “The problem is the solution! We don’t know what to do but we need to figure it out!”

      Boo. Hiss. Fie.

        It’s not a computer science writing. It‘s personal philosophy blog posts.

        Of course yes. The blog is about Rants, essays, and diatribes. The article in question could have been enriched with anecdotes; but even so, it would also be personal opinion, perhaps worth to ponder. I personally believe (to quote blazar) that the "Agile Imposition" is akin to "Perl Best Practices": something useful for some, in some situations, but sought to be imposed as standard, once and for all, by those driving the scheme. No science there, either.

        perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
      Instead of writing up stuff myself - a link: Why “Agile” and especially Scrum are terrible which is a nice read.

      He he. I posted the exact same link in Re^3: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship 37 minutes before you.

      There's an applicable aphorism I'd quote, but then that yapping toy would pop up to point out my megalomania :)


      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
    A reply falls below the community's threshold of quality. You may see it by logging in.