speaking of such things, I was just re-reading Jack Reeves, What Is Software Design today. http://www.developerdotstar.com/mag/articles/reeves_design.html

Great post again. Thanks Michael. I would add

• “Top 25 most dangerous programming errors” – http://www.sans.org/top25errors/
• “The Joel Test: 12 Steps to Better Code” – http://www.joelonsoftware.com/articles/fog0000000043.html

Any (or all) of the Lambda-the-ultimate papers. “Design of a Lisp-based Processor is perhaps the best for outright jaw-dropping though-provocation

The closely related A Universal Modular Actor Formalism for Artificial Intelligence which has with the recent rise of interest in Erlang become hugely relevant.

Also, Derivatives of Regular Expressions is a hoot! (and doesn’t have a public URL)

But most importantly, every professional programmer must read Managing the Development of Large Software Sysetms but unlike the authors of a generation’s worth of software engineering text books they must read the whole thing.

You simply cannot omit: Fred Brooks, No Silver Bullet: Essence and Accidents of Software Engineering

http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html

Great list Michael.

If I could contribute on that thought, I would add these two as my all-time favourites: The Humble Programmer by Dijkstra, and No Silver Bullet: Essence and Accidents of Software Engineering by Brooks.

I can highly recommend ‘Big Ball of Mud’ by Brian Foote and Joseph Yoder. Quoting: “While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD”.

An excellent read.

“Notes On Programming In C” by Pike. Short, sweet, and great advice.

hi there,

thanks for the list in one place.

BR, ~A

Reflections on Trusting Trust—Ken Thompson http://cm.bell-labs.com/who/ken/trust.html

How about WebDev101. Don’t make hover state text colour of your links the same colour as your background.

Time, Clocks and the Ordering of Events in a Distributed System

http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf

The best paper I’ve ever read.

Another great read … “Growing A Language” by Guy L Steele Jr.

http://www.brics.dk/~hosc/local/HOSC-12-3-pp221-236.pdf

And, no-one should touch a distributed system before reading “A Note On Distributed Computing” (already in the original top ten list).

how about:

On the economy of doing mathematics, Dijkstra at his opinionated best

Relational Completeness of Data Base Sublanguages, Ted Codd’s masterpiece

Beck Testing Framework, Kent Beck’s original article on SUnit

What every computer scientist should know about floating-point arithmetic

Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I, the short intro to LISP by McCarthy

An axiomatic basis for computer programming, nice paper by Hoare

On the design of machine independent programming languages – more Dijkstra

First, you should have actual pdfs of these papers, not links that require you to pay. If these papers were truly important, then you would be able to read them without paying.

Second, your choice is bad. Trusting Trust is an interesting paper, but it is hardly relevant to mainstream programmers. It is much more relevant to computer science and should probably be included in an upper division compilers course. The other papers have similar problems.

Third, your tone is arrogant and annoying. Get over yourself.

Some classics are not big enough to be an essay which is ok when that’s the point

And it has to be admitted our dear friend lindsey is a clasic too :-)

Oops, the point was here

And Murphy – he wrote a classic too.

David, your opinion would be a little less ridiculous, if you demonstrated the intelligence required to not post the same thing twice.

“Teach Yourself Programming in Ten Years”, Peter Norvig.

Gustavo Duarte’s recent series on computer internals has become an instant classic.

How about Kevlin Henney’s “Omit Needless Code”?

I know several of the papers mentioned so far and mostly agree that they are excellent. However, that’s just a matter of opinion, what’s missing all around, in RCMs original posting and in most comments, are arguments and reasons why particular papers are important today and worthy of reading.

I’d definitely add
End-to-End Arguments in system design
by: Saltzer, Reed, Clark

This is mainly networking, but an absolute must for anyone doing web programming, or anyone who just wants to get an idea as to reasoning behind the OSI model and the protocols that underpin the web.

I hate to respond to trolling, but I have to disagree with David. I most certainly don’t find your tone arrogant or annoying (not even sure how he’s concluding that). Your work is valuable for people in this field and I, and certainly many others, appreciate the time invested.

I should have looked more closely: “Posted by Michael Feathers”. However, no matter if Michael or Bob’s your uncH^HHauthor, I could still do with some reasons why these papers are important.

The Cathedral and the Bazaar by Eric S. Raymond. It changed the way I thought about project management and lots of other things, too. It’s more interesting to open source programmers and business types, but it’s well worth the read even if you only read the Brief History of Hackerdom, which is amazing in its own right.

http://www.catb.org/~esr/writings/cathedral-bazaar/

