Agile is for cavemen

I am currently reading The Tipping Point, by Malcolm Gladwell. In the book, Gladwell quotes the anthropologist S.L. Washburn:

Most of human evolution took place before the advent of agriculture when men lived in small groups, on a face to face basis. As a result human biology has evolved as an adaptive mechanism to conditions that have largely ceased to exist. Man evolved to feel strongly about few people, short distances and relatively brief intervals of time; and these are still the dimensions of life that are important to him.

Once you think about it, it sounds so obvious that humans are still wired as they were back when they dwelt in caves. It is therefore also natural to feel comfortable in a work environment that reproduces this kind of setting.

In Agile, small teams of five to nine people are recommended. Agile also recommends that team members be collocated, in a single room. Those practices aim at maximising the efficiency of communication and team work while minimising the required amount of ceremony and waste in communication. Those therefore facilitate face-to-face communication as well as osmotic communication, as Alistair Cockburn names it. Agile is therefore an approach to software development that befits our cavemen brains.

Dispersed teams and informal communication channels are thus completely unnatural. Nevertheless, even though our brains haven’t evolved much since the times of our hunter-gatherer ancestors, our societies tend to put more and more distance between people while offering loads of means of communicating and sharing any form of information.

Food for thought…

Comparing Java Mock Frameworks – Part 1: The Contenders

Update 2010/10/06:  I removed rMock from the list because it hasn’t been maintained for a while. I might take a look at it some other time.

Update 2010/09/24: I removed the comparison of spying capabilities. Indeed, I believe that such frameworks are not intended for state verification but behaviour verification and stubbing only.

This is the first instalment in the series Comparing Java Mock Frameworks. Here, I present the frameworks that I intend to compare. The whole series consists of the following posts:

Since a while ago, I wanted to line up the major mock frameworks in Java. I am used to Mockito, which I must say I utilize a lot when I have to deal with Test Doubles.


I must confess that I very often use a mock framework instead of writing my own test doubles, even in trivial cases. I find it quite handy because, I don’t have to care about those mocks if I later change the interface of the mocked class. Others prefer writing their own mocks in many cases.

I use mock frameworks when I need to impersonate a class for the purpose of testing the behaviour of the class under test. I mostly follow the following patterns:

  • Test Stub: I need to replace a class in order to return values when the class under test calls some methods on the object. I can also use the test stub to throw an exception to test error handling in the class under test.
  • Mock Object: I need to replace a class in order to verify how the class under test interacts with the mock object.

In a mini-series of posts, I will compare mock frameworks for Java to determine which ones best suits me. Here is the list of the different ways I will use them for the comparison:

Instantiation and overriding
  • Obtaining a test double for an interface
  • Obtaining a test double for a class
  • Obtaining a test double for a final class
  • Overriding of final methods in a test double
  • Overriding of static methods in a test double
Test Stubs
  • Returning a single value
  • Returning multiple values orderly
  • Throwing an exception in a non-void method
  • Throwing an exception in a void method
Mock Objects
  • Verify the number of invocations of a method
  • Verify the order of invocations of a method
  • Verify the arguments of an invocation of a method
Fluency of the API
  • The closer to natural language, the better
  • Ease of set up
Specifics Features that make the framework stand out of the crowd

Here are the frameworks that I will compare:

Framework URL

I will evaluate the frameworks based on my needs. I won’t claim that everyone should, from now on, use the framework I’ll choose 🙂


Evolutionary requirements, incremental design, refactoring and rework

Yesterday, I had quite a lively discussion with a colleague of mine. He wants to do Scrum. He wants to do Scrum but still wants to spent some weeks on upfront analysis and design. He does not believe in evolutionary requirements and design. One of the reasons for defending that position is that he considers that incremental means a lot rework. He also assimilates refactoring and rework. Consequently, he deduces that being evolutionary means reworking existing code each time we would implement a new feature.

As you might have guessed, I argued the opposite. I’ll try and explain why in this post.

