The Weirdest Programming Principles You’ve Never Heard Of

Joel Lee 22-12-2017

We’ve already walked you through the most essential programming principles 10 Basic Programming Principles Every Programmer Must Follow Always write code that can be maintained by anyone who may end up working on your software. To that end, here are several programming principles to help you clean up your act. Read More you need to know about, but there’s another class of programming principles that may prove even more beneficial than those.


Whereas the aforementioned principles teach you how to be smart with your code, the following principles will teach you to be wise with your code. Some of them are strange, and many of them are humorous, but they’re all equally practical and important. Take heed!

1. The Bloat Principle

This one has so many variations that it’s hard to pick one as the main one. Perhaps the most “official” version is the Law of Software Envelopment, more commonly called Zawinski’s Law, named after Jamie Zawinski and mentioned in The Art of UNIX Programming:

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

It’s talking about the tendency of programs to attract more and more features over time and inevitably drift towards increasing complexity. You may know this as feature creep, which is the ongoing addition of new features that have nothing to do with the main purpose of the program. Feature creep leads to bloat, and bloat is often undesirable.

This can also apply to software performance:

“Software expands to consume all available resources.”

Back in the 90s, hard drives and CPUs and RAM were far more restrictive than they are today and programmers worked hard to fit as much as they could within the limits. Yet now that we have bigger drives and faster CPUs and more RAM, we still struggle to respect limits. Everything gets bloated over time. It’s your job to keep that in check.


The Weirdest Programming Principles You've Never Heard Of programming laptop mac

2. The “Worse Is Better” Mentality

Almost as if in response to the Bloat Principle, we have the Worse Is Better mentality, first coined by Richard P. Gabriel in an essay he wrote about software quality:

“Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.”

In other words, it’s wise to figure out the one problem your software aims to solve and then be very good at that one thing. Keep it simple. The more you spread yourself thin, the more unmanageable the project will become, and the more undesirable it becomes for users.

What happens when you ignore this? You end up with the Software Peter Principle:


“A overly complex project will eventually become too complex to be understood even by its own developers.”

It comes from the broader Peter Principle, which states that when employees are promoted based on their current competency and not their expected competency at their next position, all employees eventually end up in a position of incompetence. Take that principle and apply it to software, and you’ll see why worse software can often be better.

3. Eagleson’s Law

“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

This seemingly demotivational saying is actually something to embrace. The fact is, nobody is perfect. You might think you’re a genius programmer right now, but there’s always something more you can learn, always more room to grow. If you ever look back on old code and cringe, it probably means you’ve learned something new since then.

Put another way: if you look back on an old project and you can’t see anything you can improve or would do differently next time around, you’ve likely stagnated as a programmer.

4. Principle of Least Astonishment

“If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.”

First published in the IBM Systems Journal back in 1984, this principle is still surprisingly relevant today — perhaps more so than ever before.


It essentially touches on the delicate balance between innovation and familiarity: if a piece of software is too different from others of its kind and doesn’t conform to user expectations, then they likely won’t adopt it. It’s better to strive for incremental improvements that are just big enough to be impressive but small enough to stay familiar.

The Weirdest Programming Principles You've Never Heard Of programming laptop coffee

5. Law of Cybernetic Entomology

“There’s always one more bug.”

Often called Lubarsky’s Law of Cybernetic Entomology, it’s unclear who this Lubarsky actually is. However, his principle rings true for all programmers: no matter how cleanly you write your code, no matter how robustly you test your modules, no matter how often you refactor your classes, there will always be another bug.

In a way, this is a freeing principle. While we should definitely strive for bug-free code, it’s also important to remember that perfectionism is the enemy of good. Look for bugs, fix them when they arise, and then move on.


6. Kernighan’s Law

“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, by definition, not smart enough to debug it.”

Brian Kernighan, the very same one who co-authored the C programming language bible Why C Programming Is Still Worth Learning C is not a dead language. In fact, IEEE Spectrum magazine ranked it as the No. 2 top language in 2017. Here are five reasons why. Read More , is famous for this insightful law. The crux of it is this: write good code, write readable code, write simple code, anything as long as it’s not clever code.

Trying to flex your programming muscles with ivory tower complexity is the exact opposite of what it means to write clean and better code 10 Tips for Writing Cleaner & Better Code Writing clean code looks easier than it actually is, but the benefits are worth it. Here's how you can start writing cleaner code today. Read More . The harder your code is to understand, the harder it will be to debug when it inevitably breaks.

And as Robert C. Martin explains, it’s not just about debugging either:

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code . . . [Therefore,] making it easy to read makes it easier to write.”

The Weirdest Programming Principles You've Never Heard Of rubber duck programming

7. Rubber Duck Debugging

This one isn’t so much a principle as it is a technique, but it’s so helpful and strange that we’d be remiss to leave it out.

First told in The Pragmatic Programmer, rubber duck debugging is when you debug broken software by explaining your code to an inanimate object (e.g. a rubber duck) one line at a time. It works because the act of explanation triggers different parts of your brain, and you’re more likely to spot inconsistencies and figure out where you went wrong.

For this reason, a rubber duck can be a surprisingly nifty gift for programmers The Best Geek Gifts for Programmers: 20 Ideas for Coders and Nerds Looking for a gift for a programmer? Here are the best geek gifts, ranging from mechanical keyboards to standing desks and more. Read More , whether you buy it for yourself or for a programming buddy of yours.

8. The Ninety-Ninety Rule

“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.”

This cheeky little proverb by Tom Cargill gets at the heart of why programming can be so frustrating: no matter how close you think you are to being finished, you’re much farther away than even your best estimations. When you think you’re done, you’re only halfway there.

It goes hand in hand with Hofstadter’s Law:

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

