Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I always liked to ask myself "what's the first principle(s) of this?" after I learned the basic stuff of something (e.g. programming). It's an inspiring question, IMO, that can force you to think about the most important principle(s) behind something, especially a skill such as programming.

So, what do you think is the first principle(s) of programming? I'll give my answer below a little later.


locked by maple_shaft May 15 '13 at 16:40

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

We do not talk about fight club. – Job Jul 10 '11 at 14:25

93 Answers 93

  1. KISS - Keep It Simple Stupid
  2. DRY - Don't Repeat Yourself
  3. YAGNI - You ain't gonna need it
KISS should be Keep It Simple Smart. The first time you have to rewrite a large chunk of your code because you didn't design smart and extensible you will agree to this. :) – Sandor Davidhazi Dec 4 '08 at 8:35
I think KISS should be "Keep It Simple, Stupid!" – Dennis Cheung Dec 9 '08 at 16:33
I'm actually working on a blog post about how these two are the two most near and dear to a programmers heart and how at the same time they are a bit of oxymorons as often times you'll need to choose one against the other – Andrew G. Johnson Jan 8 '09 at 20:11
I would also add YAGNI. – Daniel Straight Mar 9 '09 at 12:29
@Programmin Tool - I don't think "stupid" is superfluous. I think it conveys that we have a tendency to want to be "smart" and this manifests as unneeded complexity. As I see it, the "stupid" tries to remind us of this tendency by helping us remember what we initially think is "smart" is usually not. – codekaizen Jul 31 '09 at 19:01

Write code like if it was you that would have to maintain that code.

This is a very practical heuristics, 3x :) – pongba Oct 1 '08 at 19:08
Write code as if an axe-wielding psycopath will have to maintain it. FTFY. – Forgotten Semicolon Oct 1 '08 at 19:08
...and the axe-wielding psychopath knows where you live. – CAD bloke Oct 8 '08 at 20:24
..,and he has just sharpened his axe... – Roalt Mar 9 '09 at 9:56
... and he is working by your side. – Broken_Window Jul 31 '09 at 18:33

Be as lazy as possible.

Again, too general, IMO. This begs the question "How lazy is the appropriate amount of laziness, really?", because obviously "sloppy" is something you don't want to be either. – pongba Oct 1 '08 at 19:10
This is a reference to perl's "Laziness, Impatience, and Hubris" – Ólafur Waage Oct 1 '08 at 19:21
So we're talking about different kind of laziness? I thought by "lazy" Bob means "don't bother organizing your code before it gets tangled" :D – pongba Oct 1 '08 at 19:31
Too general. By that analogy all variables and functions would be 1 letter because I was 'too lazy' to type out something meaningful. Assuming I had to maintain it also however, then perhaps you are correct, because I would make it as easily maintainable as possible. – Kyle B. Jan 8 '09 at 21:21
@Kyle: Yeah, that's the point. "True laziness" is making things easiest for yourself now as well as in the future. Which turns out to be the same as doing things properly. If you do less work now but more work later, you're not being "as lazy as possible" :) – Adam Bellaire Jan 12 '09 at 12:58

Zen, part I: Programming is only the road, not the way.

Programming is only the technique to teach a computer what it's gotta do. To be successful in creating fast, reliable software means to know your algorithms, best-practices and all the other stuff not necessarily connected to your Programming (language).

Zen, part II: If you are in a hurry, stroll along slowly. If you really are in a hurry, make a detour.

Sounds silly, but do not let yourself get into compromises that (really) may trouble you afterwards. I got a rule: If you are at the core of a program, try to be as precise and good as possible. If you are using methods from the core that are deep in your software, try to be faster in coding. If you are coding above these two, you can even get a little bit more sloppy.

Design errors are the hardest to find and/or fix, next step are programming errors in parts everyone relies on, then the "real showing-off software parts". If you need to fix a design error at the end of a project, ummm, that's not good... ;-)

Zen, part III: Know your path, Neo.

Know your environment, tools and the stuff you rely on on a daily basis and get it sorted so that it works for you. Best if you use your programming "environment" so natural that you do not even have to think of it. If you have to get a job done do not introduce "fancy new stuff" but do your work. This stuff can be introduced in a new project, namely then when you have time to prepare and use it.

Uh, and then again: I landed in Zen land whilst speaking about programming :) – Georgi Oct 1 '08 at 21:46
@part III - don't add "fancy new stuff" unless you're getting paid to do it! – Jason Jul 31 '09 at 18:35
+1 for the Matrix reference. I'm a sucker for a good one (that and the Zen. Makes me think of Python) – new123456 Feb 14 '11 at 22:35

KISS (keep it simple, stupid).

It does indeed beg the question "How do you define simple?" And also "When is something too simple for the task at hand?" This is why you cannot become a good programmer just by knowing the first principle of programming.

I think this is a too general rule. It begs the question "how do you define 'simple', really". – pongba Oct 1 '08 at 19:06
and if you're stupid, how would you know if it was simple? – Steven A. Lowe Oct 1 '08 at 19:07
That's a good one, Steven :) – pongba Oct 1 '08 at 19:11
"This is why you cannot become a good programmer just by knowing the first principle of programming" - love it. – yuval Jul 31 '09 at 18:33
@Dima: you're right, I mean that quality and simplicity (in this case at least) are both undefinable, yet we know it when we see it, if our eyes are trained. – Adriano Varoli Piazza Aug 1 '09 at 21:48

Premature optimization is the root of all evil. -- Donald Knuth

Whether in implementation OR design. – Epsilon Oct 2 '08 at 3:02

Do not reinvent the wheel.

