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?

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?

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.

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.

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.

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?

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

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

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.

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

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.

(Problems with mouse, Belkin KVM switch and Linux)

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.

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

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.

When Cindy and I went to Australia, we spent some time in the rain forests on the Queensland coast. One of the natural wonders of this area are the huge strangler figs. They seed in the upper branches of a tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.

You can think of many back-end applications as primarily operating by being told about important events in outside world. Indeed the idea of an event driven enterprise application is an old way of looking at things - I first came across this in McMenamin and Palmer in the mid 80's.

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.

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?

I was working on some example code for one of my writing projects recently when I ran into a failing test. "Ouch", I thought, "those tests were passing last week - what happened?" Rather than trying to find the bug in the code in front of me, I used what I think I'd like to call diff debugging.

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.

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.

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.

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".

Handling dimensioned numbers such as: 12 ft and $9.99

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

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 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.

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 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.

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.

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.

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.

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.

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.)

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

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.