His main point is that, because Clojure is a functional language, functions have no side-effects and therefore can be used directly in the tests.

For example, the production code

(defn update-all [os]
  (update os))

would be tested with something like

(testing "update-all"
  (let [
    o1 (make-object ...)
    o2 (make-object ...)
    os [o1 o2]
    us (update-all os)
    ]
    (is (= (nth us 0) (update o1)))
    (is (= (nth us 1) (update o2)))
    )
  )

There is no reason to believe that the (update) function is side-effect-free

Changing internal values is only one way of creating side-effect. I admit that Clojure encourages coders to write code that does not change variables (if I got it right, it is definitely possible to do so, but with some additional work). However, that effect only stops at the boundaries of the language. At some point, it might access the file system or a database. Clearly, the state might change there.

Correct implementation of the (update-all) function depends on the correct implementation of (update)

Bob Martin says: ”this test simply checks that the appropriate three functions are getting called on each element of the list”.
Suppose that the (update) function does not do anything or maybe does something that does not return a value, such as printing out to the console. Then, calling it will have the same effect as not calling it at all. The test above will pass even if the (update-all) function does not provide any implementation at all. When, later, the bug is found, it will be harder to fix.

The test could be clearer (with a more powerful test framework)

One of my biggest concerns is that the test looks a lot like the code itself. Looks like duplication of information to the reader.
If there was a mock framework for Clojure, I would expect to see something like

