As regular readers of my work may know, I'm very suspicious of using metaphors of other professions to reason about software development. In particular, I believe the engineering metaphor has done our profession damage - in that it has encouraged the notion of separating design from construction.

As I was hanging around our London office, this issue came up in the context of Lean Manufacturing, a metaphor that's used quite often in agile circles - particularly by the Poppendiecks. If I don't like metaphoric reasoning from civil engineering, do I like it more from lean manufacturing?

We recently took our annual dive vacation. Whenever we do this we face a dilemma - do we go to Saba which we love so much, or do we try something new? Our answer to this was to go to Saba and somewhere new, which led to a longer vacation that made up for the long trip down from the frozen North East. Our new place was Dominica.

As someone who uses version control all the time, I think it's something that can grow into more areas of computer use. Other than software developers, few computer users use version control. Yet as software developers know, version control is a great mechanism for collaborative work, allowing multiple people to work together on a single software system. What would be the benefits of version control being more widely used?

Most version control systems rely on using and understanding the changes between versions of artifacts - often referred to as diffs from the command that can produce them in Unix. Good diff (and merge) algorithms are around for text and binary files. The trouble with these diffs is that they are rather dumb. All they do is look at the two artifact versions and generate a simple way of getting from one to another.

Sergey Dmitriev is one of the leaders of JetBrains, the people who gave us such wonderful tools as IntelliJ Idea and ReSharper. He's recently published an article on some exploratory development he's done called the Meta Programming System. He sees this system as an example of a broader movement which he calls Language Oriented Programming.

I've been attending OOPSLA for over a decade. It's become the place where I catch up with lots of friends and find out what they've been doing lately, and try to get a sense of where the OO community is going.

Clear code is good, but should you sacrifice clarity for testability?

My First Law of Distributed Object Design: Don't distribute your objects (From P of EAA).

One of the basic tenets of agile development is that requirements changes aren't just expected, they are welcomed. This poses a particular challenge when an external company, like Thoughtworks, is doing work for client. Many clients want a FixedPrice arrangement, which is really fixing scope because they see the FixedScopeMirage. But a fixed scope contract is totally at odds with agile development, so what is a company like us to do?

If you've been keeping an eye on my fellow ThoughtBloggers you'll know that it seems one of my fowlbots has blown a fuse, the Australian sun obviously frizzles these Swedish models.

Jon's annoyed with Data Transfer Objects, but it's not that DTOs are a bad thing, just like any pattern they are useful in a certain context. Patterns always have two parts: the how and the when. Not just do you need to know how to implement them, you also have to know when to use them and when to leave them alone.

As I listen to our development teams talk about their work, one common theme is their dislike of things held in statics. Typically we see common services or components held in static variables with static initializers. One of the big problems with statics (in most languages) is you can't use polymorphism to substitute one implementation with another. This bits us a lot because we are great fans of testing - and to test well it's important to be able to replace services with a Service Stub.

Installing most things on Debian is sinfully easy: apt-get install package-name. Sadly Java is an exception since it's not in the basic debian system. I recently downloaded and installed java 1.5 (or 5, or whatever they're calling it these days) on my Debian Sid desktop. In brief the procedure is.

Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don't get satisfactory software, then it won't cost them.

As there is a growing interest in dynamic languages, more people are running into a programming concept called Lambdas (also called Closures, Anonymous Functions or Blocks). People from a C/C++/Java/C# language background don't have lambdas and as a result aren't sure what they are. Here's a brief explanation, those who have done a decent amount of programming in languages that have them won't find this interesting.

Subversion is the an open-source version control system - in essence a successor to CVS. It fixes the biggest issues with CVS, introducing such things as atomic commits and support for file and directory renaming. I've been using it for a couple of years and have found it very solid.

A couple of Christmases ago Cindy gave me a Magellan Meridian Gold GPS device. Since I'm better than the average bear at navigating, I didn't see it as something I really needed but something to play around with. Since then I've found it more an interesting toy than something I really use a lot.

I've heard a couple of questions recently about coming up with a standard story point mechanism for multiple teams using extreme programming's planning approach. The hope is have several teams all using equivalent story points, so that three story points of effort on one team is the same as on another.

I think trying to come up with this at best of limited value, and at worst dangerous.

Here's an interesting conundrum posed by Przemyslaw Pokrywka. One of the refactorings in the book is Introduce Null Object - a very useful refactoring (also discussed in Josh's new book.) Przemyslaw's point is that this refactoring can alter behavior. If you have a method return a null, and you invoke a method on that null you'll get a null pointer exception. If you use a Null Object you'll get some default behavior.

