What's your favorite software idiom/aphorism?

I'm quite fond of the "ninety-ninety rule", it's so true and so heartbreaking.

Ninety-ninety rule

In computer programming and software engineering, the ninety-ninety rule is a humorous aphorism that states:

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.

View on Wikipedia

Recently I discovered that if you run "import this" on a python shell you get this beauty:

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

A function (or method) should do one thing, and do it well.

Oh, there are so many. One of my favorites, though, comes from Fred Brooks:

The bearing of a child takes nine months, no matter how many women are assigned.

You know Brooks from Brooks's Law:

Adding manpower to a late software project makes it later

YAGNI: you aren't gonna need it

There are only two hard things in computer science: cache invalidation and naming things. - Phil Karlton

I only actually heard this aphorism a few years ago (although the original quote is from far earlier). But it's amazing how often I think of it now. Obtuse, hard-to-follow code can often be "magically" transformed by applying the proper descriptive names to the variables / methods / functions / classes / etc. And yet, it can often be soooooo difficult, when you're writing the code for the first time, to settle on just the "perfect" names that will render the code clear and self-explanatory.

Small code duplication is better than a bad abstraction

"Perfectionism can motivate you to become good. But it will destroy your ability to become great" - Joel Klettke.

There's no single favorite. But a few:

• Deleted code is debugged code - Jeff Sickel
  • And also "The most secure code in the world is code which is never written." - Colin Percival
• If it doesn’t work, it doesn’t matter how fast it doesn’t work. - Mich Ravera
  • Also: nothing takes as long as developing the wrong thing
• A good programmer is someone who always looks both ways before crossing a one-way street. - Doug Linder
  • e.g. this input parameter is never X, then it doesn't hurt to validate it before using it.
• Testing can show the presence of errors, but not their absence. - Edsger W. Dijkstra
  • I have no idea how often I had to tell people this when they complain about found issues and say "hasn't this been tested?".

• If it ain't broke, don't fix it.
• Don't reinvent the wheel.

They are generic and didn't originate with software, but I think they are very applicable.

Everything comes down to one word:

Bikeshedding

😂😂😂

One of the idioms I like is: "Code never lies, comments sometimes do". Unless the comment is meaning to convey something the code cannot, you're better off not writing one. I can be quite misleading to read an incorrect or outdated comment.

YAGNI. Although I feel like I should have it tattooed on my forehead. Gold plating temptation is real!

Gall's Law:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

We have iterators now, so it was trimmed

"Make it work. Make it beautiful. Make it fast"

Not quite a software idiom but I'm sure everyone here who's maintained any aspect of a production environment will resonate with this:

Anything that can go wrong, will go wrong - Murphy's Law

My favorite is rule of three. It's the one rule I always refer to when I review PRs.

Rule of three (computer programming)

Rule of three is a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code don't require refactoring, but when similar code is used three times, it should be extracted into a new procedure. The rule was popularised by Martin Fowler in Refactoring and attributed to Don Roberts.

View on Wikipedia

MINSWAN - “Matz is nice, so we are nice.”

At the end you read docs :)

Programming in a sentence:

• A computer is a machine that does what you say, not what you want.

Conway's Law: any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

WET: Write Everything Twice

In old enough to remember TMTOWTDI. I'm not sure it's a favorite though.

The simplest solution is most likely the right one.

Technically not a programming aphorism, but I think Occam's razor applies well to software.

"The length of a variable name should be proportional to its scope. The length of a function or class name is the inverse."

More of a good piece of advice than an idiom, but I love it anyway 🙂

I don't write bugs

90% of programming is fixing bugs, and rest 10% is writing them.

Make it work, make it right, make it fast...in that order. A good summary of priorities when coding!

The best code is no code at all

Name variables in a meaningful manner is far better then adding comments, which are getting outdated at some point anyway.

Code you don't write is defect-free, requires 0 unit tests for 100% coverage, and never needs to be maintained.

Know what not to write/make.

Don't touch what is working and doesn't need to be changed

As a programmer, my job is to solve problems. Sometimes even with code.

Code never lies

I had 99 problems, so I added a regex. Now I have 100 problems.

monetization = value subtraction

About engineering in general:
"Best component is no component", E. Musk

There are two difficult tasks in programming: naming things, cache invalidation and out-by-one errors.

Forget the exact wording... Throwing more people at a problem does not mean you will get the problem done that much quicker; you can't have a baby in 1 month by getting 9 women pregnant.

Write code as if the next person to work on it is a homicidal maniac who knows where you live.