[chbot] Agile! Jack Ganssle AUGUST 11, 2014

[Quentin McDonald]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20140815/e82c080d/attachment.html>