Skip to content
markdown guide

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.


That’s a different rule

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


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!

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


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


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


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


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


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

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


Oof, some old managers/owners needed to hear those


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


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.


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.


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


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


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.


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


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.

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


Everything comes down to one word:




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


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


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


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


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.


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.


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.


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


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.


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


Programming in a sentence:

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

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.


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


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.


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.


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


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


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


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


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


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


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


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


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

Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.