If you make a change to improve the performance of a program, is this a refactoring?

In my refactoring book, I gave a couple of definitions of refactoring.

There was some recent discussion on the refactoring mailing list about what is or isn't a refactoring. As with these discussions, there's always a danger of debating how many angels fit on a pin, but thinking about the boundaries does have some useful purpose.

If software's going to go south, Jim explains in this column why it should collapse as fast as possible.

Is it a refactoring to change the order of declarations, eg methods and fields in a Java program?

I often get questions that surround one of the design choices in the JUnit testing framework - the decision to make a new object for each test method run. Enough to warrant a quick bliki entry. (However I feel almost compelled to point out that my writing about JUnit does not mean that that I don't think that other forms of testing are important. There are lots of useful testing activities, and although JUnit and its cousins are valuable for many of them it isn't the solution for everything. For more blogging on testing I suggest you look at the blogs of Brett Pettichord, Brian Marick, and James Bach. You should also not assume that my writing about xUnit testing implies suggests the unimportance of refactoring, use cases, or flossing.)

Cindy is very conscious of good workmanship in carpentry. She'll notice all sorts of fine details that I'm oblivious of. She particularly appreciates things that don't look like much, but are actually quite tricky to do right.

When you a write a class, you mostly strive to ensure that the features of that class make sense for that class. But there are occasions when it makes sense to add a feature to allow a class to conform to a richer interface that it naturally should.

I was digging through some old notes, and came across a simple but useful tip that Rich Garzaniti gave me.

There are many reasons why I'm comfortable about working at Thoughtworks, much of it is because most of the people here share a broad set of principles with me. One that's caused some debate over the years is our attitude to our own intellectual property - in essence we give it away.

This page is now deprecated as I no longer consider it a useful source of information. Please go to ActivityOriented for better coverage of this topic

This page is now deprecated as I no longer consider it a useful source of information. Please go to BusinessCapabilityCentric for better coverage of this topic

(Problems with mouse, Belkin KVM switch and Linux)

This page is now deprecated as I no longer consider it a useful source of information. Please go to OutcomeOriented for better coverage of this topic

Here's a story from a friend of a friend. I'm sure it must be true, at least somewhere.

I use the term Application Database for a database that is controlled and accessed by a single application, (in contrast to an IntegrationDatabase). Since only a single application accesses the database, the database can be defined specifically to make that one application's needs easy to satisfy. This leads to a more concrete schema that is usually easier to understand and often less complex than that for an IntegrationDatabase.

The relational data model is best known to most people through relational data bases, and through the SQL language. Colloquially, we think of the database as a set of tables, each row of which contains data. We can manipulate these tables in various ways to do queries, each query results in another table. In contrast to NetworkDataModel, there are no explicit pointers between tables, links are made by join tables on common values (although the use of surrogate keys means you have pointers in practice.)

A hierarchic data model organizes in the form of a hierarchy or tree structure. Early databases and programming data structures commonly used hierarchic models, but these fell out of favor. In the database world the RelationalDataModel became dominant, while for most in-memory programming the NetworkDataModel dominates. This was due to the fact that a hierarchy, while a simple organizational tool, breaks down as you get more complex data.

Adjective: a technique, tool, or design idea that is clearly too ludicrously simple to be any good, but when you start using it has a power that belies its simplicity.

These are now called a Squeezebox.

Knoppix is a linux distribution with quite a few interesting properties.

On-site customer is one of the practices of extreme programming, one of the twelve mentioned in the White Book. It says that a customer should sit with the developers in their open work area to be available to answer questions and interact with the development team. Indeed they are part of the development team, and recognize that the success of the team depends as much on them as it does on the developers. They don't have to give up their reqular job to do this, but they must be physically present.

C3 was the short name of the Chrysler Comprehensive Compensation project, a payroll project at Chrysler which has since become famous as the 'birth project' of Extreme Programming.

The network data model structures data as record types, with pointer links to allow to navigate between one record and another. So to query a network data model you begin at one record and move around pointer references.

A couple of years ago I changed an important aspect of my working life. Before then I tried to work on only one computer (or more strictly only one hard drive). All my working files were kept on my laptop hard drive. If I used a desktop machine I used those files through file sharing facilities.

Use cases are a technique for organizing and eliciting requirements. They were originally popularized by Ivar Jacobson in the late 80's and early 90's.

