Embrace change or embrace uncertainty

Kent Beck wrote a very nice book eXtreme programming explained with the subtitle “Embrace change”. But what he really want to embrace is uncertainty. What is uncertainty? It is those things that will happen but you are uncertain of. Possibly so uncertain that you haven’t even thought about them in a risk analysis. It is the very nature of uncertain things, you don’t think they ever will occur and can therefore not even think they might happen. They will therefore never turn up in a risk analysis.

This is what Agile and XP is all about. Handling uncertainty. Instead of taking long leaps, you frequently stop, inspect and adapt. You always tries to have the shortest possible feedback loop. You deliver working software and evaluate if it brings the values you expected it would bring. Then decide what to deliver next.

Inspecting and adapting doesn’t mean that you shouldn’t think and try to come up with reasonable risks that you want to prepare for. But at the same time, it doesn’t mean that you should stop and think forever about the risks and never deliver anything.

So embrace the uncertainty and make sure that the way you work support you as much as possible.

Resources

• eXtreme programming explained
• Thomas Sundberg – The author

Test drive an implementation using an Executable Specification – revisited

An example is perhaps the best way to describe something. Concrete examples are easier to understand than abstract descriptions.

I will show how Cucumber-JVM can be used to specify an example and how the example can be connected to the system under test, SUT. The example can then be executed using any IDE or using Maven.

Want change and is willing to change

If you want changes and are willing to change, where should you start? When should you stop?

This is a very large subject. Books are being written on it. And it will always depend on the situation. But lets assume a few things.

• We are talking about software development
• We want our product to be awesome and profitable

Want change but don’t want to change

I have met several customers and potential customers that want to implement automated testing. They have been in very different areas; insurance, transport, telecom and so on.

One thing they have in common though, is that they want a change but they are reluctant to change.

Pair Programing

How do you solve a problem best? In your solitude alone or in a group? I know that I solve problems better in a group. The group has to be small so you don’t get disturbed. But it has to be large enough so a discussion can occur.

Programing is not about writing text fast. Typing is never the bottleneck when programming. The bottleneck is problem solving and solving the right problem.

Pair programming is about two persons that solve a problem together. Problem solving in a group tend to result in better solutions. Different people see a problem from different angles. The result is usually better than a solution that one person came up with.

Challenging requirements

I attended a session with Gojko Adzic at Valtech in Stockholm in feb 2012. Gojko had some great comments about requirements and especially challenging requirements. A challenging requirement is a requirement from a customer that there is some kind of issue with and therefore something that will bring you problem.

The simplest possible solution

The simplest possible solution that could work. Ever heard that expression? What does it mean? Really?

The answer is obviously something that in a really simple way satisfies the test you currently are working on. Nothing more, nothing less.

Testing a Web Service with SoapUI, JUnit, Maven and Cucumber

An example is perhaps the best way to describe something. Concrete examples are easier to understand then abstract descriptions.

I will show how SoapUI can be used to test a web service. I will also show three different tools that can be used to control SoapUI. This tool chain can easily be made a part of your continuous build.

Test drive an implementation using an Executable Specification

An example is perhaps the best way to describe something. Concrete examples are easier to understand then abstract descriptions.

I will show how Cucumber-JVM can be used to specify an example and how the example can be connected to the system under test, SUT. The example can then be executed using any IDE or using Maven.