Since this is the Internet, the land of mistranslation, I'm going to get a few things out of the way at the beginning.
Design has many meanings and contexts. For this post, I'm going to use the following definition of design:
The purposeful or inventive arrangement of parts or details: the aerodynamic design
of an automobile; furniture of simple but elegant design.
That is, I'm going to talk about the particular design that represents a piece of application/service software.
Also, this post refers only to application/service software. Libraries have entirely different goals.
Get On With It Already
Alright, now that we're on the same page, I'm going to tell you that flexibility in application code is bad design.
The job of a programmer is to make a realization of some type of specification. There are good and bad specifications to be sure. However, the end result of all application programming should be a piece of software that does its intended job. This sounds completely logical, and many developers will pay lip service to it. But time and time again I will have a conversation with a developer who will start going on and on about flexibility for situations that might possibly happen in the future.
What these developers mean by "flexibility" is that the code allows you to do something that currently has no plan to be used. Where is the flexibility in code that has every path and possible use covered by the application? That's just code that solves the problem. For these developers, true flexibility comes from solving problems that do not need to be solved.
In my opinion, good design is whatever results in a shipping product, using the least amount of code, in the least amount of time. This definition won't allow you to say what the best design is, but it does give you a rubric to pit two actual designs against each other. Less code is always better than more code because it will always be more readable, easier to digest, and easier to maintain. Note for the dense, I'm not talking about deliberately obtuse or obfuscated code. Least amount of time is obvious. If you aren't interested in shipping, then fiddle with your code all you want, be my guest. Most of us want this software out the door yesterday.
This definition of good design also lends itself well to a grocery shopping analogy. Everyone knows you're supposed to buy based on the lowest per unit price of an item right? If you can buy 30 apples for 10 cents a piece, and 10 apples for 20 cents apiece, then the 30 apples is the way to go right? Obviously this isn't always correct. If you are only going to eat 1 apple a day, and the apples go bad after 10 days, you're now overpaid $1 if you bought the 30 pack.
The same is true of "flexibility" in code. Since this "flexibility" in code is related to the future, that means you're only going to receive value out of it if it eventually gets used. Until then, it is dead weight. It is more code that must be read, understood, and maintained. It is a minus on the overall design because it is work spent for no gain. You could mark it as a plus to possibly be received at a later date, but then you would be building the Enron of code.
The Most Flexible Code Ever
So maybe I haven't convinced you to stop trying to write flexible code that will also make toast in the morning. I have a little secret to let you in on.
The most flexible code already exists!
Seriously, go look it up. The amazing thing about it, is we all use it everyday. That's right, it's called a Turing complete programming language. If your goal is to create the ultimate in flexible code, then I think Alan Turing, and everyone who has written a programming language has got you beat.
These guys have written code that allows you to make operating systems, databases, windowing toolkits, financial software, even the software that you are working on right now. I guess it's easy to forget that programming languages are software too.
If you think you can make a better programming language, then I would love to try it out. But please, all you architecture astronauts, let's stop worrying about the undefined future and start shipping great software.