Thinking Inside a Bigger Box

I have been watching videos from the Technology, Education and Design conference (TED) all afternoon. One particularly fascinating talk was Barry Schwartz talking about The Paradox of Choice. I find an almost Buddhist-like understanding of the problem of humanity in the modern world in his talk. But it was the closing words that fascinated me the most: “If you shatter the fishbowl, so that everything is possible, you don’t have freedom, you have paralysis.”

CIO JP Rangaswami at investment bank Dresder Kleinwort Wasserstein talks about why he considers open source a corporate IT asset. In this talk, Rangaswami describes how DrKW wanted to create an internal incubator environment in order to combat skill attrition in the late 90s. In the course of doing this, they acquired OpenAdaptor and discovered almost accidentally benefits of the open source development model.

Read the rest of this entry »

This post is currently only a draft. Input on how to improve the structure is very welcome

“A journey of a thousand miles begins with a single step.” – Lao-Tzu

When doing architecture, we always have to content with the present state of the system. It is extremely tempting to ignore this picture of the ugly system and create your vision of how things should be in the future. It is also very easy to get people to agree on such a vision. But somehow, we never get there. Have you ever wondered why that is?

Most people are pretty good at making a plan for how things should be in the far future. But we’re not sufficiently prepared to make a plan about how things should be right now. This is what I mean when I say we suffer from too little myopia.

As a tool to get there, I have found the Twelve-Three-One paradigm useful: We have a goal for what we should achieve in twelve months, three months and one month. The twelve month perspective is our goal – for example to change from EJBs to POJOs, to consolidate four applications on one server, or to deliver our big project. When you’re planning, this can be extremely fuzzy without putting you at risk. The three month perspective shows the direction we’re going to get there, for example, exchanging your entity beans with Hibernate, or duplicating all applications to the target server and slowly moving all dependencies to it, or to put a limited part of our system into production. This can be vague, but should represent our current working hypothesis on how to get there. The one month perspective shows the next step. It should be as finely planned as you require to get anything done in our organization (for example: copy the foo.cfg file to server-1 and modify these settings).

Read the rest of this entry »

Sverre Huseby examines some security issues with Spring-MVC. As it turns out, the Spring JSP form-taglib provide no HTML-escaping by default, making it very easy to get Cross-Site Scripting vulnerabilities included in the code. The article comes complete with a standalone application that illustrates the problem.

Update: Added retrospective result example

I learned by favorite team building exercise on the ROOTS conference in Bergen three years ago. Alistair Cockburn conducted a great workshop that really drove home the lessons of iterative development at the same time as it showed a very useful technique for conducting retrospectives. I have later conducted the same exercise as a workshop in different situations. Maybe the most fun occasion was Oslo XP Meetup March 2006

The workshop works like this: The participants are divided into teams of six or so. It works best with about four or five teams. Each team is further subdivided into “developers” and “customers”, which sit apart during the workshop. When the exercise begins, the “customers” will be given a picture on a piece of paper. They are to describe the picture to the developers using only written instructions. Only one “customer” can visit the “developers” at any time. The teams are given five to ten minutes to plan their work before the exercise begins. Then they are given ten minutes to complete the first picture. After they have completed the picture, the “customers” and “developers” join together to do a quick retrospective for the next round. The exercise is then repeated.

Read the rest of this entry »

Inspired by Per Mellqvist (and myself, to be fair), I wanted to explore the possibility of using a generic DAO or Repository interface for REST. Based on this simple idea, I was able to create a very cute and testable prototype of a full Web Service stack for REST based Web Services. The most interesting aspect was creating a universal test case for Repositories.

This article shows how little code is required to implement and test a REST based Web Service in Java, despite the horror of the Java HTTP client API. The source code can be downloaded from my subversion repository. I also want to illustrate how to create black box tests that can be reused efficiently with different implementations of a Repository.

Read the rest of this entry »