Thanks for the list, but please don’t link to ACM portal, it is a pay site. Always link to a free version if it is available. Yes, these papers are worth spending a minute or two searching for a free version, and yes they are probably worth spending real money to read as well, but if a free version exists, save us all the time and money and link to it.

One small moment for an author, or one giant waste of time for mankind.

No Silver Bullet: Essence and Accidents of Software Engineering – Frederick P. Brooks, Jr.

Design Principles Behind Smalltalk – Dan Ingalls

Programming as Theory Building – Peter Naur

No Silver Bullet: Essence and Accidents of Software Engineering – Frederick P. Brooks, Jr.

Design Principles Behind Smalltalk – Dan Ingalls

Programming as Theory Buildinurg – Peter Naur

Would you like me to write your code for you too? YOU are responsible for your career. YOU search for the free papers if you don’t want to pay for them. Sheesh.

I used to read papers back when I was a homeless rodeo clown but not any more. Now I am a world class magician !

Lest we forget that there exist programming papers that are something other than theoretical pontification: HACKMEM

don’t read, do. reading these papers as programmer is nearly useless, unless you want to be fricking theoretician – lamer.

hey why did my comment get erased?

David: wrote:

Third, your tone is arrogant and annoying. Get over yourself.

First rule of feedback from Seashore & Weinberg is that feedback is seldom about the target and more about the person giving the feedback.

So how it is you find yourself so arrogant and annoying? What do you think it will take for you to get over yourself?

I would take off all the papers on your list and add nothing to it. That would make for a list of papers a programmer should read. I assume we’re talking white papers which are not written to be read. If you start reading white papers you’ll eventually read financial reports and then one day you’ll just shoot yourself.

“What every computer scientist programmer should know about floating point” and “What every programmer should know about memory”.

The Next 700 Programming Languages – P. J. Landin

Free version: http://ttic.uchicago.edu/~blume/classes/aut2008/proglang/papers/Landin-next-700.pdf

I would add:

1. Knuth’s Computer Programming as an Art 2. Backus’ The History of Fortran I, II, and III 3. Wirth’s A Brief History of Software Engineering

-m

For OOP, we need to add Bertrand Meyer’s Object Oriented Software Construction: http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction Probably the clearest book on OO, and one I wish so-called OO specialists had read. Yeah, it’s Eiffel heavy, but the principles should be applied everywhere.

This comment is a response to all the comments about “reading these papers as programmer is nearly useless”. I realise I won’t change their mind and will not attempt to, but hopefully there will be some people reading the comments who don’t know why it is a good idea to read papers and I aim to shed some light.

1. These papers are written by people who are much more skilled than you, at least in the area they are writing about although probably in most other areas of computing as well. I’m not slandering your skills but merely pointing out that these authors know their stuff and you can learn from them.

2. Despite what you may think, a lot of research done 20, 30, 40, etc. etc. years ago is still hugely important. For example, one of the papers listed above (“Can programming be liberated from the von Neumann style?”) discusses something that is important to the next generation of compilers. Many people think that the von Neumann style is hindering our ability to achieve the parallelism needed to take advantage of the huge number of cores that are going to be placed on computer chips in the near future.

3. You’ll gain a greater understanding of how the system beneath the level you are working at work. If you’re working at an application level then it’s a pretty good idea to have an understanding of how compilers work; how they optimise code and so forth.

Of course there are a number of other reasons (general interest, wanting to improve your knowledge) but I feel the three above are sufficient incentive.

If you’re the kind of developer who is happy just to learn the next big language and write some code, then you are probably not going to be the kind of person who would read these papers. But if you actually take an interest in what your profession is and want to really understand what you are doing and why, then reading papers is one of the best ways to help achieve this aim.

Learn to work with the goop and sludge of team programming and unworldly deadlines. Read “The Mythical Man Month” by Fred Brooks.

Learn to work with the goop and sludge of team programming and unworldly deadlines. Read “The Mythical Man Month” by Fred Brooks.

What about GoTo Considered Harmful ?

Saul, welcome to the Internet. The ridiculous ones are the people who criticize accidental double posting and casual mistakes in spelling.

I gotta agree with Axel Busch, Joel Spolky’s 12 Steps to Better Code has made my life a LOT easier. It ought to be on every programmer’s to-read list, though I would consider it “basic skills.”

casmrv wrote:

http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction

+1. I owned the first and second edition. I read the second edition cover to cover (through page 1080) and though it was excellent. Want to understand covariance, contravariance? Want to understand why multiple inheritance is required for a complete type system (in a class-based, statically typed OO language), this is the book to read. Great book.

