Hacker News Reader

Comment by panic | Hacker News Reader

Peter Naur's "Programming as Theory Building" also addresses this topic of a "theory" which is built in tandem with a piece of software, in the minds of the programmers building it, without actually being a part of the software itself. Definitely worth a read: http://pages.cs.wisc.edu/~remzi/Naur.pdf

View on HN

The biggest problem is when users of software, programmers of software, and the software code itself have 3 different incompatible theories of how it works.

Sometimes it gets worse still: you can have different theories according to (a) scientists doing basic research into physics or human perception/cognition, (b) computer science researchers inventing publishable papers/demos, (c) product managers or others making executive product decisions about what to implement, (d) low-level programmers doing the implementation, (e) user interface designers, (f) instructors and documentation authors, (h) marketers, (h) users of the software, and finally (i) the code itself.

Unless a critical proportion of the people in various stages of the process have a reasonable cross-disciplinary understanding and effective communication skills, models tend to diverge and software and its use go to shit.

This is why during software design the first thing I talk about is not the UX flow or the software architecture, but the user's mental model (or the mental model we want to give them).

This is why dogfooding is so important - you're updating the programmers' model to align with the users' model, reducing the total problem space (and thus the available avenues to get it wrong) by many degrees of freedom.

Seconded. In fact I would suggest it instead of this article - it is much better.

Thirded. It is a classic and was far ahead of its time.

There are some great comments about this buried in https://hn.algolia.com/?query=naur%20theory&sort=byPopularit....

The article looks good but I don't see why that should take away from the OP.

The OP makes excellent points concerning the relative independence of design and code in the context of the "extreme programming" paradigm having become very common if not dominant.

Thanks for linking this, don't think I'd ever seen it before and as someone who's a second generation holder of a very large system's underlying theory it feels extremely accurate, but puts things into terms I never considered before.

Nice, that's great! I hadn't known of it before.

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

-- Linus Torvalds

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

Isn't this definition circular, using "programmed" in defining "programming"?

I think for circularity you'd need a pair of definitions -- "programming: making a program" and "program: the result of programming". In this case, we already know what a program (or a "programmed solution") is -- that is, we can tell that something is a program without necessarily knowing how it was made. So the definition at least provides some new information on top of that -- the name for the activity of creating programs.[1] Also, by including the concept of "design", it lets you know when the author says "programming", he doesn't just mean the acts of writing source code, or typing it in.

[1] You could have probably guessed that the name was going to be "programming", but it might not have been.

Reply on news.ycombinator.com