And, in case anyone still hasn't read "Gödel, Escher, Bach," let this be a reminder to do so.

This was a perspective altering read for me, and I still have some 200 pages to go. It is extremely dense, in the sense that there is just so much packed into each page, chapter and dialogue that you have to pace yourself.

So many times have I noticed Hofstadter making a play on his own words to prove a point about recursion or indirection or some other fundamental concept. It's truly a wonderful piece of work.

I read it right after taking my first Discrete Math and Computation courses. My eyes were quickly opened to what computation and mathematics really are. The molecular biology stuff in the middle of the book got a bit long-toothed for my taste and I think the music part of his grand analogy was the weakest, but man was that a great book.

I too read this book shortly after doing my CompSci degree. His beautiful technique of explaining complex concepts through allegory made me finally understand a lot of stuff from my various Computation-related courses, that was opaque at the time.

If I had read that book before I took the courses, I would have understood the courses a lot better. However if I had tried to read the book before taking the courses, I may well have not understood parts of the book properly.

Deliciously, this kind of recursive, chicken-and-egg problem is an embodiment of some of the book's central concepts.

Go and buy it now!

Indeed. Hofstadter and GEB are very cool. I was geeky enough to have referenced Hofstadter's law in a margin note on my resume/CV: http://benhoyt.com/cv

I thought the standard for software engineering projects was to take the estimate, bump up a unit and multiply by 2:

  1 hour --> 2 days
  1 week --> 2 months
  . . .

so 10 years would have been 20 decades :)

I'm a huge believer in the 80/20 rule: no project takes less than 80 hours, and no matter how long you think it takes, multiply this amount by 20.

I think that 20 is a bit extreme, I always multiply by 3 and it proved to be quite accurate over the years.

So you get 97/3 rule!

Do not forget Ninety-ninety rule:

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."

I'm a huge believer of this one, I tend to be a little bit (please read: TOO MUCH) optimistic when evaluating the remaining work/time/etc.

[1] http://en.wikipedia.org/wiki/Ninety-ninety_rule

I always get big laughs when I tell people about this. It's great first week on the job joke material.

Even if you take into account that you've heard it before.

Sad thing is that I can always assume that my audience hasn't heard it before. Kids these days. They don't read anymore!

If you said planning fallacy, more people might understand.

http://en.wikipedia.org/wiki/Planning_fallacy

An infinite recursion doesn't imply an infinite amount of time - the series can have a bound, depending upon the coefficients.

That's why I always estimate times extremely aggressively. That way, when they undoubtedly multiply, they'll still get done pretty fast.

So true.

I remember telling my boss that some project would take two weeks... back in November. It's now March and I'm still not done.

It always surprises me how long things take, especially when I consider the amount of useful code I've written over the weekend or between talks at conferences...

I find this law only holds when you're doing something that is significantly new for you, and/or has many elements or individual components which can interact in complex ways and suffer from leaky abstraction effects.

But if you're doing just one thing. Or a few things. And/or it's a set of things/activities you've done almost exactly the same way previously, and knew how long that took, then no, this law does not hold, and sometimes things go faster or about what you expected.

Developing new software for clients and/or on top of new components, almost always is applicable however. Too many moving parts will bite you. Black boxes can bite you. Developing on the frontier, as opposed to walking along a well-trodden cow path, will bite you.