Michael, would please you edit your posts so that they have only a short summary visible on the front page of http://blog.objectmentor.com/ ? Now this post and The Orange Model fill it almost completely, so that seeing where there are new replies requires lots of scrolling.

Michael, would please you edit your posts so that they have only a short summary visible on the front page of blog.objectmentor.com? Now this post and The Orange Model fill it almost completely, so that seeing where there are new replies requires lots of scrolling.

My initial reaction was also that “No Silver Bullet” deserved a spot on the list, but perhaps that’s for another list. Say, the “Ten Papers Every Project Leader Should Read” list.

Thanks for the list, Michael. And thanks to all the other commenters for adding there favorites as well.

I just read “A Laboratory For Teaching Object-Oriented Thinking” for at least the second time, and it made more sense than ever.

And thanks for posting papers and not books. I already have an insurmountable list of books to read. I can get through a paper here and there.

Keep up the good work.

Wow. That ten papers would have been on my list of “papers of no CS value” lecture. 80% of them are the reason why CS has fallen in the gutter over the last 25 years. Get back to mathematics. There were programmers that wrote programs 500 years before digital computers were even developed. Only then you will have some foundations for the long run.

I would definitely add the following documents into the mix too:

• Dijkstra, Edsgar. “The Humble Programmer”. Communications of the ACM, 1972

• Dijkstra, Edsgar. EDW1157

Both of these papers foretell the importance of highly iterative software development methodologies, and the importance of matching a formal specification (which, now-a-days, means the complete set of tests as produced by following TDD) against an implementation.

I should also mention that I have been very successful in iterative design-by-contract and other applications of honest-to-goodness formal proofs for my software as well. As EDW states, a test only proves compliance with one requirement, but it does not demonstrate the absence of bugs. I find combining TDD and formal proofs a potent and useful combination.

I second the recommendation for What every computer scientist should know about floating point arithmetic.

I third the recommendation for What every computer scientist should know about floating point arithmetic.

Met you guys at SD West 2004. What I learned there changed my life! You can’t believe how fast I bookmarked those links.

Very awesome for Michael to do this.

Mmmhh… Would the table of contents of “Facts and Fallacies of Software Engineering” (Robert L. Glass) count as a “paper”?

I can’t program my tail out of a wet paper bag but I appreciate anyone who would at least attempt to put such a list together for public consumption. Maybe his list sucked (maybe not), but just look at all the recommendations that have flowed from it!

He has just done what Linus Toorvalds did … he put a nugget of an idea out there and got many other good minds to work on the problem. Now THAT is programming!

He postulated a problem and the problem itself generated an answer. Welcome to distributed / community computing.

I haven’t read a lot of computer science, but one of the most insightful and thought provoking pieces I read was Peter Naur’s Programming as Theory Building.

Thanks for publishing this list. I am a lonely programmer trying to sharpen my saw when I can, and this list is going to be very useful.

Uups, I totally forgot my favorite ‘paper’ on (unit) testing: “The Way of Testivus” – http://www.artima.com/weblogs/viewpost.jsp?thread=203994

And it’s a lot of fun to read, too :-)

Thanks for the list. Together with the ones listed in the comments, these papers form a strong trails of thought on a variety of topics relevant today as, indeed, 40 and 50 years ago. (Well, not all of them are that old.)

Someone asked a question what makes these papers good. I think it could be a start of an interesting meta-discussion which however would belong to the department of philosophy of science more than that of computer science.

Someone else called you arrogant. I think we can live with that.

Thanks again.

@Michael Feathers

Hi Michael…

of ‘On the criteria to be used in decomposing systems into modules’ , you said:

This is a very old paper, but it is more than a classic. In it, Parnas introduces a forerunner to the Single Responsibility Principle. He introduces the idea that we should use modularity to hide design decisions – things which could change. People still don’t consider this as often as they should.

I have been trying to understand what you mean by ‘a forerunner to the Single Responsibility Principle’.

In Protected Variation: The Importance of Being Closed, Craig Larman says:

Information hiding is PV, not data encapsulation ‘On the Criteria To Be Used in Decomposing Systems Into Modules’ is a classic that is often cited but seldom read. In it, Parnas introduces information hiding. Many people have misinterpreted the term as meaning data encapsulation, and some books erroneously define the concepts as synonyms. Parnas intended it to mean hide information about the design from other modules, at the points of difficult or likely change. ...

That is, Parnas’s information hiding is the same principle expressed in PV or OCP, it is not simply data encapsulation, which is but one of many techniques to hide design information. However, the term has been so widely reinterpreted as a synonym for data encapsulation that it is no longer possible to use it in its original sense without misunderstanding it.

