Can you share your favorite quote or rule related to IT?

I like quotes and funny rules. A good quote makes our presentation more interesting, draws attention to the presenter and makes the presentation unforgettable. Ridiculous or easy-to-remember rules help us keep in mind essential things.

Below one of my favorites:

• Quote

  "A language that doesn't affect the way you think about programming is not worth knowing."
  Alan Perlis

• Rule

  "A team shouldn't be larger than what two pizzas can feed."
  Jeff Bezos

Now it's your turn to share your quotes and rules related to IT ;)

Comments

[Chris James]

Individuals and interactions over processes and tools

The first line of the Agile Manifesto is the one that gets ignored the most.

[Thomas H Jones II]

There's the "law of conservation of complexity". Which is to say, just because a technology-user no longer sees the complexity, doesn't mean it isn't still there. First really encountered it when trying to Network Apple systems in the first half of the 90s. While setting up ad hoc networks of all-Apple systems was fairly trivial, integrating them with non-apple products was paaaaaaaaaaaaaainful for administrators. Users never really saw the "behind the scenes" pain, though. They just knew that, one week, suddenly they were able to see the rest of the corporation's IT assets. But, damn, the sustainment of the setup was fragile.

[Jakob Christensen]

A bug is like an iceberg - it always goes ten times deeper than you can see.

Me :-)

[Rafal Pienkowski]

Nice :)

[Devin Handspiker-Wade]

Users lie. They may not be lying about an issue, how they ran into the issue, or how the bug is affecting them but assume there's at least one lie in every bug report. It may be something completely unimportant. They have no reason to lie, but they will.

• A past manager of mine.

[Rafal Pienkowski]

This sentence reminds me Dr House's favorite saying:

[Quentin Sonrel]

The first thing that came to my mind !

[Evaldas Buinauskas]

Status: critical.

[Devin Handspiker-Wade]

"Top Priority" and hasn't responded to the ticket in a year and a half.

[Tony Hicks]

"There's never enough time to do things properly but always time to come back and fix it later" - No idea who said that but it's been the common theme with most businesses I've seen

[Evan Oman]

Not restricted to IT, but anyone who has tried estimating work can relate to this:

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law

Hofstadter's Law

[Ben Halpern]

Ha! That's great.

[Christopher Toman]

Sadly true, I always multiply by 4, but I think I got to do power of 4

[Guillaume Martigny]

Not specific to dev, but highly relevant :

"Fail faster !"
Extra Credits

store.dftba.com/products/fail-fast...

[Sethu Senthil]

If you don't succeed in your first attempt, call it version 1.0

[Moner]

I like this one!

[Casey Brooks]

Similar to a line I've found myself saying a lot lately:

What's the best way to get something production-ready? Use it in production.

[Ben Halpern]

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.

-Tom Cargill

There’s even a Wikipedia page about the 90-90 rule.

[TMcSquared]

I heard somewhere that multiplying a developers time estimate by PI is very accurate most of the time.

[Chris Bertrand]

What's PI?

[TMcSquared]

3.141519265358979323.....

[Cadell]

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, be definition, not smart enough to debug it." - Brian Kernighan

[Rafal Pienkowski]

It's so real.

[Leah Einhorn]

Just read a similar one!

Debugging code is twice as hard as writing it, so always write code as if you're a halfwit.