I was reading the Wikipedia article on Douglas McIlroy and found a quote that mentions

"The real hero of programming is the one who writes negative code."

What does that mean?


It means reducing lines of code, by removing redundancies or using more concise constructs.

See for example this famous anecdote from the original Apple Lisa developer team:

When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put "-2000" on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.

  • 263
    Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take - Antoine de Saint-Exupéry Sep 27 '10 at 7:06
  • 7
    Is #LOC a good measure of code quality? I could 'Minify' any C or C++ code and reduce the line count significantly but it'd be a nightmare to maintain. Sep 27 '10 at 8:08
  • 10
    @systempuntout - and then there was Einsten's "(A scientific theory) should be as simple as possible, but no simpler" Sep 27 '10 at 8:44
  • 35
    Nothing runs faster, or is more reliable, or requires less maintenance, than code that isn't there. "When in doubt, dike it out!"
    – TMN
    Sep 27 '10 at 12:18
  • 5
    @JBRWilkinson: I'd say that there is a "sweet spot" regarding code brevity. Generally, shorter is better, but there comes a point when code can grow too terse and not be easy to decipher to another programmer.
    – GordonM
    Oct 16 '10 at 21:54

There's a Bill Gates quote along the lines of measuring programmer productivity by lines of code is like measuring aircraft building progress by weight.

I'd like to add that the LOC metric has encouraged the use of overly long-winded languages and deliberate reinventing the wheel to meet quota.

  • 30
    Yeah, that is the problem with any kind of metric. As soon as you use them to judge people's performance, they will start gaming the numbers.
    – Thilo
    Sep 27 '10 at 5:59
  • 5
    Has anyone actually ever used LOC as performance metric? I've only seen it used for things like "how bug of a project are we talking about here?" Sep 27 '10 at 7:53
  • 5
    @Michael: yes. Unfortunately, yes. Sep 27 '10 at 8:24
  • 39
    A programmer who wrote code for the Space Shuttle's onboard computers told me that he had to account for the weight of the software! The software was real (money was paid for it); it was on the shuttle; the weight of everything loaded on the shuttle must be accounted for. First example of measuring programmer productivity by weight of code. (Zero wasn't allowed, so he specified 0.00001 gram and all was satisfactory.) Sep 27 '10 at 15:11
  • 5
    @Jay: Ten years before this, programs were stored on punched cards. When you use punch cards, software has negative weight, because the cards weigh less after being punched! Oct 21 '10 at 14:33

When I was in high school -- and yes, we had computers back in the 70s, though we had to make them out of animal skins using stone knives -- one of the math teachers ran a programming contest. The rules were that the winning program would be the one that produced the correct output, and that had the smallest product of lines of code times run time. That is, if your program took, say 100 lines of code and ran for 5 seconds, your score was 500. If someone else wrote 90 lines of code and ran for 6 seconds, his score was 540. Low score wins, like golf.

It struck me as a brilliant scoring system, rewarding both conciseness and performance.

But the entry that technically met the winning criteria was disqualified. The problem was to print a list of all prime numbers less than 100. The disqualified entry went something like this (most of the students were using BASIC back then):

100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"

The student who wrote that entry pointed out that not only was it short and very efficient, but the algorithm should be obvious to anyone with even a minimal knowledge of programming, making the program highly maintainable.

  • 11
    More proof that counting lines of code is a very gameable metric :-)
    – paulecoyote
    Oct 20 '10 at 16:08
  • 47
    That BASIC program is brilliant! It is rather upsetting that the teacher disqualified the program. After all, lookup tables (which the program is somewhat similar to) can definitely be found in real-world programming. Oct 21 '10 at 2:37
  • 7
    A wise teacher may have accepted this BASIC program and used it to highlight the importance of getting an SRS right. Reminds me of a baseball coach who got so frustrated with his team that to show them how to play, he took the bat, got three strikes in a row and not to be outdone, he shouted to his team "See! That's how you bas***** are playing. Now take the bat and play properly!". Also reminds me of the person who wrote "creation saw the creator and blushed" and won the essay contest on 'wine'.
    – Nav
    Aug 26 '11 at 8:13
  • 3
    @Nav: Reminds me of a similar story that begins the same way. Then the coach throws a ball in the air, swings and misses. He throws it in the air again, swings and misses. He throws it in the air a third time, swings and misses. Then he says to the team, "See, THAT'S how you should be pitching!" (I have no idea what this story might have to do with software development.)
    – Jay
    Aug 26 '11 at 20:20
  • 14
    I'd be pretty upset if I were disqualified for this. A deterministic problem deserves a deterministic solution, right? When I write a 'Hello World' app I don't code it to check whether if I'm spelling 'Hello' correctly. Sep 28 '11 at 0:44

It's tongue-in-cheek. If it costs you $N per average coded line, then coding "negative lines" is surely a winner.

This means, as practical advice, that small code that accomplishes the job, is much better than big code that do the same thing, all other things being equal.

  • 2
    I see where you are coming from, but concise, easy-to-understand small-footprint code is seldom achieved in one go. It is usually write it so that it works(many lines), optimize for speed(a little fewer line) and optimize for maintenance/readability(fewer lines still). The real cost with the long return of investment is the second and third step, thus they are often skipped entirely. It is like "there is cheap, fast and good - you get to choose two".
    – RickiG
    Sep 27 '10 at 10:49
  • 2
    Actually, IME, optimizing for maintenence/readibility can actually increase LOC, since rewriting code to make it more self-documenting tends to also make it more verbose.
    – Visage
    Sep 27 '10 at 10:56
  • 1
    @Visage: "... all other things being equal".
    – Ira Baxter
    Sep 27 '10 at 14:10
  • the point is, I think, that all other things can't be equal between concise code and verbose code. Sep 27 '10 at 16:20
  • The reason the average line of code costs $N is because you first spend your time writing X lines. Then, over several iterations, reducing the final product by Y lines. So, the (X-Y) remaining lines seem to be very costly because the carnage of refactoring has cut away all the cruft.
    – Chris
    Oct 20 '10 at 18:54

Writing the same program in less code is a goal for everyone.

If a program took 200 LOC to code, and I write it in 150, I wrote -50 LOC. So I wrote negative code.

  • 3
    Also, writing less LOC means you can make less errors and spot them easily-
    – LucaB
    Sep 27 '10 at 12:52
  • 3
    Not true for Haskell and other languages that can be compressed to random noise. :)
    – Macke
    Sep 28 '10 at 16:57
  • 1
    Sure, my point was not "compressing code", but writing efficient algorithms that do thins in less LOC :) +1 for you comment.
    – LucaB
    Sep 29 '10 at 10:35

Thilo's answer is probably most accurate historically, but the "negative code" metaphor can also include performance and memory use - rewarding efforts to defer execution or allocation of something until it is actually needed.

This "procrastination pays" mentality produced such tongue-in-cheek axioms such as "Doing nothing is always faster than doing something", "The fastest code is the code that never executes", and "If you can put it off long enough, you might not ever have to do it" (referring to deferral of expensive operations until actually required)

One technique to realizing negative code is to challenge initial assumptions and definitions of the problem. If you can redefine the problem / input domain such that "sticky issue #3" is categorically impossible, then you don't have to spend time or code dealing with sticky issue #3. You've eliminated code by optimizing the design.