Have you ever sat in on a meeting like this?
Person 1: The customer wants a green background on this page.
Person 2: Do we know they're going to stick with green? Maybe we need a configuration option for background color.
Nobody wants to disagree and the manager never comes to these boring design meetings so there is quiet before somebody says...
Person 3: A configuration option just for background color is kind of weak, we'd be better off allowing choices for all colors.
Person 4: Is this an instance level configuration, or do we let the end-user pick her color?
Person 2 (the original troublemaker): well it really has to be instance level, but the end-user can override, that way we satisfy all possibilities.
From here the debate continues until they've decided to create a skinning system with lots of UI color pickers and other stuff, and they wrap up with:
Person 6: Well this sounds great, but what should we make the default background color?
...and nobody can remember that:
The customer specifically asked for green, only green, and nothing but green.
Is this an exaggeration? Perhaps, but I've sat in meetings that come close. Seems to me that I've sat in meetings that were worse, but I'd hate to slander anybody, and being as I'm not perfect myself, we'll leave that one alone for now.
So anyway, there were many things going wrong in that meeting, but we're going to stick with the simple fact that nobody there knew this one simple rule, the first rule of system design, which should be burned into your brain, which you should repeat before and during any design or architecture meeting:
Today's Constant is Tomorrow's Variable.
This is not so much a rule as an observation, but when you realize that it is true on almost any level, it can become a guiding rule, something that actually lets you make decisions with confidence, decisions that turn out to work well.
The problem is that most people in technology don't know what day it is. They make one of two mistakes, they either:
- constantly plan, estimate, design, or program for tomorrow's variable when all they need to do is handle the simpler case of today's constant.
- or they don't realize that when "the customer changed the requirements!!!" the customer is doing what everybody does, taking something simple from yesterday and making it a bit more complex today.
So you can turn this around and say, "Everything I do today will get changed tomorrow. It will become more complicated. Everything I think is fixed or constant will float or become a variable."
What It Means
We've all learned (hopefully) that you don't embed constants in code because it makes the code difficult to change. We define the constants in headers, or we accept all values from outside sources as parameters. This makes the code more flexible, and it is a good thing. The code is more robust, it can handle more cases without breaking or needing alteration.
The trick to using Ken's first and only rule of system design, "Today's Constant is Tomorrow's Variable" is to recognize the many forms of "constants" that we build into our systems in hard-to-reach places, making it hard to change them when tomorrow comes and they are no longer fixed and constant.
Another trick to using the rule is to always know what day it is. Most of what I do today will involve features that may never change. It is extremely easy to see how they might change, but impossible to know for sure. So we leave them constant for today.
Back To That Meeting
Let's go back to that meeting we started with. Here is how it goes when somebody knows that "Today's Constant is Tomorrow's Variable."
Person 1: The customer wants a green background on this page.
Person 2: Do we know they're going to stick with green? Maybe we need a configuration option for background color.
Our Hero: We don't know they are going to stick with green because we never know if any customer is ever going to stick with anything, and we all know that today's constant is tomorrow's variable. However, I hope we've put the styles into a style sheet and not embedded them directly into the HTML so we can change it later if we have to, right?
Somebody mumbles that yes in fact we do use style sheets, and the meeting moves on.
Is That Lame Example?
That's a pretty lame example really, who doesn't use style sheets? And who embeds constants in their code?
Well kiddies it turns out that we didn't always use style sheets. When I got interested in web pages CSS was still optional (Yes! Believe it!) and you put your style information directly into tags, which was basically embedding constants into code, and it didn't take long before you intuitively realized this was not right, and you discovered CSS.
It is amazing how often that basic pattern repeats itself, trying to identify what you thought was a constant, realizing it is "buried in code", and turning it into a variable.
Today's Post Is Tomorrow's Promise
I'll be posting a lot more on this subject, using a very reliable and strict schedule based on a host of variables that mostly comes down to whenever-the-hell-I-feel-like-it(TM).
Cheers.
