What's your favorite software idiom/aphorism?

Comments

[Ben Halpern]

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

[Andrew Brown 🇨🇦]

I can't think of any other's Ben. You nailed it.

[Ashley]

I always heard that as the 80-20 rule.

[Ben Halpern]

That’s a different rule

Pareto principle

The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes.

View on Wikipedia

[Filipe Herculano]

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!

[Adam Nathaniel Davis]

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

[Hadrian Hughes]

I like seeing this applied on the macro level too. ie keeping a command line tool specialised to doing one specific task very well.

[Yufan Lou]

You'd be surprised at how god-damn much those command line tools actually do.

If you open up a manpage for ls on mac, you’ll see that it starts with

ls [-ABCFGHLOPRSTUW@abcdefghiklmnopqrstuwx1] [file ...]

That is, the one-letter flags to ls include every lowercase letter except for {jvyz}, 14 uppercase letters, plus @ and 1. That’s 22 + 14 + 2 = 38 single-character options alone.

-- The growth of command line options, 1979-Present

[Lorraine Lee]

Also Google's rule for browser extensions, each extension should do one thing.

[Yufan Lou]

This is an idiom which sounds nice but cannot be applied, due to the underspecificity of both "one thing" and "well". It is as meaningless as the following function signature:

f :: a

[Jason C. McDonald]

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

[Andrew Reese]

Oof, some old managers/owners needed to hear those

[Youssef Rabei]

YAGNI: you aren't gonna need it

[Maximilian Burszley]

Need a mug with this on it for retros. Some coworkers want the kitchen sink "in case our app grows bigger."

[Adam Nathaniel Davis]

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.

[Mustapha Aouas]

Small code duplication is better than a bad abstraction

[Felippe Regazio]

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

[Michiel Hendriks]

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?".

[Ryan Smith]

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

[imedacf]

The first one feels like, one should not touch it if it works, but bad code still needs to be refactored.

[Ryan Smith]

I think it depends on the situation, refactoring for the sake of it may not be worth the effort. If it works and you won't have to touch it or worry about its performance, it can be left alone. If it is a commonly used piece of code and it is causing problems when building features, then that is a good time to refactor it.

[imedacf]

Ofc, it depends, but I would build my mind around refactoring the bad code, rather then thinking not to touch it, unless its broken 😄