- 36comments
- 20comments
- 521comments
- 127comments
- 215comments
- 78comments
- 1comments
- 163comments
- 33comments
- 69comments
- 227comments
- 145comments
- 7comments
- 92comments
- 23comments
- 50comments
- 56comments
- 23comments
- 37comments
- —discuss
- 366comments
- 9comments
- 10comments
- 48comments
- 36comments
- 105comments
- 34comments
- 39comments
- 41comments
- —discuss
The last paragraph:
I keep sending copies of this paper to numerous colleagues. AFAIK almost none of them finished (or even started) reading it. I’m at a loss to explain why, since it is such a deeply insightful paper.
Repost of https://news.ycombinator.com/item?id=10833278.
Yes, but this paper is so important, yet not as well known as it should be, that I feel it is right it resurfaces every few years here.
Everyone involved in software development should read and understand it!
Often times on HN, people provide links to previous postings merely so others can reference the previous discussions. It's generally not meant to be a call out of bad behavior.
Also https://news.ycombinator.com/item?id=7491661 from 2011, and https://news.ycombinator.com/item?id=121291 from 2008.
Strange article - essentially comes down to "If you need to know, ask, because no one understands - or probably even reads - documentation anyway."
It's not obvious how thinking about programming as theory building will help with any part of this. The real problem seems to be poor communication between projects and developer groups, with the implication that any self-guided learning approach can't possibly work because it's impossible to communicate the "why" of code without having someone who does understand it explain it to you.
It's an interesting point, and in some ways explains a lot. But I see no reason to think that "theory building" - which really means teaching domain expertise external to the code - is a practical solution in most projects.
I really liked the article. I think the idea is fundamental. It sheds light on the value of things like trying to retain staff and allowing them to become experts on a piece of code. It explains why Brook's Law ("adding human resources to a late software project makes it later") is true.
That seems like a strange summary. A better one:
Everyone builds models about the world around them (Naur used "Theory" instead of "Model" but they're the same here). Not all models are as accurate as others, though they may be sufficient for many situations. The developers of a system (most likely) have the best model of how the system operates and is constructed. Operators have a separate model. Maintainers have a third model. By separating the initial developers, operators, and maintainers, and reducing communication to, primarily, the exchange of programming notation and documentation, three different models (at least) will be produced. Incorrect models lead to incorrect usage and incorrect maintenance activities.
If your programs are short-lived or very simple, this paper is of little utility to you. But if your programs are expected to live for a decade or more, or are very complex, the ideas here are more useful, probably critical to the longterm success of your enterprise.
I work (or have worked) on systems that were developed over 30 years ago. A lot of knowledge has been lost, and a lot of wheels get reinvented. Or components of the system go underutilized, or misused because of misunderstandings of how the system functions and was designed. The more successful projects have had people working on or with them for 10+ years. Without them, program modifications have usually been small (large changes were seen as untenable), complete rewrites (because no one understood it), or failures (long delays, maybe a working product at the end, often with one or more rewrites along the way).
For people with screen readers, here is an html version from the wayback machine.
https://web.archive.org/web/20121223063306/https://www.dc.ub...
Thank you for sharing this!
In my opinion, this is spot on and an important insight into programming.
The validity of this view of programming is particularly evident when using a logic programming language like Prolog or Mercury: In this case, the programmers' task is to describe what holds, and the clauses that constitute the program and their semantic consequences are literally the theory of interest.