The Weirdest Programming Principles You've Never Heard Of laptop desk coffee crunch time

9. Parkinson’s Law

“Work expands so as to fill the time available for its completion.”

This one principle, coined by Cyril Northcote Parkinson, is a broader principle that absolutely applies to programming and goes hand in hand with the Ninety-Ninety Rule above: however much time you have to finish a project is exactly how long it’s going to take. In software development, “finishing early” is pretty much a myth.

Parkinson’s Law is the reason why proper deadlines are crucial if you want to finish and ship your software. That’s why modern professional programmers often recommend agile project management principles How to Use Agile Project Management Principles to Organize Your Life Agile, best known as a project management method, is a great framework for managing your personal life. We'll show you which principles you can borrow -- free worksheet download included! Read More and project management tools like Asana Trello vs. Asana: The Best Free Project Management Tool Is... Choosing between Trello and Asana is difficult. Here we compare the free plans and help you decide which project management tool is best for your team. Read More .

10. Brook’s Law

“Adding manpower to a late software project makes it later.”

The next time you’re late on a project, which is likely since most programming projects need more time than allotted, remember that adding coders won’t solve it any faster.

In fact, it’ll probably take longer to complete. Not only do you need to bring the new coder(s) up to speed, they’ll likely clash with the existing coders. More things will need to be documented, more bureaucracy will be needed to keep everyone on the same page, and more friction will come out of the whole crunch-time experience.

Going Forward as a Programmer

Now that you know these principles, you’re actually better suited for the real world of programming, not just what you’ve encountered in school, in a web course, or in a bootcamp. These principles come from years and years of experience and failures.

With this newfound wisdom, you can now set forth to a high-demand programming career 10 Computer Programming Careers and Jobs That Are in High Demand Looking for a career in programming? Here are just some of the best paying coding jobs that you can apply for today. Read More with more realistic expectations. For that, learn how to maximize your programming career opportunities How To Improve Your Programming Career Opportunities If you're hoping to start, restart, or otherwise improve your programming career, it isn't easy. If you are in college, the time is now. Here are some tips that can take you far. Read More . And if you decide that programming isn’t for you, don’t fret — consider one of these non-coding tech jobs instead Coding Isn't for Everyone: 9 Tech Jobs You Can Get Without It Don't be discouraged if you want to be a part of the tech field. There are plenty of jobs for people without coding skills! Read More .

Which of these principles ring truest to you? Know of any other weird programming principles that we missed? Let us know down in the comments below!

Affiliate Disclosure: By buying the products we recommend, you help keep the site alive. Read more.

Whatsapp Pinterest

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Herb Moor
    December 29, 2017 at 6:53 pm

    My old project manager said that bugs were merely undocumented features!

  2. Andrew Wolfe
    December 29, 2017 at 4:12 pm

    Good collection. I'm particularly glad you went back to uncover Fred Brooks. Some of the writings from the 1960's and 1970's, like Brooks's "The Mythical Man-Month," are among the most useful and well-written articles on creating software systems.

  3. GS
    December 28, 2017 at 2:02 am

    The rules haven't really changed since I started programming in 1984. It's still a tough job.

  4. Danny117
    December 23, 2017 at 2:48 am

    LivingDeadChangePhobia Management fear of changing a system by persons now dead who learned to code on punch cards or on the job.

  5. Danny117
    December 23, 2017 at 2:46 am

    LivingDeadPunchCardPhobiManagement Fear of changing a system designed by people who are dead and learned to program with punch cards.

  6. Tom
    December 23, 2017 at 1:37 am

    A "clever" article that can b summed up with one acronym I learned in programming school in 1970. KISS: Keep It Simple Stupid

  7. Rob
    December 23, 2017 at 12:16 am

    Outstanding article! I'll share it with the rest of planet Earth as soon as I'm done writing this comment.

  8. dragonmouth
    December 22, 2017 at 11:03 pm

    Once you've run into all of these, you can call yourself an experienced programmer.

    "Back in the 90s, hard drives and CPUs and RAM were far more restrictive"
    The problem with small drives, little RAM and slow CPUs did not start in the 1990s and PC. It goes back to the ENIAC in the mid 1940s. It is this problem that was the main cause of the Y2K scare. To conserve storage space and computer memory, programmers kept on inventing novel ways of compressing dates in as few bytes as possible. Then before 2000 came along, all those cleverly formatted dates had to be uncompressed throwing every IT member into a tizzy.

    "5. Law of Cybernetic Entomology"
    It is a given that users will find bugs in even the best tested and debugged software. There always is more users than developers. Also developers think rationally and logically when developing and testing software. Users have no such constraints. They abuse the software with impunity and abandon.

    • V.R. Swamy
      December 31, 2017 at 1:32 pm

      If there were no bugs in any software then there would be no "hackers" I believe.

      A 83 year old "USER"

    • Paul Minshall
      September 20, 2019 at 8:10 am

      Unfortunately, a lot of so called professional testers just follow the test scripts, which are largely written by the developers, so you end up marking your own homework.
      Occasionally though, you get a tester who has a special knack of breaking software in ways that the developer never envisaged. If you find such a tester, treasure them, they are your best secret weapon.

  9. Martin DiViaio
    December 22, 2017 at 9:50 pm

    The TRUE Tao of Programming

    1. Every program can be reduced by one instruction or statement.
    2. Every program has at least one bug.
    Therefore: Every program can be reduced to a single instruction that doesn't work.

    I always took this as a stab at programmers who spend way to much time on code optimization.

    • Howard A Pearce
      December 22, 2017 at 10:12 pm

      "Every program has at least one bug."

      Does that mean you shouldn;t correct them until there are at least 2 bugs ?

      • Martin DiViaio
        December 22, 2017 at 10:19 pm

        Only if you can squash them under the same boot stomp.