Here I was, merrily testing my way through a piece of software that sends emails. According to the Java Mail documentation, you are supposed to first create an email session as follows:

Session mailSession = Session.getInstance(properties);

(it is worth noting that all what the getInstance() method does is call the private constructor for Session: new Session(props, null)).
Had Session been a more normal class, I could have mocked it like that:

Session mockSession = mock(Session.class);

and probably checked how it is being passed around like this:

verify(someService).startEmailSession(mockSession);

What follows is what I have to do instead.

The case of static methods

If getInstance() had been an instance method, I would have been able to mock it:

Session mockSessionProvider = mock(Session.class);
Session mockSessionInstance = mock(Session.class);
when(mockSessionProvider.getInstance()).thenReturn(mockSessionInstance);

Unfortunately, a static method cannot easily be mocked with Mockito (other mocking frameworks support that, but I believe they make the tests too obscure). So, first step: create a wrapper class just for the builder method.

public class SessionProvider {
	public Session getInstance(Properties properties) {
		return Session.getInstance(properties);
	}
}

The case of final classes

So far, so (relatively) good. However, since Session is a final class, the usual mocking mecanism under Mockito does not work:

SessionProvider mockSessionProvider = mock(SessionProvider.class);
Session mockSessionInstance = mock(Session.class); // fails because Session is final
when(mockSessionProvider.getInstance()).thenReturn(mockSessionInstance);

The case of private constructors

Another option would have been to instantiate the session instance, but that fails too, since the constructor is private:

SessionProvider mockSessionProvider = mock(SessionProvider.class);
Session sessionInstance = new Session(properties, null); // fails because constructor is private
when(mockSessionProvider.getInstance()).thenReturn(sessionInstance);

A third way might have been to call the original Session.getInstance() to create the test object:

SessionProvider mockSessionProvider = mock(SessionProvider.class);
Session sessionInstance = Session.getInstance(properties);
when(mockSessionProvider.getInstance()).thenReturn(sessionInstance);

That would work, but that also opens a whole new can of worms. Session does not implement the equals() method, so if I want to check the value of the Session instance passed around, I must either:

• compare with the pointer to the sessionInstance — the issue is that there is no way to check that the session has not been changed (any call to a setter method on the session instance will have no effect on the comparison of pointers)
• implement a generic deep equal matcher for Mockito — something we did at my company, but that I am reluctant to do myself
• use an argument captor to catch the instance passed and test — which produces a fair amount of awkward lines of test
• create a custom argument matcher — which hides the comparison in a separate class or method
• yet another is to wrap the instance of Session in yet another class, such as SessionInstance — which would require us to also wrap any service that takes an instance of Session

So we also need a wrapper for the Session instance:

public class SessionInstance {
	private final Session session;

	public SessionInstance(Session session) {
		this.session = session;
	}

	public Session getSession() {
		return session;
	}
}

Which forces us to change the SessionProvider:

public class SessionProvider {
	public SessionInstance getInstance(Properties properties) {
		return new SessionInstance(Session.getInstance(properties));
	}
}

At last, we can mock this way:

SessionProvider mockSessionProvider = mock(SessionProvider.class);
SessionInstance mockSessionInstance = mock(SessionInstance.class);
when(mockSessionProvider.getInstance()).thenReturn(mockSessionInstance);

Done? Hardly. All other, possibly mockable, classes from third-parties that rely on instances of Session must now also by wrapper. For example, a third-party JavaMailTransport that requires an instance of Session now needs its own wrapper if I want to test it. Sigh…

A reminder on how varargs work: essentially, they allow the last parameter of a method to be made of zero to many values of the same type.
For example, a method like this:

int max(int... values) {...};

is used by code like that:

int maximum = max(1, 2, 7, 0);
int maximum = max(1);

In truth, that form is only moderately useful in production code. It turns out that, on my projects at least, it is not so common for methods to be called with varying number of parameters. And in those cases, it is often acceptable to simply overload a method with more parameters.

There are however at least two cases where varargs shine.

