Sponsored Link •
Martin Fowler, chief scientist at Thoughtworks, Inc. and author of numerous books on software design and process, talks with Bill Venners about balancing maintainability and efficiency, creating tunable software, the role of patterns, and the Agile Software Manifesto.
Over the last decade, Martin Fowler pioneered many software development techniques in the development of business information systems. He's well known for his work on object-oriented analysis and design, software patterns, Unified Modeling Language, agile software processes (particularly extreme programming), and refactoring. He is the author of Analysis Patterns (Oct. 1996), Refactoring (June 1999; coauthored with Kent Beck, et al.), UML Distilled (Aug. 1999; with Kendall Scott), Planning Extreme Programming (Oct. 2000; with Kent Beck), and the soon to be released Patterns of Enterprise Application Architecture (Nov. 2002), all published by Addison Wesley.
In this six-part interview, which is being published in weekly installments, Fowler gives his views on many topics, including refactoring, design, testing, and extreme programming. In Part I, Fowler makes the business case for refactoring and testing, and describes the interplay between refactoring, design, and reliability. In Part II, Fowler discusses design principles of avoiding duplication, separating presentation and domain logic, being explicit, and describes how refactoring depends on code ownership. In Part III, Fowler differentiates between planned and evolutionary design, suggests that focusing on superficial problems can lead to the discovery of substantial problems, and claims that doing a good job won't slow you down. In Part IV, Fowler discusses design decay, flexibility and reusability versus complexity, four criteria for a simple system, and interface design. In Part V, Fowler describes the unhurried quality of test-first design, defines monological thinking, and distinguishes between unit and functional testing. In this final installment, Fowler describes how to balance maintainability and efficiency and create tunable software, and discusses the role of patterns and the Agile Software Manifesto.
Bill Venners: I keep bumping into famous people at the Red Carpet Club in the Denver airport. This summer I ran into Calista Flockhart. Last year I ran into you. I was too star struck and afraid of Harrison Ford to talk to Calista, but you and I sat down and had a beer. One of the things you said to me over that beer is that you think serialized objects should be in a programmer-readable character format rather than binary. When I mentioned that a character format could be slower than a binary format, you said the binary approach makes things harder to maintain in the name of efficiency. I wonder if you could talk about the specific case of serialization forms, and in general, how do you balance maintainability with efficiency?
Martin Fowler: Efficiency always wins providing that you're looking at it properly. The problem is that a lot of people do things for efficiency reasons without for instance running a profiler. If you ever do something for efficiency reasons and you aren't running the profiler, then basically you are speaking out of your rear end.
The serialization case is a bit more problematic. One of the problems with binary serialization is you can't look at the result. This is particularly a problem if you are storing that serialized object. A classic problem with Java is if you then change the class and try to reread the serialized object, you can't. Similarly, if you have a client and a server communicating through serialized objects, and you update one end of the connection but not the other, it all falls down.
Now there is a trick you can use to get around that. Rather than serializing the object, pull the data out of the object and put it into a dictionary. Then serialize the dictionary. That gives you some resilience against change.
Bill Venners: It's not explicit, though.
Martin Fowler: No a dictionary isn't as explicit, but if you add a field to the class and pump an extra value into the dictionary, it doesn't matter. It is a less brittle mechanism. XML is often less brittle because, again, you can ignore data you don't know about. Much of the problem with binary serialization is its brittleness. I talk a bit more about serialization forms in my book, Patterns of Enterprise Application Architecture. For data transfer and storage in a database, for example, you have to think about the variations between character and binary serialization.