(testing "update-all"
  (let [
    pre-conditions (
      (should-return (update 1) 1.5)
      (should-return (update 3) 3.0) )
    o1 (make-object 1)
    o2 (make-object 3)
    os [o1 o2]
    us (update-all os)
    ]
    (is (= (nth us 0) (1.5)
    (is (= (nth us 1) (3.0)
    )
  )

Bob Martin is right to conclude that “Clojure without TDD is just as much a nightmare as Java or Ruby without TDD.”

But he should also make it clearer that it is lacking a mock framework (he does point to Brian Marick’s work on this).

It should be noted that it is possible to get a similar implementation style in Java as in Clojure, though it is significant work. In fact, that’s often how we use it here at Algodeal. That means mostly relying on immutable objects and state-less methods. Immutable collections from Google Collections help a lot, too. Still, we like to use mocks in our tests (too much for some, probably).

In the end, Uncle Bob’s post is another aspect of the (almost) age-old debate described by Martin Fowler: classicists vs. mockists. If you haven’t already, read Fowler’s article, it’s worth it.

We chatted about a favorite topic of mine: how to expand the horizons for Agile. My point is mostly that the Agile crowd is mostly talking about basic issues in software development, including during the Agile 2009 conference. I fear that this my give the wrong impression to beginners (”how, so we only need to do this and that, and we’re agile? Cool!”) and even to seasoned practitioners (”this Agile thing is not addressing my needs anymore”).
I would much prefer that we talk more about complex problems, whether they relate directly to Agile or not. This can include technical discussions or more touchy-feely ones. As long as we are addressing difficult problems, we will be making progress.

I also want to see more cross-domains talks. Obvious domains are the heavy industry (I won’t need to remind how influential Toyota has been to the IT industry) or performing arts. But that could also include things such as Behavioral Economics.

Or not. I don’t know for sure. However, I do know that we should be taking more risks. And stop presenting Introductions to Retrospectives for the upteenth time.

At the end of the talk, I mention 2 things for further reading. Here they are, plus a bonus book that I’ve just read:

• Implementation Patterns, by Kent Beck
• Rands In Repose, a blog on technological culture and managerial aspect of life in an IT firm; posts are not frequent, but very interesting (and long)
• bonus track: The Logic of Life, a book by Tim Harford; this is very much in the style of The Undercover Economist (his previous books, which I enjoyed a lot) and Freakonomics (ditto)

The podcast is available in French on the Vox Agile site. Here is a direct link to the MP3 file.

I thought I would give more details here.

Our goals

We didn’t exactly manipulate the participants, but we certainly did not reveal, on purpose, what our goals were:

• help dissenting voices come out of the closet — very few people are vocally criticizing Scrum today in France, and I have found no blogs. I wanted to show the pro-Scrum side that they do not have the final word.
• let people vent — both pros and antis
• make participants think — one later came to me and suggested that I should have offered “alternative solutions”. Well, I have none (though I do have some starting points, see below)

Alternative endings

We had prepare additional materials, in case the discussion died out. Fortunately, it was so lively that we couldnt use them at all. You’ll find all three of them below.

You are not alone

The first thing I wanted to highlight is that, though dissenting voices on Scrum (or Agile) are not currently heard in France, they do exist in the rest of the world:

• James Shore has blogged that “when people say “Agile,” they usually mean Scrum” and that “it’s very easy for teams using Scrum to throw out design“. Finally, he points out that the “Scrum makes it worse by ignoring important (but hard) agile engineering practices, and the Scrum Alliance makes it worse still with their armies of trainers [...] issuing dubious “ScrumMaster” certificates to people“. There is more in today’s article on InfoQ.
• David Anderson lobbyied hard for an ‘Agile Fringe’ stage at Agile 2009 Conference, feeling that the vocal agile community is too mainstream. I agree with him, and I feel that the Agile 2009 program could have given more room to dissenting voices. The Agile Frontier stage is not bad, but it should have gone further.
• Naresh Jain says that Agile (as practices today) is the new waterfall.
• which reminds us directly of Steve Freeman’s aphorism, uttered during CITCON Amsterdam: “Scrum is the new RUP”
• some people did manage to get controversial sessions accepted to Agile 2009. Not all are directly related to Scrum:
  • JB Rainsberger: Integration Tests are a scam
  • Bas Vodde & Steven Mak: Let’s Stop Calling It Agile
  • Paul Hodgetts: ScrumMasters considered harmful – Where did it go wrong?
  • Brian Foote & Joseph Yoder: Big Balls of Mud: Is this the best Agile can do?
  • also, there might be good content at Linda Rising’s Agile: placebo or real solution?
• last but not least, Alistair Cockburn, author of the Crystal family of methodologies, signatory of the Agile Manifesto and Certified ScrumMaster Trainer, will host a keynote at Agile 2009 entitled “I Come to Bury Agile, Not to Praise It”

Scrum has Crossed The Chasm

There is a model that give hints to the current situation with Scrum. It is the Technology Adoption Life-Cycle, as amended by Geoffrey Moore in his seminal book “Crossing The Chasm“.

In short, it appears that many of the arguments against Scrum do not just mean that it is poorly explained, nor just that it is poorly understood, but rather that it is now being adopted by a large number of people. Or, to rephrase this, that it has been (consciously or not) packaged in order to be palatable to the mainstream. This implies trainings, books, consulting services, explanations, case studies, success stories. In short, packaging the approach just like a marketing team would do. That the people behind Scrum did it on purpose (as I believe) is beyond the point: the Agile approach that wins the hearts and minds of IT professionals everywhere is necessarily the one that comes with such as package, a whole product, in the words of Moore.

That is a reality that people that are blindly against Scrum must acknowledge.

ARXTA

Finally, I would like to point any aspiring Scrum-evil-ist to Brian Marick’s writing on Agile roots. His argument is that “Agile” (and, I guess, the names of pretty much all Agile methodologies) is too easy a term to adopt. In other words, many people will look at the name, glance at the practices, and quickly come to the conclusion that “hey, this is exactly what we’ve been doing all along! Let’s avoid asking ourselves hard questions and let’s not change the way we work.” Which is, obviously, missing the whole point.

Brian has came up with a new name for the roots of Agile: “Artisanal Retro-Futurism, crossed with Team-Scale Anarcho-Syndicalism.” The name is cryptic (and even slightly repulsing) on purpose, so that people will have to ask, and will have to have a conversation.

Further reading

Check out

• my photos of the notes taken on easel pads
• the transcript (in French) of the session by Nicolas Martignole (Google translation in English); he even has a recording somewhere on his site
• my notes from the session at CITCON Amsterdam 2008
• “Is Scrum Evil?” a question asked by Jeffrey on Stackoverflow

However, it can only go so far to prevent your code base from swelling permanently. In theory, if your revenues keep growing, you can keep recruiting more people in your development team, and all will be good. Unforunately, that’s not usually how software works.

Like many other things in life, software goes through well-known phases: birth, growth, maturity, and decay. At some point, the costs of maintaining the software are just not justified anymore and the editor pulls the plug.

However, we can do a little better than that. If the project still has some life in it, it can be a better plan to reduce its complexity, in order to lower its maintainance costs and increase its life. In fact, there is no need to wait for the product to decrease in popularity. Housekeeping should be done as early as possible in the lifecycle. No need to maintain features that cost more than they pay.

My current customer has exactly this problem. Their project suffers from feature creep. Regression tests become more and more costly to maintain (it is actually planned to delete some of them regularly — though, of course, nobody really knows which ones we can afford to throw away).

I would call the activity I’m promoting “Feature Refactoring: the process of changing a computer program’s list of features (and corresponding code) without modifying revenues significantly” (balancing short- and long- term revenues). This means that it is OK to remove some features, as long as it is acceptable to your customer base, in terms of money to make in the long term. Basically, you want to avoid the classic pattern where 80% features that are little used or not used at all.

Note that I am not merely talking about features representing significant weight in terms of code, tests, or documentation. Rather, I want to target anything that costs money to maintain, understand (for new hires), market, etc.

How can we do this? Well, here are a few smells that can help

• your client representative tell you about it — the easy scenario
• you detect that few customers actually use your modules – monitoring tools can help you here
• you find bugs in production… and few people actually complain about it — should this feature be there at all?
• you upgrade your project… and nobody complains — if your features are popular, someone is bound to complain about any change
• specs for a particular feature are not updated — features that do not evolve tend to rot
• run workshops with customers — a interesting format for this is Speed Boat

My point is that there are even more potential benefits in term of code maintenance when removing features, compared to refactoring the code base (which is a good thing to do, too).

Refactor your features. See this one there in the corner? You Aren’t Going to Need It.

You’ll be happier.  And you will probably save money.

As you might know, the AA board is meeting in person a couple of times a year and, for once, they decided to reach out to the crowd. This time, it happened in Paris.

Not much talking that evening; mostly networking, really. I got to talk to a few people that I had seen at Agile 2008, but couldn’t meet, because of the huge crowd. It’s too bad I couldn’t stay for drinks, since I was giving a training the following day.

Check out my pictures.

According to an interview of Jeff Sutherland, for every CSM, there are 10 Scrum teams that have not had training.  That is, 300,000 Scrum teams.

Finally, Scrum defines that a team is made of 7 people, give or take 2. Taking the conservative value of 5, this means that we have 1,500,000 people doing Scrum.

One and a half million?! Is it really possible? That said, even taking more conservative numbers, there is no doubt that many people are using (trying to use?) Scrum. The annual Agile Survey showed that more than 60% of agile projects are using Scrum, or Scrum combined with XP.

To be honest, this is probably off the mark but maybe not by an order of magnitude. Some estimates put the number of developers worldwide to something between 8 to 13 millions. I’d be surprised that even 5% of developers worldwide are using Scrum (400,000 to 650,000 individuals), but the 1,500,000 figure contains all people in a scrum team, including some that probably do not qualify as developers, such as business analysts, testers, graphical designers, etc. So it could work.

At least it would explain why many people now start to think that Scrum Is Evil.

I will be presenting 3 things:

• Retrospectives: the key to continuous improvement, together with Laurent Bossavit
• A 15-mins demonstration of Hudson
• Introduction to the Open Space part of the conference

I thought it would be a good idea to reproduce that version here. The French version is on the conference website.

Talk: Agile: Crossing the Chasm

Description: Agile Software Development is moving to a new level of acceptance in the industry. Geoffrey Moore has famously called this transition Crossing the Chasm. As this occurs, a number of significant changes in the rate and manner of acceptance of Agile are happening. These changes are often accompanied by legends, myths and other points of view. Some of them support the new point of view while others discount it. The keynote will explore many of the legends and myths that surround Agile and describe techniques for adoption Agile into the modern enterprise.

Jeff McKenna has been involved in software development for over 45 years and has been actively participating in the creation and delivery of agile software development since 1987. He has been involved in all areas of software product development from programming, system design and architecture to project management, testing, sales and marketing. Since the late 1980s Jeff has focused on the process side of development and along with Jeff Sutherland and John Scumniotales at Easel corporation in 1993 created the Scrum methodology of agile software development and started the very first Scrum team.

Jeff has worked extensively with object-oriented programming systems, languages and applications and was the Chair of OOPSLA in 1994 which helped to incubate and increase adoption of several related disciplines including agile software development. Working with IBM, Cigna, ObjectShare, Easel Corp, Millennium Pharmaceutical and the US Air force, Jeff provided expertise in architecture, design and implementation for their first Smalltalk based object-oriented projects.

As an Architect at Rational Software (now IBM), Jeff made various contributions to Rational’s industry leading Rose product. These included extensions to the Unified Modeling Language (UML) to support a UML model of testing. Jeff also worked with industry pioneers, including Grady Booch, to extend the Rational Rose product to natively support Design Patterns.

Jeff is a Certified Scrum Coach and Scrum Master, he has taught, coached and mentored agile teams using Scrum and Extreme Programming practices for many companies, including Oracle, PayPal, Borland, Vanguard, Microsoft, Google, Lockheed Martin, Tumbleweed Communications, V-Mark and Net Objectives.

Jeff is currently an Agile evangelist for Serena Software helping to build Serena Agile On Demand and working with customers and partners aiding the adoption of agile methods and practices in engineering organizations.

Willem and I thought that we had missed some of our goals (especially demonstrating Mockito), but still many people at the closing session mentioned that they enjoyed it :-)

We tried to prepare a bit before diving into the session. However, in practice, it became a bit chaotic, as many participants tried to make their opinion heard. This was very different than when I do that in trainings or even at Valtech. I guess this is because there were quite a few people (~20) and most of them were rather experienced and strong-headed (I guess they wouldn’t be at such a conference otherwise!).

We managed to have a quick retrospective at the end. Here are some of the things we learnt:

I need to experiment a bit more with Coding Dojo for Legacy Code, but I feel that the format is rather good. Next year, we’ll do better!