This is a true story of a company. At the first of January this year ago this company was a great idea and a few pictures. It had been like that for a while. At the first of April it was a company with a production website doing actual business with actual clients. The 12 weeks in between that have been awesome, nerve-wrecking and scary at the same time. We’ve had to let go of some really cool features and we’ve found out things about the business case that we definitely didn’t know when we said we could build it in such a short time. At the beginning of the project I invented the term “Oh shit erlebnis” and I’ve had a few since then.

Because we were working in short iterations (1 week Sprints), we had awesome focus and we could deal with most discrepancies between dreams and reality quickly.

Read more →

In the past years there has been much ado about the quality of software. Programmers have emancipated and evolved into software craftsmen. Metrics have been defined and honed to measure the quality of code and deliverable artifacts. More and more of our clients are asking for guidance in achieving higher and higher quality goals.

The discussion about software craftsmanship hasn’t been all positive. Many developers that I’ve worked with express the feeling that certain levels of quality are only driven by the personal gratification of craftsmen and not in line with the economic realities of our trade. In this article I strive to establish guidelines in the compromise between quality and speed. I feel it is warranted to be more nuanced than the simplistic statement: “Going fast by going well”. This is because “going well” can mean different things in different contexts.

I look for a line in the sand between improving quality to improve procreation and improving quality for mere self indulgent practice.

Read more →

Sharing knowledge is one of our core values and as lot’s of research confirms knowledge transfer is best done between peers. We have a great knowledge sharing platform at Xebia through bi-weekly evening sessions, where we do some experimental coding and some presentations. Once in a while we take it to the max and organise a tech rally. One of those happened last Friday and it was a total blast. I’ll give you some of the highlights. More detailed posts on the technical details will follow and I’ll update the list below as they do:

• Git tricks we learned in the commit frenzy

Read more →

In the current market it becomes more and more likely that developers in the same team will not be in the same physical location. This is caused by outsourcing, but also other reasons like ever increasing focus on open source projects.
In a distributed scenario pair programming has huge benefits over meetings and sending comments on issues around. It is (still) the fastest way of sharing detailed information between people, and it actually gets the job done where a meeting does not.
The added benefit of pair programming in a distributed team is that it bridges the gap between the local team and the remote team that is caused by the fact that informal communication is impeded. Research has shown that pair programming works in distributed teams [1]. The challenge is to find out how to make it work for you.
In my previous blog on Pair Programming I focussed on the different styles that I see in my daily practice and ways of improving the dynamics in a pair. This applies equally to colocated pair programming and distributed pair programming. At my current client I bumped into the issues particular to distributed pairing, so in this blog I will outline habitual and technical prerequisites for successful distributed pair programming.
Read more →

Without exception in all teams I’ve developed software in people have expressed their aversion against pair programming. It’s not that developers don’t want to try, or that they don’t believe it will help. On the contrary, they are usually very enthusiastic about trying it and give it more than a fair chance. After a few days they sit alone behind their keyboard coding like zombies with headphones. What’s going on? Is pair programming too hard? Doesn’t it pay off? In this post I’ll try to explain what I think is happening, and I will give you some clear pointers to avoid the traps. At the end I will go into distributed teams and what part of the game changes there.

So what are people saying when they have stopped pair programming and you ask them why:

• I’m faster on my own
• Can’t pair with that guy, he’s getting on my nerves
• Pair programming is too tiring
• We’ve split up the work and we’ll get it done faster if we use two keyboards
• There’s too much background noise
• I’m just slowing her down

Some of this might sound plausible, so let me axe that down first. No you’re not faster on your own, you’re just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you’ll turn into a better programmer. Or maybe you can teach him something and he’ll stop getting on your nerves. If your code is so simple that you can split up the work in advance you’re writing it on too low an abstraction level, or you need to work on this in two pairs. If you’re slowing the other guy down, that’s a good thing. That will prevent him from writing code that you cannot maintain. If you don’t feel worthy of your colleagues code, get over it, or get off the team.
Read more →

A lot of automated acceptance testing pioneers have come around and denounced their fate in heavy automated test suites. A recent article on InfoQ sums up the trend quite nicely. I am not going to jump on that bandwagon, but I will try to find the safe middle ground between the overzealously created maintenance burden and anarchy. The main point is that automating acceptance tests is the way to go, you just shouldn’t automate and maintain useless tests. The tricky part is to find out what tests are useful and what tests are not.
Read more →

Git has made me more productive, and I will explain in a few words why that is. I could almost do it with twitter, but I like to take a little more time to make my point. The main benefit that git has given me can be found in performance of certain things I want to do when I am managing changes in my code base. The performance improvements of some critical parts of it are even so profound that they have changed the way I am working. In particular the fact that I can skip builds for most of my commits is a big time saver.

There have been many things said about git already and I suggest you use your favorite search index to bring yourself up to speed if you need to. Git is a simple distributed versioning system that is challenging many assumptions I had about development. Let’s go over these assumptions. I’ll show you my (svn based) assumption and why it doesn’t hold if you’re using git.
Read more →

Concurrent testing is hard, but not as hard as you think. If you use the right tricks it can be done. This blog shows you one particular trick that uses a latch and a mock to ensure a test scenario is completed before running the verifications.

While working on Spring Integration in Action, I experimented with a neat solution for concurrent tests. When I showed it to some colleagues I was pleasantly surprised by the reaction that I got. Judge for yourself if it’s worth the blog.

The main idea is to use a latch and let your mock count it down. It sounds trivial (and to be honest it is).
Read more →

Last week I’ve added a new test bundle to Spring Integration. This bundle contains matchers to help writing tests for Spring Integration configurations. It builds on JUnit 4, Hamcrest and Mockito. Even if you’re not a user of Spring Integration, I will make sure that this post gives you a few ideas for using matchers to write more readable tests.

First a few pointers to Spring Integration to give you some background.

Spring Integration is a framework that aims to implement Enterprise Integration Patterns as described in the book by Hohpe and Woolf. The book is nice, but using those patterns will require some boilerplate and plumbing that is a good match for a framework, hence Spring Integration. JUnit 4 you should know about already, but a feature that was added recently deserves another mention. In the latest versions of JUnit you can use the assertThat(T actual, Matcher<T> matcher), which builds on Hamcrest matchers. This already makes your assertions much more readable, but combined with Mockito, test cases become poetry. I will assume for now that I don’t need to tell you about all this, but if you have no clue what I’m talking about you should really enlighten yourself.

EIP frequently involves asynchronous handoff, also it involves wrapping object payloads in messages. Both of these can be in the way when writing tests. Luckily we can easily abstract this boilerplate away. Today I’ve committed the solution for the unwrapping problem, I’ll talk about a solution to the second problem another time.

Unwrapping messages requires some boilerplate that makes the test harder to read. The following snippet from the Spring Integration’s AggregatorEndpointTests clearly shows both problems.

[source lang=”java”]
@Test
public void testCompleteGroupWithinTimeoutWithSameId() throws Exception {
//…
Message<?> reply = replyChannel.receive(500);
assertNotNull(reply);
assertEquals("123456789", reply.getPayload());
}[/source]

In a few seconds it’s clear what we’re trying to do here, but it doesn’t look very elegant to me. With the new test project we aim to make this type of code more readable. To do this we’ve created some utility classes.Read more →