Red Echo

June 30, 2008

Flexibility is bad design. Indeed. Make it work and ship it. Your users will tell you what you need to improve.

1 Comment

  1. A couple small comments.

    One is that I dislike the title, while I largely agree with the content. “Flexibility” is ambiguous; I usually think of it as a good thing, but I am thinking of the flexibility of the code itself—that is, the ease with which it can be adapted and modified to another purpose, not the degree to which it is already general-purpose enough to be applied to other purposes with little-to-no modification. Encapsulation and legibility are the primary means to achieving that sort of flexibility, and are precisely the techniques to ensure that you don’t need to achieve the “flexibility” the article is discussing. Having a comprehensive set of unit tests is also often extremely helpful to that end.

    Another is that this isn’t universal. The author explicitly states that this principle shouldn’t be applied to libraries, but why do libraries get a pass? Because APIs (and ABIs) are an expensive thing to change, so choosing a solid, general API in the first place is less expensive than iterative design. But this principle doesn’t just apply to library APIs; it applies to any programmer- or user-interface that will be more expensive to change down the road than it will be to “get right” in the first place. File formats, network protocols, and command-line invocation interfaces are among the things that invite careful design, to ensure extensibility while maintaining backward compatibility.

    Comment by Micah Cowan — July 22, 2008 @ 2:07 pm