Saturday, June 30, 2012

Do You Know What Day It Is?

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:
  1. 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.
  2. 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.

13 comments:

JulesLt said...

A key point to remember is that it is relatively easy to change a consistently used constant to a variable - less so hard-coded values of #00DD0000.

I'd also say "Today's variable is tomorrow's function" - and of course you'll never predict the function parameters - "we want custom backgrounds on major holidays".

KenDowns said...

Jules, agreed on all points, the rule is stated in a form that was as compact and easy to remember as I could get it, but it really does apply in all kinds of cases.

Your example of the function is exactly what I was going for, and what will be expanded upon in later posts.

Once upon a time there were no clusters (n=1) now we ask "How many boxes in the cluster?" Once upon a time a box ran an OS (n=1) now we say, "how many virtuals are on that physical?"

Anyway, more posts to come.

mortoray.com said...

I think these rules should be applied generally. You never over engineer a solution -- there is no value in programming features before they are used. You should however accomodate future features, and this really just means writing clean, easy to maintain code. In the case of constants it means having the constant defined only one time.

Andy Lester said...

The most insidious YAGNI features are those we invent ourselves.

Phil Mayes said...

The rule I use is that the code should not contain any numbers other than 0 and 1.

Laptop Reviews said...

there is no value in programming features

Anonymous said...

Nice to see you posting again. I learned a lot by reading your posts, but of course do not agree with you on all points :). Just want to say thank you. Best wishes.

Cory Isaacson said...

The question to add on to this example came to mind where someone says, "Will we still want green if our business triples in size over the next six months?" Surprising how often scalability planning is overlooked.

Joki malhotra said...

According to me there have nice information

about Data service .Data service is

business increment process service. We get

and make business growth in market and also

get easy and good with best price and also

with customer requirement as. So Today I get

good Data service in UK .

Thanks & Regards
Data Supply Services UK

Genti Disha said...

The post is very interesting, I partly agree with you, please see my latest post at my blogger http://myprogrammingexamples.blogspot.com/

Earl said...

Hard coding is a almost always an error. The customer seldom knows what they want so I would suggest that variable are used to the extreme. Secondly, if you have the same situation twice (from different customers) maybe design a subroutine or function.

Anonymous said...

Agree with all the commenters. I do database work for clients in insurance and agriculture in both Regina and Saskatoon and never ever do I take what they say and set it in stone
Jvic31

Qadir Shaikh said...

hello sir,
thanks for sharing thia graet information.

Regards :
Qadir Shaikh