The right answer to the question as to whether or not one should reinvent the wheel is always "it depends". So "don't reinvent the wheel" only goes so far. It may serve as a good heuristics most of the time, but not every time. – pongba Oct 1 '08 at 19:13
Some "wheels" need to be reinvented. – CrashCodes Oct 1 '08 at 19:45
Tell that to Dunlop. He invented the pneumatic tire. If it wasn't for him, reinventing the wheel, we'd have a pretty bumpy ride. – Kibbee Oct 1 '08 at 20:36
How about: Only reinvent the wheel if the benefits will be worth the costs – e.James Dec 9 '08 at 16:19

Understand the problem first!

Ah, finally somebody with this one. You ca kiss, yagni, dry all you want. It's useless if you program something for nothing. – e-satis Jun 22 '09 at 10:22
@e-satis: Yeap, that what I thought when I first answer this. I scroll for all the answer and surprisingly nobody posted before. – OscarRyz Jun 22 '09 at 18:42
Good answer. Hours and hours get wasted when programmers don't properly understand the full requirements of a problem. – Steve Wortham Jul 31 '09 at 19:10
Problem is: how do you you know you understand the problem? – CamelCamelCamel Mar 17 '11 at 21:20

YAGNI - You Ain't Gonna Need It. The idea behind YAGNI is to program for your requirements, not for prospective, potential features. The premise is that by keeping to what you need to program, you will (among other things) cut code bloat, reduce complexity, avoid feature creep, and reduce the restrictions on what can be done (and how it can be done) in the future.

I suppose it works in tandem with modular design: Future features can be augmented without redesigning existing code.


Knowing when not to program.

what on earth is this supposed to mean? – anbanm Oct 1 '08 at 19:32
And when is that? – pongba Oct 1 '08 at 19:34
Sometimes you need to tackle a users problem differently - not just code a solution. – RichH Oct 1 '08 at 20:01
Human judgement and decision-making are part of everything; sometimes there's no point in trying to automate judgement. – S.Lott Oct 1 '08 at 20:05
What he means is that many programming problems can be solved cheaper and more timely by purchasing off the shelf applications, components, or libraries. – Gordon Bell Oct 3 '08 at 5:08

Coffee in, code out.

Tea in in my case =) – Clox Aug 3 '09 at 16:36
+1 hmm more like "Coffee In, Code + lots of loo breaks?" :) I love both Coffee and tea, I swing both ways... – Darknight Jul 10 '11 at 14:17

If it wasn't tested, it is broken.

I agree on that one – Clox Aug 3 '09 at 16:37

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

-- Charles Antony Richard Hoare

  1. Distinguish between cause and effect (working with computers)

  2. Distinguish between fact and opinion (working with people)

  3. As simple as possible, but no simpler (design)


Programming is a means not an end. Or perhaps, "Can does not mean should."

  1. Understand why the program will make someone happy (otherwise, why aren't you outside playing with all the other kids?). (This person can be you.)
  2. Develop a conceptual model of the business domain that captures all the needed complexity, and no more.
  3. Develop a conceptual model of the software architecture that captures all the needed complexity, and no more.
  4. Ruthlessly keep all other complexity out.
well said! couldnt agree more – Antony Jun 14 '09 at 12:20

In my opinion, the most important principle is the reduction of complexity by creation of good abstractions.

This includes

  • understanding the problem to be solved,
  • designing an appropriate solution for it and
  • implementing it,
  • preferably in a way that keeps the code understandable and maintainable,

but also determination of the point where to stop creating abstractions and get down to the fundamental properties of the implementation technologies (e.g. database system, programming language) to prevent creation of avoidable additional complexity.


Program with an audience in mind. By that, don't assume that anything you write will not be read and maintained by you or someone else.

A corollary to that: Prove that you understand the problem you are trying to solve by naming your variables and functions and classes well!


it doesn't work till you showed it in a test

That's not true, I've written tons of code that works and isn't tested! :D – Gavin Miller Jan 8 '09 at 19:15
"I haven't tested it, I have only proved that it is correct" :) – Daniel Daranas Jun 22 '09 at 10:27

Think first, code later.

You're nowhere near as smart as you think you are. Ask questions. Learn to value your peers.

When debugging, the first answer will almost always be wrong.

Code you write with the intention of tossing out tends to become a cornerstone of much larger processes. Never leave anything written haphazardly.


Any problem can be solved with another layer of indirection.

Actually, having too many indirections is itself an issue waiting to be identified and resolved. So.. – pongba Oct 1 '08 at 19:15
resolved... by another layer of indirection! =) – Erik Forbes Oct 1 '08 at 20:55
Oddly enough, its true. Look at Spring... – Joshua Oct 3 '08 at 13:16

Know your tools.


Principle: Software is Knowledge Capture.

Consequences: Many techniques for knowledge representation, all founded on Abstraction. Gives us layers, tiers, encapsulation, separation of concerns.

Many techniques for procedure representation, all founded on Sequence, Choice, Repetition.


Write code for the next guy.


Always write code as if the person who will be maintaining it is a psychotic serial killer who knows where you live

Also, never think you know everything about programming, keep learning


I got into programming by way of studying digital electronics, so I guess for me the basic logic gates (not, and, or, xor, implies) were the first principles of programming.


It's all about the user.


Garbage in - Garbage Out It doesn't matter how nice your user interface is if the data is bad.


DRY, pretty much everything else spawns from it. KISS is the other end of the balancing act to make sure you don't pursue software elegance to levels of insanity.


Start with the output and work backward.


Not the answer you're looking for? Browse other questions tagged or ask your own question.