Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share

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.

show 1 more comment

93 Answers

  1. KISS - Keep It Simple Stupid
  2. DRY - Don't Repeat Yourself
  3. YAGNI - You ain't gonna need it
share
8  
I think KISS should be "Keep It Simple, Stupid!" –  Dennis Cheung Dec 9 '08 at 16:33
10  
I would also add YAGNI. –  Daniel Straight Mar 9 '09 at 12:29
3  
@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
3  
OR if you combine them all: "KISS my DRY YAGNI" :P –  Darknight Jul 10 '11 at 14:15
show 9 more comments

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

share
19  
Write code as if an axe-wielding psycopath will have to maintain it. FTFY. –  Forgotten Semicolon Oct 1 '08 at 19:08
10  
...and the axe-wielding psychopath knows where you live. –  CAD bloke Oct 8 '08 at 20:24
2  
..,and he has just sharpened his axe... –  Roalt Mar 9 '09 at 9:56
1  
... and he is working by your side. –  Y3L1NNa Jul 31 '09 at 18:33
show 3 more comments

Be as lazy as possible.

share
2  
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
2  
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
3  
@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
show 5 more comments

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.

share
show 3 more comments

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.

share
3  
and if you're stupid, how would you know if it was simple? –  Steven A. Lowe Oct 1 '08 at 19:07
1  
"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
1  
@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
show 5 more comments

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

share
show 1 more comment

Do not reinvent the wheel.

share
5  
Some "wheels" need to be reinvented. –  CrashCodes Oct 1 '08 at 19:45
3  
How about: Only reinvent the wheel if the benefits will be worth the costs –  e.James Dec 9 '08 at 16:19
show 2 more comments

Understand the problem first!

share
show 4 more comments

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.

share
add comment

Knowing when not to program.

share
1  
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
show 6 more comments

Coffee in, code out.

share
3  
Tea in in my case =) –  Clox Aug 3 '09 at 16:36
show 1 more comment

If it wasn't tested, it is broken.

share
show 1 more comment

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

share
add comment
  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)

share
add comment

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

share
add comment
  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.
share
show 1 more comment

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.

share
add comment

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!

share
add comment

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

share
6  
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
1  
"I haven't tested it, I have only proved that it is correct" :) –  Daniel Daranas Jun 22 '09 at 10:27
add comment

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.

share
add comment

Any problem can be solved with another layer of indirection.

share
show 3 more comments

Know your tools.

share
add comment

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.

share
add comment

Write code for the next guy.

share
add comment

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

share
add comment

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.

share
add comment

It's all about the user.

share
add comment

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

share
add comment

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.

share
add comment

Start with the output and work backward.

share
add comment

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