One is in utilities classes. For example, Math.max() only takes exactly two parameters. Which comparisons between 3 or more elements very awkward. If a varargs had been used, Math.max(3, Math.max(1, 4)) would be written Math.max(3, 1, 4). Agreed, that does not happen that often. But it does occasionally.
(I must admit that I do not understand exactly why Math.max() has not been modified to take a varargs nowadays)

However, the biggest benefit, I believe, is in the writing of tests.
Tests tend to contain lots of variations in the values passed to the code under test. And it is critical to keep the clutter to a minimum.
For example, here is how a typical series of tests might look like

@Test
public void should_find_the_longest_name_for_a_single_user() {
	List users = new ArrayList();
	users.add(new User("eric"));
	assertThat(findLongestName(users), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	List users = new ArrayList();
	users.add(new User("eric"));
	users.add(new User("cecile"));
	assertThat(findLongestName(users), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	List users = new ArrayList();
	users.add(new User("cecile"));
	users.add(new User("eric"));
	assertThat(findLongestName(users), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	assertThat(findLongestName(new ArrayList()), is("eric"));
}

Of course, they can be made a bit nicer using the varargs in Arrays.asList():

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(asList(new User("eric"))), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	assertThat(findLongestName(asList(new User("eric"),
		new User("cecile"))), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	assertThat(findLongestName(asList(new User("cecile"),
		new User("eric"))), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(Arrays.asList());
}

However, the real goodness comes when writing our own builder method:

private static List users(String... names) {
	List users = new ArrayList();
	for (String name : names) {
		users.add(new User(name));
	}
	return users;
}

(side note: I like this type of methods to be private -so that I get notified when they are not used anymore- and static -mostly because they look nicer in italic, which makes it clearer that they are not part of the code being tested-)

which allow our tests to become:

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(users("eric")), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	assertThat(findLongestName(users("eric", "cecile")), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	assertThat(findLongestName(users("cecile", "eric")), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(users());
}

Tests become a lot shorter, consistent, and easier to read. In fact, at this point, it is worth grouping the tests (at least those that do not throw an exception) into a single one:

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(users("eric")), is("eric"));
	assertThat(findLongestName(users("eric", "cecile")), is("cecile"));
	assertThat(findLongestName(users("cecile", "eric")), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(users());
}

Final note: I prefer not to group those builder methods into a general utilities class — I tend to duplicate them in each test class. One reason is that I prefer keeping much of the test code close together. Another is that I tend to change the name of the method from test class to test class to make the code more fluent. Also, I think that DRY principles are not as important in the tests as they are in the production code.

This lead to an interesting discussion yesterday on Twitter with Deborah Hartmann Preuss, Alexandru Bolboaca, Willem van den Ende, Brian Marick, and Jeffrey Fredrick (see transcript at the end of this post).

I think most Agile personalities have become addicted to the relatively easy money of consulting. Why would they risk get a software product out in the highly competitive software market? It is so easy to just found your own consultancy. It is probably related to age, too, as you do need to have lots of spare energy for late night coding (Paul Graham once wrote that the ideal age to start a startup was between 23 and 38).

In fact, as I argue below, I do not believe that “being agile” is viewed as a desirable trait for a startup and I’m sure it might even deter some of the most likely candidates to create one, as it is now viewed as a process for medium to large companies. What is viewed as needed is raw hacking powers, even if that means making things hang together with duct tape. Agile techniques might be preferable, but their ROI will become mostly apparent after two years, an eternity for a startup.

So, Agile luminaries are not starting software development ventures, and the founders of successful startups that use Agile techniques probably do not have the time or the will to tell the rest of the Agile world how they did it.

This is regrettable. I wish there was more cross-pollination, like 37signals has done with Getting Real. Where are the others?

Transcript of our conversation on twitter:

• elefevre Wondering why so few Agile luminaries are into the commercial software business.
• alexboly @elefevre I think Kent Beck said it best: “As a business man, I’m a very good software developer” :)
• elefevre @alexboly interestingly, he seems to be the only one actually trying to make a living selling software (seems hard)
• mostalive @elefevre because they are too busy consulting or marketing? want to publish own commercial product? work happens in odd hours -> slow
• alexboly @elefevre As a programmer I would rather live in Castalia (http://goo.gl/AzQn) As a business man, I need to live in the real world.
• elefevre @mostalive sure they do consulting. But if agile dev is really better, then products they would make ought to be better too. => Profit?
• DeborahH @elefevre I guess Mike Beedle (PatientKeeper) is an exception, then. Co-author of first Scrum book.
• mostalive @elefevre Profit yes, and, consulting & product development don’t really mix, as the business drivers point in opposite directions.
• DeborahH @elefevre ken Schwaber came from sw dev company iirc, but perhaps you can’t change the world AND refactor your codebase at once. Or?
• mostalive @elefevre agile tool vendors may be the exception, however their consultants can not recommend the best tool for the context (post-its ;))
• mostalive @elefevre and if a product is successful, it generates so much revenue, that consulting revenue is irrelevant.
• DeborahH @elefevre … Then they wouldn’t be luminaries in the sense of “visible as a teacher, writer” imo: these things are jobs in themselves.
• DeborahH @elefevre though I respect more those who take time for practice as well, it grounds one’s teaching. But usually on s/one else’ project?
• elefevre @DeborahH yes. Maybe if you’re busy developing (not consulting), then you have less time & inclination helping others.
• elefevre @mostalive also, I suspect majority of (or the best known) consultants from Agile Tool vendors are more business-facing type than developers
• DeborahH @elefevre until recently, Jeff was CTO @ PatientKeeper.http://bit.ly/ctQJRb Once yr own house is in order, you gotta get a new challenge?
• elefevre @DeborahH @mostalive @alexboly I think my point could be: are successful/rich developers/hackers really applying Agile techniques?
• elefevre @DeborahH @mostalive @alexboly or is Agile orthogonal unnecessary for a successful startup? (maybe I’ve been reading too much Paul Graham)
• elefevre @DeborahH @mostalive @alexboly I think that, in a startup, techniques might be “agile”, but do not need to be identified as such
• elefevre @DeborahH @mostalive @alexboly while, in a bigger biz, it helps that people can relate to a consensual definition of development process
• elefevre @DeborahH @mostalive @alexboly in our startup, we are 3 former Agile consultants (out of 5 devs), but we take care not to say we’re agile
• alexboly @elefevre @DeborahH @mostalive Agile doesn’t exist. Agile tools exist. Do you need agile tools for a succesful startup? I think you do.
• alexboly @DeborahH @mostalive @elefevre Do you need to call the agile tools “agile” in order do succeed? Of course not. :)
• DeborahH @elefevre “Agile” is a means to an end. You cannot afford to primarily “be agile”n you must be primarily busines owners!
• alexboly @DeborahH @mostalive @elefevre The point was never to “be agile”, it always was to build software in a way that increases the success rate.
• elefevre @DeborahH @mostalive @alexboly there might even be a stigma to calling things “agile” in a startup. Not hip (anymore)
• DeborahH @elefevre surely “hipness” is not more important than profitability? Like “agility”, “hipness” sounds like a red herring, to me.
• alexboly @elefevre @DeborahH @mostalive I’d like to see that people don’t talk about agile anymore but do the right thing. Human nature loves labels.
• elefevre @DeborahH certainly is a red herring. But I do think it’s important for startups, often packed with smug hackers. #overgeneralization
• marick @elefevre I don’t have any good product ideas. I don’t have skills to do it all & it’s a big step from 1-person company to N-person company.
• elefevre @marick my thinking is that the mobile market is more tolerant of seemingly mediocre ideas than the desktop/enterprise space
• DeborahH @elefevre @marick perhaps because in mobile market short release cycles allow products to “grow up” in public?
• elefevre @DeborahH @marick I think it’s because there are fewer high-standard apps, so users tolerate mediocre ones. eg. quizzes, website wrappers
• Jtf @elefevre I think people who are successful consultants are addicted to fast feedback from helping. Products are delayed gratification.

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.

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.