Computer

Decisions and why you should remember them

Jim is a developer and is working on the GUI. His GUI has several buttons. Jim decides that the buttons will have the default operating system’s look and feel, which is gray and not too appealing.

The product manager sees the GUI and tells Jim to change the button’s color. They will definitely look better with a blue hue. Jim makes the change.

After two weeks Jim notices that the user can change the application background, and the blue buttons look fugly with any background color except the default one. He shows the product manager the proof that the gray buttons were slightly less sexy but worked better with any background.
The manager is convinced and tells Jim to switch back to the original buttons.

Everyone is happy, except six months later the product manager is using the application and notices the gray buttons. They look dull.
His mind his busy and overloaded: he doesn’t remember the discussion that took place months ago. He calls Jim and tells him to make buttons blue.
Jim’s mind is slightly less busy, he remembers there was a reason why they changed back to the gray buttons. Unfortunately he doesn’t remember why.
He has no way to convince the manager that the gray buttons are better. He walks back to his place and makes the buttons blue again.

Two weeks later…

I admit this example is idiotic, and many things could be said about GUI standards, precise specifications, etc… but that’s not the point.
The point is, you often take decisions that don’t look like decisions. They are not so important to require a formal meeting and nothing formal is written about them. Those “hidden” decisions look innocent but they often make one waste a lot of time.

That’s why I now have a “Decisions” folder on my desktop with plain .txt files that hopefully won’t be needed but probably will.

(And if you are thinking that source control takes care of this, you are only partially correct according to my experience. If your software is quickly evolving, getting back and working a 6 months old piece of code usually takes a lot of time and effort.)