Sponsored Link •
Bill Venners: In Refactoring you write, "Before I used refactoring I always looked for flexible solutions. Because design changes were expensive, I would look to build a design that would stand up to changes I could forsee. The problem with building a flexible design is that flexibility costs." What is the cost and what is the alternative?
Martin Fowler: 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.
Bill Venners: What about reuse? Is flexible just another word for reusable?
Martin Fowler: No, but the problem is that in order to get code that's reusable you need to make it very flexible. And a lot of the time your reuse benefit doesn't pay off, either because you end up never needing to reuse it, or because the anticipated modes of reuse weren't what you thought they were. Often the flexibility you put in isn't the flexibility you ultimately need.
Bill Venners: Are there times when it makes sense to make something more reusable? How would I decide?
Martin Fowler: My attitude with reuse is that reuse is something you evolve. You build an application to solve the problems of the application. If you build another similar application, then you begin to factor out some common pieces. If you build a third similar application, you factor out more common pieces. Then you'll begin to have something like a reusable framework. My definite recommendation is don't attempt to define a reusable framework first and then build applications on top of it. Rather, evolve the framework while building the applications.
Bill Venners: How would you describe the balance between up front design and refactoring?
Martin Fowler: Before I really came across refactoring, particularly in conjunction with automated testing, I tended to look at design as something I have to get right at the beginning. Now, I look at design as something I can often do a fairly small amount of up front. I let most of the design flow from the evolutionary process. So I feel that there's been a shift in balance. Before, I might have preferred—and these percentages are purely illustrative—80% of my design in planned mode and 20% of it as the project went on. Now I'd perhaps reverse those percentages.
Bill Venners: Much more evolutionary than up-front now.
Martin Fowler: Much more evolutionary design. Much less up-front.