

Hofstadter's law - mnnttl
http://en.wikipedia.org/wiki/Hofstadters_law

======
mkramlich
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.

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

~~~
joshes
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.

~~~
baddox
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.

~~~
JonnieCache
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!

------
klochner
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 :)

------
gregschlom
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.

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

~~~
thesz
So you get 97/3 rule!

------
pixdamix
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>

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

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

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

~~~
DTrejo
If you said planning fallacy, more people might understand.

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

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

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

------
jrockway
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...

