If you read many standards documents, apart from the need for excessive amounts of coffee, you'll also need to be wary of the overloaded meaning of some words.

A role interface is defined by looking at a specific interaction between suppliers and consumers. A supplier component will usually implement several role interfaces, one for each of these patterns of interaction. This contrasts to a HeaderInterface, where the supplier will only have a single interface.

A header interface is an explicit interface that mimics the implicit public interface of a class. Essentially you take all the public methods of a class and declare them in an interface. You can then supply an alternative implementation for the class. This is the opposite of a RoleInterface - I discuss more details and the pros and cons there.

Now that JRuby is getting more and more mature, several people are thinking of finally doing something to improve the world of build scripts by replacing ant with rake.

How do you improve the productivity of software developers?

In the last few years there's been a lot of discussion about Web 2.0, both about the concept and it's value as a Neologism. My involvement in this is limited, I've read and heard Tim O'Reilly on the topic, and took part in a workshop he organized. There's a lot of confusion out there, however, so I guess it's time for me to make a futile attempt to reduce that confusion. (Since I'm interpreting Tim for much of this, if we disagree on anything you should believe him.)

I have the habit of creating Neologisms to describe the things I see in software development. It's a common habit amongst writers in this field, for software development still lacks much useful jargon. One of the problems with building a jargon is that terms are vulnerable to losing their meaning, in a process of semantic diffusion - to use yet another potential addition to our jargon.

Neologism:

1: a new word, usage, or expression.
2: a meaningless word coined by a psychotic.

-- Merriam-Webster

If you read much of my writing you'll quickly notice that I am a compulsive neologiser. I'm always looking to come up with new words and phrases, indeed this bliki is designed around this habit.

A common, perhaps dominant, practice of agile methods is to develop a list of features (often called stories) for the software that's being built. These features are tracked with index cards, work queues, burndown charts, backlogs, or whatever your tool of choice is.

A bunch of common misconceptions about Pair Programming.

Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software - hence the need for it to be rigorous, since software doesn't cope well with ambiguity.

One of Ruby's most popular features is its support for metaprogramming, that is features that act like they change the language itself - introducing things like new keywords.

An internal DSL (often called an Embedded DSL) is a DomainSpecificLanguage that is written inside an existing host language. It's a common way of thinking in a number of programming language communities - particularly the Lisp community. It's now gaining a lot of attention as DSLs are a common way of thinking in the rapidly growing Ruby community.

An object mother is a kind of class used in testing to help create example objects that you use for testing.

If you care about what you do, you care about getting better at it. This involves reflecting about how you do things, and trying out new techniques to see if they make you better. Even if other people recommend new techniques, the only way you know if they work for you is by trying them out yourself and seeing if they improve your performance.

One of the longest running arguments on object-oriented circles is the debate between OpenInheritance and Designed Inheritance. The principle of Designed Inheritance is probably best summed up by Josh Bloch: “Design and document for inheritance or else prohibit it”. With this approach you take care to decide which methods can be inherited and Seal the others to stop them being overridden.

According to the current board of the Agile Alliance, agile methods have “crossed the chasm” , which I think means they are becoming more widespread. While this has its advantages, it also brings problems. As a methodology or design approach becomes fashionable, then we see a lot people using it, or teaching it, who are focusing on the fashion rather than the real details. This can lead to reports of things done in agile's name which are a polar opposite to the principles of movement's founders.

I've said before (in an earlier version of this page) that I cannot understand how a voting machine without a clear, auditable paper trail could be considered acceptable for voting. Some further support for this view is a recent study at Princeton showing how easy it is to subvert common voting machines. (via Glenn Vanderburg)

Recently Apple announced the Time Machine, which is the ability to go back in time and see all the alterations to your files, including finding deleted files. For some of us intense geeks, this is not a new feature. Like others, I put my entire working directory under version control, originally CVS now Subversion, and have thus had the ability to easily look at all the changes to everything I work on. It's such a useful feature that I've wondered before about what it would be like to have MoreVersionControl, and perhaps Time Machine is a step in that direction.

This is the opposite attitude to DesignedInheritance. Advocates of open inheritance do not look to disallow inheritance by Sealing their classes or doing anything else to stop people inheriting classes.

A while ago Jon Udell characterized two modes of public speaking:

• Scripted: where you write out pretty much exactly what you are going to say and either read or memorize it.
• Slide-driven: where you produce detailed slides and use them to drive what you say.

Most of my public talks these days use a third mode - extemporary speaking. In this style I begin with little more than a rough outline of my talk, and compose everything else as I go.

When the topic of DomainSpecificLanguage comes up, one of the common puzzles is exactly what is or isn't a DSL. The trouble is that there is no precise definition for a DSL and there is a large gray area between DSLs and other things.

I've spent a lot of my writing energy writing patterns. From time to time I get asked questions about why I do that and what makes a good pattern. This is a brief article about how I look at patterns with my suggestions for people who are interested in writing patterns themselves.

When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I'll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.

A historical overview of how GUI archiectures have evolved, with a particular attention to how Model-View-Controller has been seen by different groups over the years. Ties into my presentation patterns from a historical perspective.

For the last four years Thoughtworks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we've discovered that we can make it work, although the benefits are still open to debate. (Although this article was last updated in 2006, I our visited our offshore work in 2011 and found the lessons to still be relevant and thus the article did not need a further significant revision.)

Graphical User Interfaces provide a rich interaction between the user and a software system. Such richness is complex to manage, so it's important to contain that complexity with a thoughtful architecture. The Forms and Controls pattern works well for systems with a simple flow, but as it breaks down under the weight of greater complexity, most people turn to “Model-View-Controller” (MVC). Sadly MVC is one of the most misunderstood architectural patterns around, and systems using that name display a range of important differences, sometimes described under names like Application Model, Model-View-Presenter, Presentation Model, MVVM, and the like. The best way to think of MVC is as set of principles including the separation of presentation from domain logic and synchronizing presentation state through events (the observer pattern).

Narrative overview of patterns in user interfaces. Discusses how and why to separate domain logic from the presentation and how layers of data are separated and synchronized.

In the newly formed Rails community, the word 'enterprise' is becoming a dirty word. For many people the Rails framework, with its aggressive simplicity, is the antithesis of over-complex 'enterprisey' frameworks.

In February 2001 a group of seventeen software pundits got together in Snowbird UT to discuss the growing field of what used to be called lightweight methods. We decide to use the term agile to describe this new breed of agile methods. We also wrote the Manifesto for Agile Software Development , setting out the values and principles of these agile processes. I was one of these self-elected visionaries and have since come across many questions about this group's origins and the subsequent founding of the agile alliance. This is my recollection of those events.

I've talked many times about the virtues of Continuous Integration. To get such an environment working you need a continuous integration server, and a source code control system. To make a project run smoothly you could also do with an issue tracker for bug tracking and the like, and a wiki to help capture all sorts of project knowledge.

The meeting at Snowbird Utah in 2001 that decided to use the word 'Agile' and began the 'Manifesto for Agile Software Development'.

As with most of my keynotes, this is an extemporary talk. Given the conference, this one has a theme of how rails impacts software development.

In my recent post on EvaluatingRuby I mentioned that a colleague had put together a web app with some fancy numerical graphs. Someone emailed to ask how he did that. I added my short answer, ploticus, to the original bliki entry, but that led to the question of how he interfaced ruby with ploticus?

A recent blogosphere controversy was caused by Nicholas Carr's entry claiming the “death of wikipedia“ (yes I know my response is slow, but I didn't have the time to write while on the road). His initial post struck me as rather odd, saying that wikipedia was dying because 0.01% of articles had a rather mild protection. It's like saying democracy is over when a town hires a policeman.