First, let’s start off  by defining refactoring, rework and rewrite.

  • Refactoring: Change the code to improve it in terms of readability, maintainability, cleanness, reuse, etc while preserving functionality. If there are bugs, they remain in the code. When you refactor, you don’t change functionality.
  • Rework: Change the code to change its behaviour, for example to fix bugs or improve performance and stability. Rework entails changing the functionality. You did the wrong thing and want to do the right thing.
  • Rewrite: Scratch something and start afresh. You obviously did the wrong thing and did it wrong.

In Agile, you build the system iteratively and incrementally. You only write code for the scope of your iteration, no more, no less. This means that the functionality will change for sure. That’s not a problem because, thanks to the rapid feedback, you usually will seldom need to completely change too much completely.

By doing incremental design, you:

  • Code only to implement what’s in the scope of the sprint.
  • Design only to fulfill the needs of the scope of the sprint.

Plan stories earlier if you need to minimise risk and generalise some design early.

  • Triangulate to generalise behaviour instead of thinking ahead a so-called generalised behaviour and that will not be used after a while and possibly never.

By doing so, you eliminate waste:

  • By coding only for the functionality at hand, you don’t overdesign. The code you write is tested and accepted by the end of the sprint. If you wrote code for future needs, it would not be accepted because the functionality would not be tested
  • You don’t code anything based on speculations. The code you write is used and exercised immediately.

Iteration after iteration, you write new code and change existing code. Usually, you do the following:

  • Refactor continuously so as to keep you code base clean and don’t incur technical debt.
  • Rework periodically to fix bugs and misunderstandings. This usually happens during the sprint and concerns little portions of code. If defects made their way to production, the code will be fixed during a future sprint.
  • Rewrite seldom, except if you incurred a lot of debt or that something was done completely wrong.

The continuous refactoring allows for keeping the code clean and easier to evolve. Such evolutions usually take the form of new code driven by tests. Once the tests pass, refactor the code to avoid duplication and keep it clean.

In conclusion, you refactor a lot, rework a little and rewrite as less as possible.

Some interesting links on the topic:

Learning and Growing with Agile

I work for an organisation that thinks that juniors can’t design. Even worse, they still think that because of this alleged lack of skills, they need to be fed design. Consequently, projects needs “designers” that just do big upfront design.

I say no! I even say, don’t give them anything! Instead, coach them, give them opportunities to try and learn and propose.

I see several practices that help addressing the topic:

  1. Design sessions: During those short sessions, have more senior roles (seasoned developers and architects) work out a design with the juniors. This is highly beneficial because they are an active part of it. They better understand what to implement afterwards because they know the reasoning behind. The most important is that they learn how to tackle design.
  2. Pair Programming: Have a senior and a junior work together on a story. Alternate roles so that the junior can play both the driver and navigator roles.
  3. Test Driven Development: TDD is all about design. Designing for testability, YAGNI, baby steps, incremental design, refactoring.  Do  ping-pong pair programming. They once write a test, they once implement the code to pass a test written by the team mate and they once refactor. Then repeat.

The benefits of this approach is that the process is much leaner. If we try and map the benefits to the seven lean principles:

  1. Eliminate waste: No time wasted on lengthy designs that will never be accurate. No overproduction of design.
  2. Build quality in: No need fork any rework after implementation. Peer reviewing is immediate thanks to pair programming.
  3. Create knowledge: Both juniors and seniors learn and grow their skills.
  4. Defer commitment: Design just in time.
  5. Deliver fast: Design just in time and enough leads to a shorter lead time.
  6. Respect people: Juniors are respected and considered fully skilled team members
  7. Optimise the whole: Team improves, no constraint on expected design, rapid feedback on the design.


Agile and lean practices really help getting juniors up-to-speed. IT helps them grow while optimising the process and being respectful of team members. A great benefit is also that it’s much more fun to work that way!


Pair Programming
Lean Principles of Software Development
Test Driven Development
%d bloggers like this: