Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

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

by BrowserUk (Pope)
on Jun 15, 2015 at 23:55 UTC ( #1130539=note: print w/replies, xml ) Need Help??


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

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

Replies are listed 'Best First'.
Re^9: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by mr_mischief (Monsignor) on Jun 16, 2015 at 06:01 UTC

    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.

      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.

      Um; I never mentioned (anywhere in this thread) test-first development.

      1. <cite>Daily 15 minutes status meetings:</cite>

        The following is a from-memory precise of a report I wrote over 20 years ago and presented at a "weekly cascade meeting" one of my clients insisted I attend:

        In the short term, I was excused future attendance -- I had no need or interest to be keep up with the changes in the site maintenance schedules; company pension plan changes; corporate wide managerial promotions; or retirements. I was a contractor.

        Why was I ever required to attend? Because the employees felt it was unfair for contractors to be excused the drugery of attending, when they had to.

        In the longer term; it actually triggered a sea change on that site; that spread to others.

        It wasn't all my idea. The original moans were mine to my PL (same guy mentioned earlier) and the write up was all my own work; but it was him that suggested I should bind copies and hand them out in the meeting. I was his stalking horse to effect change on several occasions.

      2. <cite>absolutely and definitely replaceable cogs who can't develop code and need to "code by numbers"</cite>

        First. Nothing I've said implies anything about the programmers subjected to these methodologies.

        The statements are about the goals of the methodologies (as sold to management in private by the purveyors of the branded methodologies.)

        These methodologies are essentially public domain, free for any company to use.

        So why do so many of them spend money on consultants; training courses and certifications from branded versions?

      I obviously don't know how things go in every company; so I can only talk generically; and as I'm trying to make supporting argument for a position; it is natural that I will tend to the extreme that support that position.

      Its neither personal nor accusatory.

      And remember; I've nothing to gain or lose by what you or others do. Especially if they choose to do things that work for them.

      But the single most frustrating thing as an "old timer" is watching younger generations making the same damn mistakes I made; and doing so willingly and enthusiastically.

      If my posts in this thread have caused any one young guy or girl to step back and consider their work situation with a broader, more skeptical eye; they've been worth my effort.


      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1130539]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2019-06-24 17:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Is there a future for codeless software?



    Results (99 votes). Check out past polls.

    Notices?