This article discusses some of the challenges in evolving a community of service providers and consumers. It describes some of the coupling issues that arise when service providers change parts of their contract, particularly document schemas, and identifies two well-understood strategies - adding schema extension points and performing “just enough” validation of received messages - for mitigating such issues. Both strategies help protect consumers from changes to a provider contract, but neither of them gives the provider any insight into the ways it is being used and the obligations it must maintain as it evolves. Drawing on the assertion-based language of one of these mitigation strategies - the “just enough” validation strategy - the article then describes the “Consumer-Driven Contract” pattern, which imbues providers with insight into their consumer obligations, and focuses service evolution around the delivery of the key business functionality demanded by consumers.

Early this year I did a lot of travel, so my writing ground a complete halt. I got back home a few weeks ago, hoping to get a lot of writing done. Well I've done some, but things keep coming up to keep me away: surgery to remove the pins from the accident, being Flooded. But the big productivity killer has been self inflicted - buying a new computer.

One of our favorite toys over the last couple of years has been the Squeezebox. It's a very simple device - about the size of a router, with ports for power, Ethernet, amplifier, and aerials for wireless LAN. Its job is to take mp3 files streamed from a server and play them through the amplifier.

Those of you with an eye on the news may have noticed that New England has been hit with a major spring storm with a lot of flooding. I live in Melrose, which is right in the middle of the rain, we've had nearly ten inches of rain over the weekend. People are saying there's been nothing like it since a hurricane in 1938, although it's a minor affair compared to what some other places in the world have suffered in the last few years.