After much anticipation, the folks at JetBrains have started their Early Access Program for their C# tool. Sadly they ignored my naming advice and instead called it ReSharper. Early noise from my colleagues has been enthusiastic if still wanting more.

From time to time people ask about how you get a book into my signature series. There are lots of book series out there and each series has its own way of deciding what to accept. Here's how I decide

In my view the Gang of Four is the best book ever written on object-oriented design - possibly of any style of design. This book has been enormously influential on the software industry - just look at the Java and .NET libraries which are crawling with GOF patterns.

If you learn about object-oriented design, you quickly learn that it's important to encapsulate your data. The simplest form of encapsulation is to use accessors (getting and setting methods) or properties - if your language supports it. (Some even do this within the class - SelfEncapsulation

In recent months I've gone on a major binge of installing Debian Linux. In the last few months have seen a lot of new environments appear in my setup. I've acquired a new desktop machine which I installed Windows XP on, a Powerbook laptop with MacOS X, and a new work laptop with windows XP. All of these involve various amounts of work, even my work laptop, which came with a Thoughtworks configured Windows XP already on it, needed work to install the various applications that I use in my work.

Everyone has their own list of important design guidelines. Scott concentrates on interfaces and how to design them so they are easy to use correctly and hard to use incorrectly.

Asset capture is a strategy for developing a StranglerFigApplication. You can think of many applications as managing a key set of assets. A payroll system looks after employees, a trading system looks after trades, a leasing system looks after leases. To gradually cut over to a new system, you can begin by identifying a subset of assets that you'll start with the new system. Often the best assets to start with are either simple assets (because they are quick to get going) or those that have needs that are particularly difficult to handle with the old system.

This was the original text for Strangler Fig Application. That version supersedes this one.

If you're using XP style planning, you need to get rapid consensus estimates from developers. Throwing the estimates lets you quickly tell when developers have same similar views on an estimate (so you can note it and move on) or if there is disagreement (when you need to talk about the UserStory in more detail.

I draw a lot of UML diagrams, but I don't use CASE tools. The reason is that I'm interested in UmlAsSketch, not in all the repository stuff. So far my regular choice has been Visio. Although Visio comes with UML templates I don't use the built in ones - I prefer those of Pavel Hruby.

I find this to be a sadly common architectural style. Your company buys some very expensive piece of infrastructure software. You are then told you must use it on a project even if it's not suitable for the project and causes you extra effort. After paying all that money for it you don't want it to go to waste do you?

One of the most common questions I see about agile projects is how they deal with handover to another team. If you have a development team that leaves and hands over support to a support team, how do they cope when agile projects tend to produce much less documentation than plan-driven processes?

An integration database is a database which acts as the data store for multiple applications, and thus integrates data across these applications (in contrast to an ApplicationDatabase).

When I talk about databases and how they relate to applications, I've found it useful to distinguish between two styles of database: ApplicationDatabase and IntegrationDatabase. The difference between the two lies in whether the database is controlled and encapsulated within a single ApplicationBoundary.

This is the principle that says you'll get as much done today as you got done yesterday. In iterative projects it says that you should plan to do as much this iteration as you did last iteration. The term comes from the Extreme Programming community.

As a writer and speaker on software development, I dish out a huge amount of general advice about our profession. Whether it's as specific as saying how a DecoratedCommand works, or as philosophical as how to think about your SoftwareDevelopmentAttitude, there's no end to the noise I make. Furthermore I'm only one of a large community of general advice givers: authors, analyst companies, journalists, there's more of it than anyone can read.

I've attended lots of panels at conferences, and organized a couple myself. When I organize one, I like to use a particular format based on the British TV current affairs panel “Question Time”. I've done it a couple of times and much prefer it to the traditional panel.

Every so often I get someone who not just disagrees with something I've said, but is also alarmed that I've said it. “When a guru like you says something, lots of people will blindly do exactly what you say”.

Treating a range of values, such as Oct 22-25 as a single object.

Handling dimensioned numbers such as: 12 ft and $9.99

At OOPSLA 2003 Dave Thomas (the founder of OTI) gave a thoughtful and powerful critique of Model Driven Architecture. In this column he explains why he thinks a universal model-driven approach is likely to fail, and points out that the UML and Domain Specific Languages still have value.

For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design. Not just is much design activity ridiculed as “Big Up Front Design”, but such design techniques as the UML, flexible frameworks, and even patterns are de-emphasized or downright ignored. In fact XP involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style.

Should there be a certification program for agile methods?

