Sponsored Link •
Martin Fowler, chief scientist at Thoughtworks, Inc. and author of numerous books on software design and process, talks with Bill Venners about the unhurried quality of test-first design and monological thinking, and the difference between unit and functional testing.
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 this fifth installment, Fowler describes the unhurried quality of test-first design, defines monological thinking, and distinguishes between unit and functional testing.
Bill Venners: When doing evolutionary design, are you designing interfaces in small steps, one piece of the interface at a time?
Martin Fowler: Yes. If I'm creating a
Money class, I'll
plus work first before I even think about the interface of
multiply. Just get
plus to work. Don't think about anything
else, just focus on
plus. Come up with its interface. Come up with its
implementation. Now we've done
plus. Now let's do the next bit.
Bill Venners: I'm more comfortable with, OK I've got a
Money class, what are its responsibilities? What services does it need to
provide? Define the interfaces without implementing the code, and get that nice and easy
to understand. And then you can write code, test, implement, test, implement. But I still
tend to think more of partitioning the whole system into subsystems, and sub-subsystems,
and designing interfaces in the chunks they'll be used, like classes.
Martin Fowler: 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.