In my recent CodeOwnership post, I described the way in which I think about code ownership issues. Many of my software development friends are extreme programmers, and tend to favor collective code ownership. However these kind of practices aren't absolute and should always be tempered by local considerations. One of my colleagues sent me a note with the following story which I thought was a good indication of when you have to vary your practices, even if you are a strong fan of XP. (As he's talking about his team, he prefers to be anonymous.)

There are various schemes of Code Ownership that I've come across. I put them into three broad categories:

If you're reading this I assume you're aware of the fact that there's been a huge amount of fuss about the Ruby programming language, and in particular the Rails framework for developing web applications. Some see it as the future of programming, others as a dangerous diversion.

For the last month or so I've been hanging out in our UK office, catching up with various UK ThoughtWorkers. I was intending to visit some of our client projects, but just catching up with people in and around the office has kept me pretty busy (it's also wiped out any book writing progress, but that can wait till I get back home.)

You can tell them by the twitch in the left hand side of the mouth when they see a getter method, there's swift pull on their battleaxe and a satisfied cry as another getter is hewn unmercifully from a class which immediately swoons in an ecstasy of gratefulness at the manly Getter Eradicator's feet.

A code smell is a surface indication that usually corresponds to a deeper problem in the system. The term was first coined by Kent Beck while helping me with my Refactoring book.

With setter initialization you construct an empty object and then use setter methods to setup various properties as you go. (An alterative to ConstructorInitialization.)

Constructor initialization is an approach where you pass in all the collaborators that the object needs in the creation method of the object. It is an alternative to SetterInitialization.

One of the side-effects of my success as a writer is that I've become a minor geek celebrity. It is very minor, usually only taking effect in geek conferences (although I have had people wander up to me in a restaurent a couple of times in San Francisco.) Before it happened I really didn't think much about it, other than a mild hankering after fame. Now it's happened I'm more aware of it - and all in all I hate it.

A pattern narrative that looks at how events can be used as the focus for how a system operates and collaborates with peers. Summarizes how you represent events, how to use events to integrate between systems and using event sourcing in the architecture of a system.

One of the longest running ways to think about an enterprise application is as a system that reacts to events from the outside world. This is a way of thinking that became established in the structured design community in the second half of the 80's. You hear of it now under the banner of “Event-Driven Architecture”. In the mid 2000's I started collecting some patterns for these kinds of systems, but haven't since been able to turn them into anything more substantial. Despite their rough and ready nature, I do think they provide some useful ideas around the nature of Event Collaboration, introducing the term “Event Sourcing”, using Parallel Models to represent hypothetical states of the world, and how domain logic can be organized using an Agreement Dispatcher.

Narrative of patterns useful for accounting. Contains basic representations of accounts, entries and transactions, together with an overview of patterns for making accounting adjustments.

XUnit is the family name given to bunch of testing frameworks that have become widely known amongst software developers. The name is a derivation of JUnit, the first of these to be widely known.

Gerard Meszaros is working on a book to capture patterns for using the various Xunit frameworks. One of the awkward things he's run into is the various names for stubs, mocks, fakes, dummies, and other things that people use to stub out parts of a system for testing. To deal with this he's come up with his own vocabulary which I think is worth spreading further.

There's been a long-running, if low-key, argument between the advocates of Design by Contract (DbC) and Test Driven Development (TDD). I'm not going to delve into that right now, but I will pass on an idea to merge the two that came up when I was talking with Daniel Jackson.

What do people mean when they say a method doesn't change the observable state of an object?

Whenever two or three values are gathered together - turn them into a $%#$%^ object.

-- Me (it was funnier with the voices)

This is one of my favorite CodeSmells from the refactoring book. You spot it when you constantly see the same few data items passed around together. start and end are a good example of a data clump wanting to be a range. Often data clumps are primitive values that nobody thinks to turn into an object.

Both Java and C# share the same model of pure interface types. You declare a pure interface by going interface Mailable, then you can declare you implement it with class Customer implements Mailable (in Java). A class may implement any number of pure interfaces. One of the things this model ignores is that you have implicit interfaces whenever you have a class.