Can we measure how much more complicated computing is?
25 years ago, a simple question was asked about storage, access times, and economics, and the result was a simple paper. Every ten-ish years since then, an updated paper was written to answer the same question. It’s not a terribly good measure of complexity, but it is enlightening.
Niklaus Wirth proves that better software is possible, in "A Plea for Lean Software"
This paper reads like an old man yelling at clouds, but then, half way through, he simply writes a better cloud. (This metaphor is pretty awkward given cloud computing.)
History and lessons of Algol 68
Algol 68 is the Cronus of programming languages. Cronus is the titan who fathered Zeus, an important character in the myth, but vastly overshadowed by his own progeny. Algol 68 was an important language, and had a fascinating history. This post is a combination history, lesson, and filled with quotes from people who were there.
The Biggest Post-Mortem
When there are failures at a small level, like a deployment goes wrong, there’s a meeting, and a blameless post-mortem written is shared publicly. Normally this happens quickly, while everyone’s memories are still fresh.
When entires projects and movements fail, the opposite happens. There are no public post-mortems, and no meetings. A couple people leave the company, some blame is privately assigned, and the rumor mill goes into overdrive. At this level, a failure can mean a derailed career.
Inside the (1984) Japanese Software Industry
I went to dig into some of the sources cited in Peopleware (see my previous two blog posts), and I fell in love with this 1984 article on Japan’s software industry and Hitachi Software Engineering. It’s a look into a company that feels like peak-era IBM: much bureaucracy and even more success.