Here, PV is Alistair Cockburn’s Protected Variation pattern:

Identify points of predicted variation and create a stable interface around them

So Larman is saying: INFORMATION HIDING = OCP = PV

At first I thought that if SRP was closely related to OCP, like DIP (which is a means to achieve OCP) and LSP (which is necessary to achieve OCP), then maybe by some sort of transitivity, you meant that information hiding was a forerunner of SRP. But my understanding is that SRP and OCP are two separate principles.

So what did you mean?

@Michael Feathers

Hi Michael,

another attempt at understanding what you meant when, regarding ‘On the criteria to be used in decomposing systems into modules’ (OTC), you said:

This is a very old paper, but it is more than a classic. In it, Parnas introduces a forerunner to the Single Responsibility Principle. He introduces the idea that we should use modularity to hide design decisions – things which could change. People still don’t consider this as often as they should.

I first read the OTC paper when I was searching for the origins of the term Separation of Concerns. While the term was coined by Edsger Dijkstra in his 1976 paper ‘Notes on Structured Programming’:

design should start be enumerating the ‘separable concerns’ and by considering each group of concerns independently of the others

most books and papers attribute the concept to David Parnas, who did not use the words ‘Separation of Concerns’ (SoC), but who expressed the concept in the OTC paper (1972):

we propose that [to decompose a system into modules] one begins with a list of difficult design decisions, or decisions which are likely to change…each module is then designed to hide such a decision from others

Based on this (and the rest of the paper), I concluded that at the time of the paper, SoC could be defined as follows:

The modularisation of s/w, using information hiding, to achieve the benefits of s/w flexibility, shorter s/w development times, and s/w understandability

Many more modularisation criteria have been used to do Separation of Concerns, e.g. AOP aka advanced separation of concerns.

Two classic criteria are:

*low coupling
*high cohesion

OO decomposition directly supports the first, and we have often been told to aim for the second one.

Of the SRP, Uncle Bob said:

This principle was described in the work of DeMarco and Meilir Page-Jones, They called it cohesion. ...

SRP is one of the simplest of the principles, and one of the hardest to get right. Conjoining responsibilities is something we do naturally. Finding and separating those responsibilities from one another is much of what software design is really about.

It seems to me that like ‘high cohesion’, SRP can be considered a (cohesion-related) modularisation criterion. But it is distinct from the modularisation criterion of information hiding.

So what do you mean when you say that information hiding is a forerunner of SRP?

@Michael Feathers

Hi Michael,

another attempt at understanding what you meant when regarding ‘On the criteria to be used in decomposing systems into modules’ (OTC), you said:

This is a very old paper, but it is more than a classic. In it, Parnas introduces a forerunner to the Single Responsibility Principle. He introduces the idea that we should use modularity to hide design decisions – things which could change. People still don’t consider this as often as they should.

I first read the OTC paper when I was searching for the origins of the term Separation of Concerns. While the term was coined by Edsger Dijkstra in his 1976 paper ‘Notes on Structured Programming’:

design should start be enumerating the ‘separable concerns’ and by considering each group of concerns independently of the others

most books and papers attribute the concept to David Parnas, who did not use the words ‘Separation of Concerns’ (SoC), but who expressed the concept in the OTC paper (1972):

we propose that [to decompose a system into modules] one begins with a list of difficult design decisions, or decisions which are likely to change…each module is then designed to hide such a decision from others

Based on this (and the rest of the paper), I concluded that at the time of the paper, SoC could be defined as follows:

The modularisation of s/w, using information hiding, to achieve the benefits of, s/w flexibility, shorter s/w development times, and s/w understandability

Many more modularisation criteria have been used to do Separation of Concerns, e.g. AOP aka advanced separation of concerns.

Two classic criteria are:

* low coupling
* high cohesion

OO decomposition directly supports the first, and we have often been told to aim for the second one.

Of the SRP, Uncle Bob said:

This principle was described in the work of DeMarco and Meilir Page-Jones, They called it cohesion. ...

SRP is one of the simplest of the principles, and one of the hardest to get right. Conjoining responsibilities is something we do naturally. Finding and separating those responsibilities from one another is much of what software design is really about.

Like ‘high cohesion’, SRP can be considered a (cohesion-related) modularisation criterion. But it is distinct from the modularisation criterion of information hiding.

So what do you mean when you say that information hiding is a forerunner of SRP?

Philip: It’s a funny thing about the design principles. I think that often if you take one, you get many of the others by implication. If you concentrate on SRP, you can end up with OCP without even thinking about it. I think the same is true of OCP.. If you really push it, you will end up with modules with single responsibilities. That’s the sense that I meant.

