DEV Community

Ben Halpern
Ben Halpern

Posted on

What's your favorite software idiom/aphorism?

Discussion (61)

Collapse
ben profile image
Ben Halpern Author

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

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.

Collapse
andrewbrown profile image
Andrew Brown 🇨🇦

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

Collapse
geekynerdgirl profile image
Ashley

I always heard that as the 80-20 rule.

Collapse
ben profile image
Ben Halpern Author

That’s a different rule

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

Collapse
fifo profile image
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!
Collapse
yujiri8 profile image
Ryan Westlund

Man, I remember finding that so many years ago :D

Collapse
bytebodger profile image
Adam Nathaniel Davis

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

Collapse
hadrianhughes profile image
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.

Collapse
louy2 profile image
Yufan Lou • Edited on

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

Collapse
n8chz profile image
Lorraine Lee

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

Collapse
louy2 profile image
Yufan Lou • Edited on

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
Collapse
codemouse92 profile image
Jason C. McDonald • Edited on

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

Collapse
hyliancoder profile image
ΔNDRΞW

Oof, some old managers/owners needed to hear those

Collapse
youssefrabeiii profile image
Youssef Rabei

YAGNI: you aren't gonna need it

Collapse
mburszley profile image
Maximilian Burszley

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

Collapse
citizen428 profile image
Michael Kohl • Edited on

I'm not sure if it's an idiom or aphorism, but if not it should be: easy to delete is more important than easy to change.

Collapse
citizen428 profile image
Michael Kohl
Collapse
bytebodger profile image
Adam Nathaniel Davis • Edited on

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.

Collapse
yujiri8 profile image
Ryan Westlund

I heard a version of that saying that was way better: "There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors."

Collapse
qm3ster profile image
Mihail Malo

We have iterators now, so it was trimmed

Collapse
lukeshiru profile image
LUKESHIRU

💋🏜️ DRY KISS: Don't Repeat Yourself and Keep It Simple Stupid 🏜️💋

Collapse
wolfhoundjesse profile image
Jesse M. Holmes

WET: Write Everything Twice

Collapse
felipperegazio profile image
Felippe Regazio

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

Collapse
mustapha profile image
Mustapha Aouas

Small code duplication is better than a bad abstraction

Collapse
elmuerte profile image
Michiel Hendriks • Edited on

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?".
Collapse
ryansmith profile image
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.

Collapse
imedacf profile image
imedacf

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

Collapse
ryansmith profile image
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.

Thread Thread
imedacf profile image
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 😄

Collapse
yashints profile image
Yaser Adel Mehraban

Everything comes down to one word:

Bikeshedding

😂😂😂

Collapse
ryands17 profile image
Ryan Dsouza

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.

Collapse
codingmindfully profile image
Daragh Byrne

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

Collapse
jcsvveiga profile image
João Veiga

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

Collapse
elmuerte profile image
Michiel Hendriks • Edited on

I know that one as: make it work, make it right, make it fast.
I think it was by Kent Beck.

Collapse
jcsvveiga profile image
João Veiga

It is

Collapse
vinayhegde1990 profile image
Vinay Hegde • Edited on

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

Collapse
cathodion profile image
Dustin King

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.

Collapse
joshuap profile image
Josh Wood

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

Collapse
sharadcodes profile image
Sharad Raj (He/Him)

At the end you read docs :)

Collapse
fluffynuts profile image
Davyd McColl
Code is for co-workers, not compilers.
Collapse
hadrianhughes profile image
Hadrian Hughes

"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 🙂

Collapse
dmfay profile image
Dian Fay

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.

Collapse
maestromac profile image
Mac Siri

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

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.

Collapse
pinotattari profile image
Riccardo Bernardini

Programming in a sentence:

  • A computer is a machine that does what you say, not what you want.
Collapse
bugmagnet profile image
Bruce Axtens • Edited on

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

Collapse
sergix profile image
Peyton McGinnis

The simplest solution is most likely the right one.

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

Collapse
sqlmancerqueuellc profile image
SQLmancerQueueLLC • Edited on

The best code is no code at all

Collapse
kritner profile image
Russ Hammett

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.

Collapse
canro91 profile image
Cesar Aguirre

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

Collapse
jrop profile image
Jonathan Apodaca

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

Collapse
danrot90 profile image
Daniel Rotter

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

Collapse
tuned profile image
Lorenzo (Mec-iS)

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

Collapse
n8chz profile image
Lorraine Lee

monetization = value subtraction

Collapse
lahmacun profile image
Mustafa Zahid Efe

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

Collapse
sqlmancerqueuellc profile image
SQLmancerQueueLLC

Code never lies

Collapse
fluffynuts profile image
Davyd McColl

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

Collapse
jvarness profile image
Jake Varness

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.

Collapse
fluffynuts profile image
Davyd McColl

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

Collapse
fluffynuts profile image
Davyd McColl

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

Collapse
fluffynuts profile image
Davyd McColl

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

Collapse
yizhuang profile image
yi

I don't write bugs

Collapse
kritner profile image
Russ Hammett

Better to have a kick ass half over a half assed whole