The Emperor's Old Clothes

tags
Software Development

Notes

The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time.

NOTER_PAGE: (2 0.18265086206896552 . 0.13668061366806136)

Although I was still managerially responsible for the 503 Mark II software, I gave it less attention than the company’s new products and almost failed to notice when the deadline for its delivery passed without event. The programmers revised their implementation schedules and a new delivery date was set some three months ahead in June 1965. Needless to say, that day also passed without event.

NOTER_PAGE: (4 0.8561422413793104 . 0.08856345885634588)

we had failed to make any overall plans for the allocation of our most limited resource - main storage. Each programmer expected this to be done automatically,

NOTER_PAGE: (5 0.19719827586206895 . 0.22733612273361226)

The entire Elliott 503 Mark II software project had to be abandoned, and with it, over thirty man-years of programming effort, equivalent to nearly one man’s active working life, and I was responsible, both as designer and as manager, for wasting it.

NOTER_PAGE: (5 0.7219827586206896 . 0.2635983263598326)

The hope "that deficiencies in original program specifications could be made up by the skill of a technical writing department . . . was misguided; the design of a program and the design of its specification must be undertaken in parallel by the same person, and they must interact with each other. A lack of clarity in specification is one of the surest signs of a deficiency in the program it describes, and the two faults must be removed simultaneously before the project is embarked upon."

NOTER_PAGE: (7 0.1648706896551724 . 0.29358437935843795)

My notes of the proceedings of that day in October 1965 include a complete section devoted to failings within the software group;

NOTER_PAGE: (7 0.30280172413793105 . 0.09205020920502091)

What was amazing was that a large team of highly intelligent programmers could labor so hard and so long on such an unpromising project. You know, you shouldn’t trust us intelligent programmers. We can think up such good arguments for convincing ourselves and each other of the utterly absurd.

NOTER_PAGE: (7 0.43426724137931033 . 0.4400278940027894)

We assigned to each group of customers a small team of programmers and told the team leader to visit the customers to find out what they wanted; to select the easiest request to fulfill, and to make plans (but no promises) to implement it. In no case would we consider a request for a feature that would take more than three months to implement and deliver. The project leader would then have to convince me that the customers’ request was reasonable, that the design of the new feature was appropriate, and that the plans and schedules for implementation were realistic. Above all, I did not allow anything to be done which I did not myself understand. It worked!

NOTER_PAGE: (7 0.6875 . 0.38702928870292885)

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

NOTER_PAGE: (9 0.36853448275862066 . 0.21757322175732216)

cf Bikeshedding: wonder whether the former is possible in practical terms

A feature which is omitted can always be added later, when its design and its implications are well understood. A feature which is included before it is fully understood can never be removed later.

NOTER_PAGE: (10 0.09913793103448276 . 0.19735006973500696)

"…as a tool for the reliable creation of sophisticated programs, the language was a failure." This report was later suppressed by IFIP,

NOTER_PAGE: (10 0.2661637931034483 . 0.08507670850767085)

We were charged first with a watching brief and then with the standardization of a language to end all languages, designed to meet the needs of all computer applications, both commercial and scientific, by the greatest computer manufacturer of all time.

NOTER_PAGE: (10 0.6387530562347188 . 0.31170886075949367)

Failure of this project brings to mind The Programming Language Conundrum: A language that works for everyone in all contexts is necessarily a shitty language

At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way - and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.

NOTER_PAGE: (11 0.33782327586206895 . 0.08926080892608089)

Software vs Capitalism

An unreliable programming language generating unreliable programs constitutes a far greater risk to our environment and to our society than unsafe cars, toxic pesticides, or accidents at nuclear power stations.

NOTER_PAGE: (12 0.30010775862068967 . 0.7259414225941422)

To have our best advice ignored is the common fate of all who take on the role of consultant,

NOTER_PAGE: (12 0.38254310344827586 . 0.2740585774058577)

The Emperor’s Old Clothes

NOTER_PAGE: (12 0.46551724137931033 . 0.09065550906555091)