I'm back from my trip now, so in return for all the tips I got over the emails, here are some of my reflections from our three week trip to Japan.

Can average developers use agile methods?

I was attending a workshop at XP/Agile Universe in 2002 when the phrase 'Specification By Example' struck me as a way to describe one of roles of testing in XP.

I write about design, and it's my view that even when you are discussing somewhat abstract design patterns it's useful to provide source code examples. Of course this can lead to people thinking that the code example is the pattern, but I think that risk is outweighed by the precision that code provides. Several times I'm not quite sure about an idea but a code example helps to clarify it for me. So in my writing on design I always try to provide code examples.

One of two SoftwareDevelopmentAttitudes. The directing attitude says that since most developers aren't that good (it's rumored that almost 50% are below average) we need to direct the way they do things. This direction is to prevent them from causing harm to the system they are working on. Typically this attitude manifests itself in designs and tools that prevent developers from doing certain things, limiting what they can do to keep them away from complex areas.

Many debates in software development are underpinned by whether the speaker has a DirectingAttitude or an EnablingAttitude. These different attitudes affect choices over languages, designs, tools, processes, and lots more.

One of two SoftwareDevelopmentAttitudes.The enabling attitude takes the view that developers are responsible professionals and so should be given the freedom to do whatever they need to do. Designs that follow this attitude should make things easy to use well but should assume that developers know what they are doing and thus not try hard to prevent something being used badly. As such these tools can be misused, but take the attitude that users should know better, and if they don't they deserve all they get.

Modular programming is not just about programming to interfaces, it's also about assembling modules together without the various modules knowing which concrete modules they are talking to.

One of my early favorite books was Tsichritzis and Lochovsky's book on Data Models. The book discussed different models for thinking about data, in particular the three models most discussed at the time: RelationalDataModel, HierarchicDataModel and NetworkDataModel.

When I first came across C# I liked the notion of properties right from the start. The getX and setX conventions of C++/Java always seems rather silly to me, it's much more natural to write obj.X = other.X. Providing a property with get and set methods turns a common convention into a naturally supported feature of the language.

Some people think that Model Driven Architecture (MDA) will be biggest shift in software development since the move from assembler to the first high level languages. Others think that it's nothing more than Night of the Living Case Tools. I'm in the latter camp but feel the need for more than a slick saying.

When people talk about Extreme Programming, they often focus on such things as its adaptive planning style, or its evolutionary approach design. One small but growing trend that particularly interests me is the small but growing number of XP projects that have very low defect rates, by which I mean less than one production bug per month.

This is a very common pattern and also very simple, it's really just the decorator pattern applied to commands. I've seen it used a lot with CommandOrientedInterfaces. You also hear this referred to as interceptors and as a form of Aspect Oriented Programming.

In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of “Inversion of Control”. In this article I dig into how this pattern works, under the more specific name of “Dependency Injection”, and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.

Bruce Eckel's recent post on ant and make triggered me to share some of my thoughts about build languages. Both ant and make specify how builds happen, they are a language for describing builds. Both are pretty widely used and have been successful. Yet both run into limitations, with larger systems it's quite common to find people generating their ant/make files from other programs.

Here's an interesting contrast I recently picked up. Two enterprise application projects of a similar size (~100 KLOC), similar environments (Java and .NET). One can do a full build and test in an hour, the other takes 2-3 minutes.

One of the most difficult things for many people to understand about agile methods is the people orientation of agile. Those who are interested in agile processes all agree that process is a second-order effect on project success. The first value of the agile manifesto is that Individuals and Interactions are more valuable than Process and Tools.

XML has been around for a while now, and it's used a lot - indeed a lot more than it should be. Like most tools XML is good for some things and not for others

Once a term known to only a few, “Refactoring” is now commonly tossed around the computer industry. I like to think that I'm partly responsible for this and hope it's improved some programmers lives and some business's bottom lines. (Important point, I'm not the father or the inventor of refactoring - just a documenter.)

From the very beginnings of object-oriented development, OO design has been linked with iterative and incremental development. But as many point out, there's no inherent link between the two. You can do OO in a waterfall, and you can do IID without objects. So why are the two so closely linked?

The rising popularity of refactoring, tools such as JUnit, and agile methodologies such as Extreme Programming (XP) has brought a new style of design into view. Continuous design is the process of using refactoring to continuously improve a program's design. In this column Jim discusses his experiences with continuous design, in particular with design issues that seem tricky such as internationalization and transactions.