Martin Fowler on Flexibility and Complexity

Bill Venners (JVM author & Jini guru) had some great discussions with Martin Fowler (OOD author) around designing applications for today rather than tomorrow. This is a core belief held by the XP community, but one that I have struggled to accept.

Fowler states, "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."

This is a, 'no shit' kind of comment, but one worth inspecting. The opposite of creating flexible, reusable code is to create rigid, simple, one-offs. The side effect of one-offs would be the creation of a larger code base. Thus, the maintenance effort deals with the MASS of the code rather than the COMPLEXITY of the code... an interesting trade-off. Now, Fowler would argue that the mass of the code would be decreased on a just-in-time basis through the magic of refactoring. And he would be right if we were only dealing with a single system or a small set of systems where Collective Code Ownership is possible. When we move into enterprise systems where hundreds of applications exist (with millions of lines of code), the ability to ascertain if the functionality should be coded in a flexible way is very hard. The Fowler (and XP) solution is to throw in the towel and claim that it is too hard.

So in response to Fowler's comment, "The cost of flexibility is complexity", I have identified a few additional quips:
-The cost of inflexibility is increased mass in the code base.
- An increased code base leads to additional costs in enhancements and quality.
- Refactoring is a solution to 'flexibility is complexity' but only when Collective Code Ownership is possible.
- The return on flexibility increases as the reusability of the functions increase.
- Reusability increases as the FUNCTIONALITY is neutralized.
- Functionality is neutralized by making it independent of the operating system, network, programming language, hardware and physical location.
- Service Oriented Architectures that neutralize (like Web Services, not Jini) increase reusability on a linear scale that is significantly greater than anything we have seen to date.

The statements that Fowler made were correct for an object-oriented world but do not hold true in a neutralized service oriented world.

By the way, if you haven't read Fowler's work and you're an OO person, you are really missing out - it is wonderful. His book on refactoring is the standard. Other strong works include his books on XP and analysis patterns. Bill also did a quality work on the JVM.