Bookmarks

The 'software crisis' was first identified in 1968and in the intervening decades has deepened rather than abated... but the purpose of this paper is to give some cause for optimism.

This paper proposes there are a number of seminal differences between data inside a service and data sent into the space outside of the service boundary.

...since we're awash in this contemporary ocean of speculation, we forget that things can be known with certainty, and that we need not live in a fearful world of interminable unsupported opinion. But the gulf that separates hard fact from speculation is by now so unfamiliar that most people can't comprehend it

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

The truths described in this memo result from extensive study over an extended period of time by many people, some of whom did not intend to contribute to this work. The editor merely has collected these truths, and would like to thank the networking community for originally illuminating these truths.

Please don't bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet. However, keep in mind that my wife likes blue.

Thus spake the Master Programmer: 'Though a program be but three lines long, someday it will have to be maintained.'

There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. In this paper we shall try to see why, by examining both the nature of the software problem and the properties of the bullets proposed.

A program lives in the minds of the people who work on it. The code is merely a written representation of the program, and it's lossy, so you can't reconstruct a program from its code.

In my work, I probably spend about ninety-nine percent of my time on what others may call petty details. Most managers would rather focus on lofty policy matters. But when the details are ignored, the project fails. No infusion of policy or lofty ideals can then correct the situation.

...is this honest? Is not our prolonged silence fretting away Computing Science's intellectual integrity? Are we decent by remaining silent? If not, how do we speak up?