The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence.
The boss must first distinguish between action information and status information. He must discipline himself not to act on problems his managers can solve, and never to act on problems when he is explicitly reviewing status.
The hardest single part of building a software system is deciding precisely what to build.
Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.
Successful software always gets changed.
The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. Hence plan to throw one away; you will, anyhow.
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.
Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.
A basic principle of data processing teaches the folly of trying to maintain independent files in synchonism.
But I will argue that knowing complete product requirements up front is a quite rare exception, not the norm.
Even the best planning is not so omniscient as to get it right the first time.
Conceptual integrity is the most important consideration in system design.
A little retrospection shows that although many fine, useful software systems have been designed by committees and built as part of multipart projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers.
I have never seen an experienced programmer who routinely made detailed flow charts before beginning to write programs.
Systematically identity top designers as early as possible. The best are often not the most experienced.
More software projects have gone awry for lack of calendar time than for all other causes combined.
Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude.
Job Control Language is the worst programming language ever designed anywhere by anybody for any purpose.
A computer program is a message from a man to a machine. The rigidly marshaled syntax and the scrupulous definitions all exist to make intention clear to the dumb engine.