This a style of application I've come across a couple of times. The application is primarily a reporting application that gives users real time information about the state of something. It is an active application, in that the users have a lot of control about what kinds of things they are looking at they're able to drill down in particular areas and generally manipulate their display; however it is still, at least primarily a read-only application.

The RIAA may say the world is ending, but despite my embrace of digital music with my Slimp3 I don't see my music budget getting any smaller. Indeed I think I need more of the stuff to keep my ipod's hunger satisfied.

Perhaps I was being naive but I never expected quite the chatter that my post on HumaneInterface opened up. Sadly most of it ended up being arguments about the relative merits of Ruby's Array and Java's List rather than the underlying points I was trying to make, but despite that I think some nice conversational tributaries appeared.

One of these conversational threads brought out that there are other reasons for the differences between Array and List than the humane/minimal philosophies. One of these reasons has to do with the way similar functionality plays different roles in the two languages.

Like most geeks I'm not much interested in fashion or having this season's styles. My philosophy is there isn't much point worrying about the packaging when there's nothing attractive about the contents. But I've had a few conversations with my geek friends about clothes, enough to inspire this entry.

A few months ago I attended a workshop with Eric Evans, and he talked about a certain style of interface which we decided to name a fluent interface. It's not a common style, but one we think should be better known. Probably the best way to describe it is by example.

In his excellent book Domain Driven Design, Eric Evans creates a classification of the different kinds of domain objects that you're likely to run into.

After my positive experiences with Extreme Programming in the 90s, I became curious about similar sounding approaches such as Scrum, Crystal, and DSDM. Digging into them, I distilled the common characteristics of these new methodologies: preferring adaptive planning to predictive planning, and treating people as more important to success than what process was used. In time these approaches gathered under the banner of agile software development, (and I revised the article) but I still find the perspective in this article a good way to understand the essence of agility.

The practice of taking every class and pairing it with an interface. So as a result you see pairs of things - maybe ICustomer and Customer or Customer and CustomerImpl. In many ways it echoes the C/C++ habit of header files for each class, although in this case the interfaces and implementations are actually separate types.

In my writing endeavors, I've long intended to write a chunk of material on validation. It's an area that leads to a lot of confusion and it would be good to get some solid description of some of the techniques that work well. However life is full of things to write about, rather more than time allows.

Hanging around the ruby crowd for a while, I've come across the term 'Humane Interface' quite a bit. It describes part of the rubyist attitude to writing class interfaces, I think it also sets up an interesting contrast between two schools of thought in designing APIs (the other is the MinimalInterface).

