Bad Day at the Office

This is for all of you who have ever let a typo or a photoshop error go live or to print:

Reliability
... always upholding the highest standards for every detal.

Martin Luther King Day Rally

This product has been x-rated at point of origin.

Oddee.com

Ever Wonder About Excel Dates?

I found a blog post that might answer most of your questions.

WAY BACK in 1991

... Later that day, I had some time, so I started working on figuring out if Basic had enough date and time functions to do all the things you could do in Excel.

In most modern programming environments, dates are stored as real numbers. The integer part of the number is the number of days since some agreed-upon date in the past, called the epoch. In Excel, today's date, June 16, 2006, is stored as 38884, counting days where January 1st, 1900 is 1.

I started working through the various date and time functions in Basic and the date and time functions in Excel, trying things out, when I noticed something strange in the Visual Basic documentation: Basic uses December 31, 1899 as the epoch instead of January 1, 1900, but for some reason, today's date was the same in Excel as it was in Basic.

Huh?

I went to find an Excel developer who was old enough to remember why. Ed Fries seemed to know the answer. ... http://www.joelonsoftware.com/items/2006/06/16.html

Do The Simplest Thing

I've read the following again and again. I wish I had come across it 10 years ago. From: xProgramming.com

"The most important rule in our development is always to do the simplest thing that could possibly work. Not the most stupid thing, not something that clearly can't work. But simplicity is the most important contributor to the ability to make rapid progress."

We find that we have to remind ourselves of this rule continually. Developers like to develop, and most of us have years of experience in creating a "general solution" to whatever we're asked for. Real progress against the real problem is maximized if we just work on what the problem really is.

On the contrary, if we know we're going to need something we should build it in while we're building the object the first time. It'll save time.

• How can it possibly save time to do more rather than less? The best you can hope for is to break even. A little bad luck, and you'll come out behind.
  
• When you're thinking about "we're going to need this someday", you're not thinking about "we need this today". You just distracted yourself from your goal. Don't compound the error by chasing tomorrow.
  
• Software follows an 80/20 rule: 80 percent of the benefit comes from 20 percent of the work. Find that simplest 20 and do it.
  
• Studies show that developers are not really that good at predicting what will be needed. It's better to wait for a real need, and provide for it then.

Smalltalk code is extremely easy to modify. We do not have to design or build for the future. Progress is fastest if we just do what we need to do now: leave the future to the future.

On the contrary, when I'm immersed in a new object, I may see how to do something that will later be more difficult because I won't be up to speed.

• If the object is so complex that it will be hard to modify later, it is just too complex. Simplify it so that adding new capabilities will be easy, but don't make it even more complex by adding them now.
  
• Add commentary describing the key idea. Your mission is to make the fastest progress against what the problem really is, not against what the problem might be or might become.