Some bloggers have strong opinions and are just right all the damn time. Like Joel Spolsky, and Jason Fried. I admire them, but I’ve never been that guy, or been that confident in my opinions. But damnit, some of my oldest opinions hold up. After nearly two decades of professional programming, I’ve looked back and thought about the opinions I originally had. Here are the ones that I’m convinced I was always right about. ...
The TLDR is simple: if you have a disappearing/reappearing bug, just run it again. In 1985 Jim Gray coined the term Heisenbug. It’s a bug that disappears when you try to replicate it. As distinguished from Bohrbugs, which are easy to replicate. Jim Gray’s key insight was that since a Heisenbug disappears quickly, you can solve it by just running the system again. This way, instead of spending time tracking down a bug and fixing it, you can get wicked high uptime just by having multiple copies of a system ready to go. ...
Programming languages can be categorized in a number of ways: imperative, applicative, logic-based, problem-oriented, etc. But they all seem to be either an “agglutination of features” or a “crystallization of style.” COBOL, PL/1, Ada, etc., belong to the first kind; LISP, APL– and Smalltalk–are the second kind. It is probably not an accident that the agglutinative languages all seem to have been instigated by committees, and the crystallization languages by a single person ...
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. In 1985 Jim Gray and Franco Putzolu asked a simple question. When does it make economic sense to make a piece of data resident in main memory and when does it make sense to have it resident in secondary memory (disc) where it must be moved to main memory prior to reading or writing? ...
This paper reads like an old man yelling at clouds, but then, halfway through, he simply writes a better cloud. (This metaphor is pretty awkward given cloud computing.) A Plea for Lean Software, by Niklaus Wirth In 1985 Niklaus Wirth, fresh off of Pascal, decided that software was too bloated. He placed the blame on two laws: Parkinson’s law: Software expands to fill all the available memory. Reiser’s law: Software is getting slower more rapidly than hardware becomes faster. “A Plea for Lean Software” was written in 1995, right when software started to rely on Moore’s law (that processing speeds double every 2 years) to let consumers keep up with their own bloat. Major software was/is/probably-always-will-be explicitly designed to only be usable on tomorrow’s computers. My rough-rough-rough understanding is that, of the major companies, only Apple focuses on improving software size, and that’s due to their org chart being organized by function instead of by product. ...
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. There is an unofficial and undocumented set of stories and folklore in programming. From kids illegally building the Graphing Calculator for Apple to Mel relentlessly optimizing his code around hardware drums. These stories are our lore. ...
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 entire 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. ...
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. Inside the Japanese Software Industry, by Denji Tajima and Tomoo Matsubara I’m just going to pull some choice quotes. ...
Timothy Lister and Tom DeMarco didn’t include a bibliography in Peopleware, so I swept through the book and produced one for curious readers. (Sorry for the bad formatting. Here’s a life tip: never use a CMS that promises continued development. Just grab one that already works.) Free Articles Hawthorne Effect Denver International Airport Baggage Handling System The Satir Change Model, by Steven Smith IBM’s Black Team “Inside the Japanese Software Industry”, by Denji Tajima and Tomoo Matsubara ...
I just finished reading that old software classic, Peopleware. The first chapter is “Somewhere Today, a Project Is Failing,” and hooked me immediately. Peopleware: Productive Projects and Teams, by Tim Lister & Tom DeMarco Chapter 15 talks about Leadership as Work Extraction v. Leadership as Service. This ties into what I know of management spans. For years MBAs thought that the ideal number of direct reports was around 5-7 (which matches what psychologists know about working memory), but the idea of increasing that number means that managers have to start leading instead of micromanaging. See this HBR paper: More Direct Reports Make Life Easier by Ron Ashkenas (HBR). ...