The term 'command query separation' was coined by Bertrand Meyer in his book “Object Oriented Software Construction“ - a book that is one of the most influential OO books during the early days of OO. (The first edition is the one that had the influence, the second edition is good but you'll need several months in a gym before you can lift it.)

A minimal interface is a style of API design which I contrast here to a HumaneInterface. The idea behind the minimal interface is to design an API that allows the client to do everything they need to do, but boils down the capabilities to the smallest reasonable set of methods that will do the job. (See HumaneInterface for a good example of the difference.)

Lazy Initialization is a technique that initializes a variable (in OO contexts usually a field of a class) on it's first access. It canonical form is something like this:

Over the weekend I heard the sad news that John Vlissides died after a long battle with cancer. John is best known as one of the “Gang of Four” who produced probably the best book written on software design.

An in-memory database is a database that runs entirely in main memory, without touching a disk. Often they run as an embedded database: created when a process starts, running embedded within that process, and is destroyed when the process finishes.

From time to time I run into people who want to get a smalltalk and give it a spin to see what the fuss is about. My old favorite introductory smalltalk book went out of print, but I just discovered you can now download it from here together with lots of other smalltalk related material. The material is hosted by Stéphane Ducasse, who was a co-author on an excellent book on reengineering patterns.

This is an embarrassingly brief report of what has turned into my favorite conference. Sadly a clash with other business meant that I could only spend a day in Aarhus. JAOO continues to be a great conference, although I'm hard put to say why. Somehow it manages to retain the feel of a small conference while staying fresh and broad.

OOPSLA again, lots of conference and all sorts of ideas. It's impossible to do a proper write-up of this conference - there's too much for any one human to attend, let alone take in. So these are scattered thoughts.

A way of thinking about programming introduced by James Noble and Robert Biddle. The essence of it (at least for me) is that software development has long had a modernist viewpoint that admirable software systems are composed of uniform components, composed in a uniform and simple way. (Smalltalk and Lisp are good examples of this kind of thinking.) A post-modern view is that software is all sorts of different very different stuff glued together in all sorts of different ways (think Perl and Unix), and this style of software (big bucket of glue) isn't a bad thing.

You can't put ten pounds of shit into a five pound bag

-- Anyone who has tried

When Kent and I wrote Planning Extreme Programming, we included this whimsical quote to help get the essence of what planning is about.

One of the frustrations of the software development field it's hard to choose between different techniques and tools. Often when someone talks about this they are asked for 'hard data' that the technique or tool is better than alternatives. It's an understandable request, but in the end it's a doomed one. For a start we CannotMeasureProductivity.

Thoughtworks has come to China. It's been a long-held ambition for several people to open a China office. Roy has always held it as part of RoysSocialExperiment. In addition Xiao Guo, who's given me so many good experiences and ideas in software development, has long wanted to start Thoughtworks in China.

At JAOO 2005, I chaired a track on Domain Specific Languages. I opened the track with a half-hour introduction which was recorded by InfoQ and made available on their website. The talk mirrors the first part of my paper on Language Workbenches.

As any regular reader of mine should know, I've been a keen rubyist for several years. I like the ruby language for its rich yet uncluttered syntax and the well designed frameworks that come with it. It's become my regular workhorse language for personal projects, including most of this web site.

Enterprise Architecture groups often get separated from day to day development. This can lead to their knowledge of development work getting out of date and development teams not taking a broad company-wide perspective. Having seen this happen frequently my colleague (Thoughtworks CTO) Rebecca argues that enterprise architects can be much more effective by joining development teams.

One of the big themes in Thoughtworks is to encourage a diverse range of people in all parts of the company. (In this context we mean diversity in terms of such things as gender, race, sexual orientation, and the like.) We want to be a company where historically disadvantaged groups such as women and non-whites can feel comfortable and get just as many opportunities as the traditional WASPish leaders. Roy, being a notable mongrel, obviously cares about this diversity.

Open Space is an approach to help you put together self-organizing conferences. I was first introduced to it by Norm Kerth in 1997 and have since seen it used, and used it myself, many times. It seems to work well in small scales, groups of a dozen or two people, and at larger scales of one or two hundred. I've seen it for periods of one to three days. I'll describe it with variations I have seen: Crested Butte is a small annual workshop of around 20 people, Agile Universe 2002 had about 100 or so at the conference with Open Space in one track (they've continued to do this since, but I've not been able to get there), foocamp did this with a couple of hundred people. The technique was developed by Harrison Owen and is well described in his book.

It looks like those devious people at UIUC getting ready to refactor Fortran. Brian Foote writes about the project in his unparallelled style. (He's one of the most amusing writers in software - but getting him to write anything is usually like trying to pull teeth from a live sabre-tooth tiger while wearing a necklace of freshly killed lamb chops.) (Yes I know it's old news, but I saw something else on his blog and then found this.)

Sealing a method or a class prevents subclasses from overriding it.

An annotation on a program element (commonly a class, method, or field) is a piece of meta-data added to that program element which can be used to embellish that element with extra code.

Call Super is a minor smell (or anti-pattern if you like) that crops up from time to time in OO frameworks. Its symptoms are pretty easy to spot. You are inheriting from a super-class in order to plug into some framework. The documentation says something like “to do your own thing, just subclass the process method. However it's important to remember to start your method with a call to the super-class”. An example might be something like this.

As a company grows, you have to worry more about how it's led and who's responsible for choosing the leaders. Most companies have owners (shareholders) and they ultimately select the executive management. Executives then make most decisions for the company (or at least they like to think they do).

Whenever Thoughtworks rashly lets me out in front of a client, one question I'm bound to be asked is “what do you think of SOA (Service Oriented Architecture)?” It's a question that's pretty much impossible to answer because SOA means so many different things to different people.

Testability is such an important virtue that you should make architectural decisions to improve the testability of a system.

Inversion of Control is a common phenomenon that you come across when extending frameworks. Indeed it's often seen as a defining characteristic of a framework.

A synonym for InversionOfControl.

When I wrote my recent article on Language Workbenches, I decided to separate the section on further reading into my bliki, to make it easier to report updates when new stuff appears.

Using a language workbench is very different to working with traditional Domain Specific Languages. This is an example of building a small but interesting DSL using the JetBrains Meta Programming System (MPS). You can use this to get a feel of what working with language workbenches would be like.

There's been a recent surge in development of tools that allow you integrate between multiple Domain Specific Languages (DSL) - tools that I refer to as language workbenches. Much of the discussion around language workbenches is very similar to the discussion around the Object Management Group's Model Driven Architecture (MDA). In my view the MDA means different things to different people - and this effects how we view the relationship between MDA and language workbenches. Certainly there groups of MDA practitioners who are using MDA ideas to build a language workbench. However my feeling is that the help MDA provides is partial, at best. A broader school of Model Driven Development (MDD) echoes many of these ideas without the links to the MDA standards - this is something that is very much in line with the ideas of a language workbench.

Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness.

When you build a Domain Specific Language (DSL), how do you go about making it executable. This is an easy question to answer for an internal DSL, since they are embedded into real languages. An external DSL needs more work. Here I take a simple DSL example and show a few simple ways to generate code from it.

I often run into a complaint that agile methods don't have a rigorous definition. The complainer may talk about how this means that you can't tell if a particular team is using an agile method or not. They may also say that this makes it hard to teach people how to do agile methods - what's the curriculum?

To some degree I do feel the pain of this complaint - but I accept there is no cure. This lack of rigorousness is part of the defining nature of agile methods, part of its core philosophy.

I get a lot people offering me free copies of their new software development tool. Sadly I don't have time to look at them - and frankly I'm usually underwhelmed. Very rarely do I get enthusiastic about a tool.

Table driven techniques to allow systems to change without major code changes.

When we talk about Thoughtworks, we mostly talk about us as a software application development company. We also talk a bit about our values and how we are trying to be a different kind of company to most corporations. But all this is dancing around the point - fundamentally Thoughtworks isn't about being a company.

I was working on some of my book example code the other day. I made some changes, got everything working, ran tests, and committed it to my personal repository. I then moved over to a different area and made a couple of changes - and some unexpected tests broke in the previous area. Now part of the point of running automated tests is to find unexpected breaks, but this book code has completely independent areas. This was odd.

If you need to get the current date or time in your code, don't access the system routines for that data directly. Put some form of wrapper around it that allows you to override it by setting the “current date/time” to a particular value. This is important to simplify testing.

One of the common elements of agile methods is that they raise programming to a central role in software development - one much greater than the software engineering community usually does. Part of this is classifying the code as a major, if not the primary documentation of a software system.

There are a few things that I've come to think are fundamental to how I see software development. If I had to pick one as my key to software development it's that the critical element in a software development effort are the people you have doing the work. The productivity of the best developers is far more than the average, much more than the difference in salaries. Therefore the most important part of getting cost effective software development is to hire the best team you can, even if the individual cost of the developers is much higher than the average. A few high ability (and expensive) people will be much more productive than many low ability (cheap) developers. That productivity difference means that a few high ability people will produce software more cheaply even if they cost more on a daily rate.

One the interesting aspects of the open source world, particularly for us, is how it's proving to be a fascinating research community. Open source projects come in many guises, but a fair number of them are taking an idea and programming around it to see where it goes and whether it has value. That's a notion that sounds strange if you believe that design and programming are separated, but makes a lot of sense if you accept that they are tied together.

(Here's an addition to your dictionary.)

Detestable (adjective): software that isn't testable.

I've long been loath to write any contributions on the debate between static and dynamic typing in programming languages. This is one of those emotive topics where people seem driven to debate rather than listen. But since I've been asked a few times about it, I will contribute my personal experiences. I'm not trying to convince anyone of anything, but I hope someone finds some food for thought in them.

I have a couple of feeds for those who like to use them. Although I've used the term RSS Feed here, they are actually Atom feeds.

A personal survey of various efforts to catalog patterns for enterprise software development.

In UML Distilled, I bemoaned the fact that there isn't a good book on teaching UML's activity diagrams. There still isn't, but I recently came across Conrad Bock's articles on UML 2.0 . Amongst these there is a series of articles on activity diagrams that go into more depth than I was able to cover in Distilled. (For those who don't know, Conrad Bock is one of the leaders of the activity diagram work in UML 2.)

One of the oft advertised features of modern application servers is that they provide failover in a cluster. Clustering improves the reliability of your application, if one of your servers goes down, you have some more up to server your customers. Failover can add even more reliability, if a server goes down in the middle of a interaction the cluster can move that interaction to another server.

However this can be a problem.

Baristas don't do synchronous processing - their reasons may be reasons for you to go asynchronous too.

Summarizes various patterns that you can use to answer questions about the state of an information in the past. These include questions of the form "what was Martin's address on 1 Jul 1999" and "what did we think Martin's address was on 1 Jul 1999 when we sent him a bill on 12 Aug 1999".

Any reader of my writings will know that I'm a big proponent of evolutionary design. Despite my enthusiasm for this approach, no technique is perfect and I'm just as happy to report its problems as I am its successes.

Microsoft have released a new community resource called PatternShare. The idea is to bring together pattern summaries from many pattern authors and provide a platform for discussion and further exploration of the interconnections between them. Much of the work was led by Ward Cunningham, whose pattern lineage is second to none. You'll find patterns there from myself, GOF, POSA, Hohpe/Woolf, Evans, and Microsoft.

One of the new notations that appeared in UML 2 was the socket notation to show interfaces required by a class. The origins of this was the 'lollipop' notation that was popularized by Microsoft to show a class implementing multiple interfaces. So I can show that the Array class implements multiple interfaces like this.

I've spent a lot of time of the last year wandering around Thoughtworks, talking to lots of people on lots of projects. One message that's come home really firmly to me is the value of rotation.

From time to time during a meeting or workshop, it's good to get votes on a number things in order to rank or choose a subset. A quick and nice way to do this is dot voting.

I've tended to avoid writing about Thoughtworks in my blog. To a large extent this is because I don't like anything that looks like advertising for my employer - the logo on every page is quite enough of that. But more and more my mind gets full of the kinds of things we are doing not just in our delivery work (which is the source for much of the ideas in my writing) but also in the way we structure ourselves. The reason I gave up my successful life as an independent consultant was because I felt Thoughtworks was a special and unusual company. In the last year I've been more and more interested in the social aspects of my employer, and so I've decided to start blogging about some of those.

For the last few days I've been attending a workshop on enterprise software in Norway, hosted by Jimmy Nilsson. During the workshop we had a session where we came up and voted on a bunch of design principles.

From time to time people question whether a particular specialty can be used incremental way: “You can't do (security | user interface design | databases | internationalization | * ) with an agile project because this aspect has to be done up front.”