Artima.com has published Part VI of an interview with Martin Fowler in which he discusses balancing maintainability and efficiency, creating tunable software, the role of patterns, and the Agile Software Manifesto.

Here's an excerpt:

So you could make a performance optimization in one VM, and then bring in Hotspot, and it will actually slow Hotspot down. You've got to be very wary of that. Object pooling is a good example. A lot of people are very enamored with object pooling, yet half the time people are not measuring to that to find out whether object pooling is any good. Object pooling was very important in the early days of Java, because garbage collection wasn't terribly good. When you've got generational garbage collection, object pooling becomes a lot less effective, because short-lived objects can be collected very cheaply. It's the long-lived objects, such as ones you might pool, that are expensive to garbage collect.

So the rules keep changing. That's why you've got to be very careful to profile. If you think you can predict from the source code what the machine is doing, you've got no chance. When you're in a world of optimizing compilers and VMs, you have to profile, because the compilers and VMs are doing things that you can't even imagine. So don't predict, just measure.

Artima.com has published Part V of an interview in which Martin Fowler discusses the unhurried quality of test-first design, defines monological thinking, and distinguishes between unit and functional testing.

Here's an excerpt:

The thing I like about taking small steps and writing tests first is that it gives me a simple to do list of the things I've got to do. At each end point I have a certain amount of closure. I say, OK, this stuff works. Check it in. It's all there. It does what it does and it does it correctly.

There's an impossible-to-express quality about test- first design that gives you a sense of unhurriedness. You are actually moving very quickly, but there's an unhurriedness because you are creating little micro-goals for yourself and satisfying them. At each point you know you are doing one micro-goal piece of work, and it's done when the test passes. That is a very calming thing. It reduces the scope of what you have to think about. You don't have to think about everything you have to do in the class. You just have to think about one little piece of responsibility. You make that work and then you refactor it so everything is very nicely designed. Then you add in the next piece of responsibility. I previously used the kind of approach you describe. I'd ask, "What's the interface of this?" I've now switched and I much more prefer incremental design.

Artima.com has published Part IV of an interview in which Martin Fowler discusses design decay, the cost of flexibility and reusability, four criteria for a simple system, and test-first design of interfaces.

Here's an excerpt:

The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity. If your guess about the flexibility needs of your software is correct, then you are ahead of the game. You've gained. But if you get it wrong, you've only added complexity that makes it more difficult to change your software. You're obviously not getting the payback.

It's not hard to guess wrong about flexibility needs. You can guess wrong if requirements change. What you think is a requirement for flexibility now may go away or change in the future. You can also guess wrong if you put extra code into the program to improve flexibility but you don't get it quite right. You get more complexity without getting the flexibility you were after.

The alternative is to use the XP approach and not put the flexibility in at all. XP says, since most of the time we get it wrong, just don't put the flexibility in there. Now if you can't evolve your design safely, then that is a foolish route to take. But if you can evolve your design safely, it becomes quite a nice approach. In fact it becomes a self-reinforcing approach. If you strive to keep your design as simple as possible by avoiding speculative flexibility, then it's easier to change the code because you have less complication to deal with. The code is easier to understand and easier to change. As a result, you can make changes much more quickly.

"People also underestimate the time they spend debugging. They underestimate how much time they can spend chasing a long bug. With testing, I know straight away when I added a bug. That lets me fix the bug immediately, before it can crawl off and hide. There are few things more frustrating or time wasting than debugging. Wouldn't it be a hell of a lot quicker if we just didn't create the bugs in the first place?", says Martin Fowler in this Artima.com interview.

"You can almost do this as an exercise. Look at some program and see if there's some duplication. Then, without really thinking about what it is you're trying to achieve, just pigheadedly try to remove that duplication. Time and time again, I've found that by simply removing duplication I accidentally stumble onto a really nice elegant pattern. It's quite remarkable how often that is the case. I often find that a nice design can come from just being really anal about getting rid of duplicated code," says Martin Fowler in this Artima.com interview.

"Reliability is one story that hasn't been told about extreme programming (XP), which focuses heavily on testing. People talk a lot about its responsiveness and its light weight, but I hear more stories about XP's staggeringly high reliability. A couple weeks ago I chatted with Rich Garzaniti, an old colleague from the C3 project. The C3 project is often referred to as the birth project of XP at Chrysler where Kent first really put the various practices together coherently. Rich talked about this system he was developing using XP with testing and refactoring -- drinking the whole XP Kool-Aid completely through the system. He's had one bug so far this year," says Martin Fowler in this Artima.com interview:

"Underneath the covers, JRun's RPC method invocations are fundamentally a messaging subsystem. When you perform an invocation, in JRun we actually wrap the invocation in a message object....The pattern has been implemented in many ORBs and servers, and in DCOM, and now .NET Remoting. It's probably best described in Pattern-Oriented Software Architecture, Volume 2. When the EJB container gets the invocation message, it passes it through all the filters, before it gets to the instance. So if you have a transaction interceptor, it gets the invocation first. It pulls off the transaction ID, and discovers the transaction attributes of this particular instance. It does whatever it needs to do for the transaction. It then passes it onto the next interceptor, which may put something on or take something off the invocation message. Some folks consider this a Pipes-and-Filters pattern, and in the default cases where the interceptors are hardwired that's a good match. The concept isn't too different from designs that application developers create with servlet filters or message sinks, though in this implementation the container filters are a bit more dynamic and can account for more dependencies than a servlet filter could," says Sean Neville in this Artima.com interview.

"When you deploy a remote object, it needs a way to locate all similar remote objects on the cluster. The cluster would include whatever hosts the admin decided to link together. By default, if the admin did nothing, we wanted the cluster to include all the nearby hosts reachable via multicast. So whatever that network neighborhood cluster was, we needed a particular remote object to find its buddy on another system within the cluster based on class lookup. The lookup could possibly be based on some other information in the template, but it would mainly be based on the class. We wanted those objects to automatically find each other and exchange stubs," says Sean Neville in this Artima.com interview.

"I am not fond of copy constructors. In fact, I'm not very fond of constructors at all. The problem is that the code that creates the object with a constructor is defining the object's type. In all other operations, the code that uses an object effectively only defines that the object is at least a certain type. Constructors are an exception to that rule. I don't think that exception should exist," says Ken Arnold in this Artima.com interview.

"JavaSpaces tries to accomplish something rather different. Yes, JavaSpaces is data-driven. It is object-oriented in the sense that the entries have type and you can match subtypes, and that entry fields can be object types. But at some point, you get past objects in any system. At some point, you call a method with an integer value. In some languages that integer is still logically an object, but it doesn't contain other objects. At some point, you hit the bottom. JavaSpaces is a bottom point in the sense that it is a way to make an asynchronous method call. You can consider that the entry fields are like the parameters to the method call. The fact that those are data shouldn't bother you, because that is when you hit bottom," says Ken Arnold in this Artima.com interview.