[ghh]

So Naur is saying that programming helps programmers understand how software can solve the problem at hand, and that this is more important than the resulting code.

I might be reading this the wrong way, but this helps explain the Not-Invented-Here syndrome [1]. Why not just re-use some other code? Because it's not just about the code, but about the programming team's understanding of how the software tackles the problem.

[1] http://en.wikipedia.org/wiki/Not_invented_here

[pfortuny]

It looks similar but it is not exactly the same thing. In some sense, not being the 'writer' of the code makes it difficult for you to understand it and hence to use it as the expression of your theory, which may lead you to rewrite everything (thus 'invent it here').

However, the rational way to do it would be to try and read the outside code and reuse it as much as possible. In the same way that you read a book on Calculus and do not need to write a new one if you have learnt it.

But we humans are anything but rational.

[pavlov]

You're probably not going to learn calculus just by reading a book, though. To understand it and to be able to deploy the knowledge to solve actual problems, you need to do practical exercises.

In a sense, doing those exercises is "rewriting calculus" in a form that is internalized for yourself. It's the same as learning to play a piece of music: if you're a good piano player, you can read the sheet music for a Beethoven sonata and have an idea of what it's like [0], but you need to practice the piece to really understand what it means.

Maybe the design of software should also contain some kind of built-in learning process. When one encounters a new codebase, it can take quite a while to figure out where to even start deciphering the architecture... What if there was a design document with a textbook-like approach that extended all the way into the code itself: there would be "exercise hooks" expressly for the purpose of allowing a programmer to experiment with the software's internals in a controlled fashion.

- -

[0] I guess -- I suck at music, so I wouldn't really know.

[noblethrasher]

Doing the exercises is not rewriting calculus, but it does lead to the discovery of useful pseudo-theorems about mathematical expressions and calculus-based techniques for manipulating them.

An actual rewriting of calculus would involve discovering proofs for things like the Mean-Value Theorem or the Fundamental Theorem of Calculus. Short of that, you could wrestle with trying to discover proofs for theorems so that you can at least appreciate the canonical ones. Incidentally, this is what every mathematics major has to do in order to earn their degree.

[noblethrasher]

I think one of the reasons for NIH is that, unlike mathematical theorems, programs are not customarily explicit about the domain over which they hold and therefore are just pseudo-theorems. The few programs that do have that explicitness, such as compilers and small UNIX utilities, tend not to get reinvented. Also, the domain can become obsolete (e.g. ascii vs utf8 or unstructured text vs XML).

Thus, NIH may really just be a want of a theorem (sometimes merely a stronger one).

[Confusion]

I think you are right it helps explain NIH, but I don't think it justifies it. In the article, Naur says:

  I shall use the word programming to denote the whole 
  activity of design and implementation of programmed 
  solutions. 

So 'programming' is not just 'producing code', but also everything leading up to that. It is very well possible to design a solution for your specific problem and then conclude somebody already implemented (parts of) it for you. You get NIH if you need to implement (part of) the code to discover how you can use software to solve a problem and subsequently cannot let go of your code. So there are two opportunities to get rid of NIH: 1) become sufficiently proficient that you can design software without needing to write lots of it already and 2) be able and allowed to throw your code away.