Play makes web development easy

I’ve been looking quite a bit at the play framework lately, after receiving a tip from Arild, one of my colleagues at Miles. I’ve been amazed by how easy it is to build web applications with the framework. You can really accomplish a whole lot with very little code, a very attractive feature indeed. Fewer lines of code means fewer bugs and fewer bugs means less maintenance and more time to deliver new stuff. A positive feedback loop.

From Scrum to Kanban – Introducing change

Agile software development is not about whether you do Scrum, XP or Kanban. It is about finding a process that works in the environment you’re in. Finding this can be hard, and doing so certainly require reflection about what you are doing, how you’re doing it and why. One thing’s for sure, if you are doing something and it doesn’t work: Stop doing it!

BDD with Scenario tables in Fitnesse Slim

I think writing functional tests in a given-when-then style manner is a great idea. Tests tend to be clearer and more precise when written this way. There are quite a few tools too choose from. Cucumber by Aslak Hellesøy seems to have a lot of momentum these days and is an acceptance testing framework definitely worth considering.

However, the customer I work with has been using Fitnesse for a number of years now, which means people are familiar with this framework. So going for the new Fitnesse Slim framework seemed like a step in the right direction.

Kanban – the next step in the agile evolution?

The software industry has embraced agile methods. A rising number of teams is now trying to deliver value incrementally in small iterations. This is of course a good thing. Customers get new functionality more frequently out into the market, an increasingly important factor in a competitive global economy.

The innovators and early adopters of agile methodologies were able to deliver great results using agile methodologies like Scrum and XP. But these early adopters were software craftsmen, proud developers of well-crafted software with lots of enthusiasm and good communication skills in addition. These early agile teams would probably succeed using less agile methods than Scrum and XP. Now the agile train has really started rolling, the majority has “seen the light” and even the laggards are starting to think that this might be worth looking into. Should we be happy? Or is it time to get just a little bit worried?

JavaZone 2009

Nearly one week since this years JavaZone conference with around 2000 attending. Time for some reflection: The agenda was published fashionably late and with 6 parallel sessions, picking the right talk seemed like a challenge.

Behaviour Driven Development with Mockito

I’ve been using EasyMock for 3 years now, and have been quite happy with the way it has helped me to test drive development. Sometimes though, I’ve felt that my tests have become hard to read. Hard to read tests is often a test smell and a sign that the code is poorly factored so I should be careful blaming this all on EasyMock. Seriously, EasyMock has been a good friend and I wasn’t really looking for a replacement. But then I stumbled across the Mockito mocking framework

Disabling tests in Maven

Sometimes you want to disable tests in Maven, f.ex integration tests that you need to just do quick tests against an external component. These are brittle tests and should therefore not be part of the automatic build …..

Running fitnesse from Eclipse

I believe that running fitnesse from inside of eclipse is a good idea. When Fitnesse is using my eclipse classpath I can modify my code without having to restart fitnesse. This gives me nice, short cycles and is major efficiency boost. A good colleague of mine, Morten Udnæs, had created a small start up class for Fitnesse in Eclipse. But when upgrading to the latest stable release of fitnesse (20090709) I found that I had to modify this class a bit – Uncle Bob has done quite a few refactorings over the last couple of releases.

Agile testing

The vacation is over and a new project is just around the corner. As an iteration zero we have working on setting up the technical infrastructure and tried to carve out a test strategy for the development. In this project we really want to practice a test first strategy, not only for unit tests but also test driving the requirements. This means that before development of a feature can start, a set of acceptance tests should be written in a form that makes it executable. We’ve been using fitnesse (old style) for this for most of our previous projects. But it turns out that neither developers nor testers are particularty satisfied with the current solution. Developers thinks it is tedious and time consuming to develop and maintain tests investment. Testers too find it hard to use (for other reasons than developers, but that’s another story) and we find they often skip the regression tests suites because it is to hard to use.  If it is hard to use then people will avoid it.

Help! My development environment is killing my productivity

No question about it, as software developers our single most important task is to delive business value for our customers. The software industry is turning their back to the classic waterfall style of development and embracing agile methodologies. Still, teams struggle to deliver functional value at a regulart steady pace. There might be several reasons why this happens. In this post I like to focus on one important factor in the process of software development, the development environment.