[chbot] Agile! Jack Ganssle AUGUST 11, 2014

[Charles Manning]

When my sons wanted to start programming, the first thing I did was
set them up github accounts and taught them how to use git.

I am still amazed at how many people (even programmers in commercial
settings) will work for weeks without doing any check ins.


On Fri, Aug 15, 2014 at 8:38 AM, Quentin McDonald <dqmcdonald at gmail.com> wrote:
> Hi All,
>
> Thanks for sharing this Mark. I've just come out of a stand-up (one held
> with developers in four cities over two countries) and I have, despite some
> initial misgivings, started to appreciate the advantages of the Agile ways
> of doing things. On the other hand a quarter century of software development
> has also convinced me there is no silver bullet
> (http://en.wikipedia.org/wiki/No_Silver_Bullet). Like a lot of enterprises
> we've picked out those aspects of the theory that seem to work best for us
> in practice, no doubt to the horror of consultants and authors who seem to
> believe you have to sign on completely to get full benefit.
>
> What I am interested in, and it's perhaps more relevant for this list, is to
> what extent Agile techniques might be also applicable to "hobby" coding
> projects. Often these are single developer (or a small number) and the coder
> is also the "customer". I suspect Agile type ideas (such as delivering
> often) happen naturally. But are there other techniques that we could use
> even in our efforts that might improve our "productivity"? Or would that all
> make it seem too much like work, each weekend becoming a "sprint" and tasks
> rolling over undone?
>
> I note that despite much day job experience with them I've only just started
> using a revision control system (github) for my own Arduino based projects
> and I'm wishing I'd done so years ago. That's what gave me the idea that
> perhaps there are other "work" habits that could be usefully adapted for my
> "play". OOD/OOA? Test driven development? Design by contract? These probably
> all happen naturally to some extent but has anybody made a conscious effort
> to adapt formal methods for informal projects?
>
>
> Quentin
>
>
> On Fri, Aug 15, 2014 at 7:25 AM, Mark Atherton <markaren1 at xtra.co.nz> wrote:
>>
>> sense at last :)
>>
>> stolen from http://www.embedded.com/ hopefully with full credits included
>>
>> -mark
>>
>> ============
>>
>> Bertrand Meyer is one of the most literate authors in computer science.
>> His latest work, Agile!, is an example. It’s a 170 page summary and critique
>> of the leading Agile methods. The introduction gives his theme: “The first
>> presentations of structured programming, object technology, and design
>> patterns… were enthusiastically promoting new ideas, but did not ignore the
>> rules of rational discourse. With Agile methods you are asked to kneel down
>> and start praying.” The book burns with contempt for the eXtreme attitudes
>> of many of Agile’s leading proponents. He asks us to spurn the “proof by
>> anecdote” so many Agile books use as a substitute for even a degraded form
>> of the scientific method.
>>
>> This is a delightful, fun, witty, and sometimes snarky book. The cover’s
>> image is a metaphor for the word “Agile”: a graceful ballet dancer leaping
>> through the air. He contrasts that with the Agile manifesto poster: “The
>> sight of a half-dozen middle-aged, jeans-clad, potbellied gentlemen turning
>> their generous behinds toward us…”!
>>
>> He quotes Kent Beck’s statement “Software development is full of the waste
>> of overproduction, [such as] requirements documents that rapidly go
>> obsolete.” Meyer could have, and should have, made a similar statement about
>> software going obsolete, and that both software and requirements suffer from
>> entropy, so require a constant infusion of maintenance effort. But he writes
>> “The resulting charge against requirements, however, is largely hitting at a
>> strawman. No serious software engineering text advocates freezing
>> requirements at the beginning. The requirements document is just one of the
>> artifacts of software development, along with code modules and regression
>> tests (for many agilists, the only artifacts worthy of consideration) but
>> also documentation, architecture descriptions, development plans, test
>> plans, and schedules. In other words, requirements are software. Like other
>> components of the software, requirements should be treated as an asset; and
>> like all of them, they can change”. (Emphasis in original).
>>
>> He describes the top seven rhetorical traps used by many Agile proponents.
>> One is unverified claims. But then he falls into his own trap by saying
>> “refactored junk is still junk.”
>>
>> The book’s subtitle is “The good, the hype, and the ugly,” and he uses
>> this to parse many Agile beliefs. Meyer goes further and adds the “new,”
>> with plenty of paragraphs describing why many of these beliefs are actually
>> very old aspects of software engineering. I don’t see why that matters. If
>> Agile authors coopt old ideas they are merely standing on the shoulders of
>> giants, which is how progress is always made (note that last clause is an
>> unverified claim!).
>>
>> The book is not a smackdown of Agile methods. It’s a pretty-carefully
>> reasoned critique of the individual and collective practices. He does an
>> excellent job of highlighting those of the practices he feels have advanced
>> the state of the art of software engineering, while in a generally fair way
>> showing that some of the other ideas are examples of the emperor having no
>> clothes. For instance, he heaps praise on daily stand up meetings (which
>> Meyer admits are not always practical, say in a distributed team), Scrum’s
>> instance on closing the window on changes during a sprint, one month
>> sprints, and measuring a project’s velocity. (I, too, like the Agile way of
>> measuring progress but hate the word “velocity” in this context. Words have
>> meaning. Velocity is a vector of speed and direction, and in Agile
>> “velocity” is used, incorrectly, to mean speed).
>>
>> One chapter is a summary of each of the most common Agile methods, but the
>> space devoted to each is so minimal that those not familiar with each
>> approach will learn little.
>>
>> Agile! concludes with a chapter listing practices that are “bad and ugly,”
>> like the deprecation of up-front tasks (e.g., careful requirements
>> gathering), “the hyped,” like pair programming (“hyped beyond reason”), “the
>> good,” and “the brilliant.” Examples of the latter include short iterations,
>> continuous integration, and the focus on test.
>>
>> The book is sure to infuriate some. Too many people treat Agile methods as
>> religion, and any debate is treated as heresy. Many approaches to software
>> engineering have been tried over the last 60 years and many discarded. Most,
>> though, contributed some enduring ideas that have advanced our body of
>> knowledge. I suspect that a decade or two hence the best parts of Agile will
>> be subsumed into how we develop code, with new as-yet-unimagined concepts
>> grafted on.
>>
>> I agree with most of what Meyer writes. Many of the practices are
>> brilliant. Some are daft, at least in the context of writing embedded
>> firmware. In other domains like web design perhaps XP is the Only Approach
>> To Use. Unless TDD is the One True Answer. Or Scrum. Or FDD. Or Crystal…
>>
>> Jack G. Ganssle is a lecturer and consultant on embedded development
>> issues. He conducts seminars on embedded systems and helps companies with
>> their embedded challenges, and works as an expert witness on embedded
>> issues. Contact him at jack at ganssle.com. His website is www.ganssle.com.
>>
>>
>> _______________________________________________
>> Chchrobotics mailing list Chchrobotics at lists.linuxnut.co.nz
>> http://lists.ourshack.com/mailman/listinfo/chchrobotics
>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>> Web site: http://kiwibots.org
>> Meetings 3rd Monday each month.
>>
>> When replying, please edit your Subject line to reflect new content.
>
>
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Web site: http://kiwibots.org
> Meetings 3rd Monday each month.
>
> When replying, please edit your Subject line to reflect new content.