I don’t know this for sure, but I have a feeling that OCP came before SRP historically. But, somehow I think that SRP (or some generalization of it) is primary. Consider duplication. If we have duplication in a code base, a piece of code may have a single responsibility seen by itself, but from the perspective of the entire code base, it has some fraction of a particular responsibility if it is duplicated in a couple of different places.

Thanks for the list!

Thanks so much for putting together this list. Lists, like academic papers, tend to foment passioante discussion and can occasionally lead to great things.

I was astonished at the rudeness of many of the commenters here. This was not a provocative or controversial post. And yet the hostility of a number of the comments was pretty shocking.

(FPM’s comment about being a homeless rodeo clown did sort of make my day – thanks for leaving that one up.)

My two favourite papers: the Parnas’s, “On the criteria …” which you rightly have in first place and the paper that brought us coupling and cohesion, “Structured design,” by Stevens, Myers and Constantine: www.research.ibm.com/journal/sj/132/ibmsj1302C.pdf

I’ve always been mildly surprised that coupling and cohesion are the only things that made it big from this paper; the concepts of scope of control and scope of effect are astonishing to me.

Ed.

A great list. There are many more to be considered, but a couple that happen to be related to some already on the list…

Parnas and Clements, “A Rational Design Process: How and Why to Fake It” http://www.win.tue.nl/~mchaudro/sa2007/ParnasRationalDesign.pdf

Cunningham, “Everything I Really Need to Know About Object-Oriented Design I Could Learn on a Black-Diamond Run” http://c2.com/doc/everything.html

Thank you! It’s nice to understand what you expect of your audience.

Sad that so many important documents in computer science history are owned, locked behind a pay wall, and denied to the public by the ACM.

Sad that so many important documents in computer science history are owned, locked behind a pay wall, and denied to the public by the ACM.

As much as I’d like to read these I dont have money to buy these. Why cant we have open papers like open source. That would be cool

Hi, only parnas is worth reading. the other papers are b….. or only mathusulem. He received the ACM Turing Award for his work on Fortran!! UPPS Hi mr. Bakus!!!! hi Mr. bakus: are you for citibank programming in cobol? or you mr. Feathers ?

It is up to the individual to read or not read the papers. I am not going to provide links, but I was successful in finding every paper discussed in free pdf files. I did not check for the books.

Thank you for the list. I have some reading to catch up on as many of these papers are before my time. I may not read them all, but I will at least start them. If somebody I respect in the field recommends them, and other people I respect in the field backs them up, then they are worth the time to at least investigate.

It’s true, I agree wholeheartedly.

Nice article. I would love to read six, seven, eight and ten too, but they´re dead.

Thanks for this article.

Greetings, Kjellski

Nice article. I would love to read six, seven, eight and ten too, but they´re dead.

Thanks for this article.

Greetings, Kjellski

Nice article. I would love to read six, seven, eight and ten too, but they´re dead.

Really? I am able to locate copies that are very much alive for me, perhaps you should become a tool user

11th Paper suggestion – E.W. Dijkstra – Cruelty of Really Teaching Computer Science – www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF

Speaking of Parnas, I like Parnas and Clemens:

A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT

http://web.cs.wpi.edu/~gpollice/cs3733-b05/Readings/FAKE-IT.pdf

Super nice!

Fantastic resource. Thanks

THANKS FOR ADDING SUCH GOOD BOOKS

EVEN THANKS EVERY ONE WHO HAS RECOMMENDED THIER VIEWS IN THIS BLOG AND Michael Feathers TOO

How about Networking for dummies?

Too many programmers don’t understand the absolute basics, and therefore are repeating failures of 15 to 20 years ago.

Time to get over yourselves, you’re just code monkeys… and I’m reading your copy of Shakespeare; it blows.

UncleBob wrote:

| Would you like me to write your code for you too?

Yes! That’s why I use frameworks, samples, libraries, so that I don’t have to re-invent the wheel.

| YOU search for the free papers if you don’t want to pay for them.

Why have everyone do it? Surely it would benefit everyone if it was done once and the information shared?

Has Uncle Bob forgotten re-use? :-)

Good Reading !

Great article, i have already read the one by Richard Gabriel on lisp and it was just great, very good food for though, so i’ll sure take a look at your suggestions! Always hungry for great books.

Thanks for the list !

I’ve really enjoyed reading : On the criteria to be used in decomposing systems into modules – David Parnas

and

Arguments and Results – James Noble

I should get back to read classic papers !