Papers

Should you use full variable names, or abbreviated? The answer: doesn’t matter. Fixing Faults in C and Java Source Code: Abbreviated vs. Full-word Identifier Names by an all-Italian team of Scanniello, Risi, Tramontana, and Romano. This is a long paper with a short message. Abbreviated identifiers are not a major obstacle to fault identification and fixing It’s a quantitative and qualitative study: it measures participants’ success and failure in debugging code with deliberate mistakes, and uses ethnographical methods to study these professional programmers. (Relevant Dilbert comic) ...

Who uses UML? The answer may surprise you! Unless you’ve spent any time working as a programmer, then the answer will not surprise you. Not at all. At my last job I saw a data scientist reading a heavy UML doorstopper of a book. He was a mathematician who liked to dive into proper programming concepts (I once saw him slowly reinvent unit testing in his Jupyter notebooks). He asked me if programmers used UML. ...

C.A.R. Hoare thinks programming languages should primarily support design and documentation, with programming being a distant third. Two papers by Turing Award winner C.A.R. Hoare, both on programming language design. I like to write up interesting tidbits and copy fun quotes, this isn’t a full summary If you don’t have time to read it all, here’s the tldr: C.A.R. Hoarse invented switch statements, warned us about buffer overflows, and loves Algol 60. (Not Algol 68, which I wrote about.) ...

Use two choices. It’s easy to get hugely better performance by moving from one choice to two choices. It’s very hard to do better. The full title is The Power of Two Choices in Randomized Load Balancing, by Michael David Mitzenmacher. I love the simple theory of this: use two choices. Two choices is exponentially better than one choice, and having three or more choices doesn’t offer much more improvement. Need to hash? Hash it twice, then choose the bucket with fewer items. Need to load balance? Choose two servers at random, then pick the one with less traffic. Need to cache? TWO CHOICES. The math of this thesis is beyond me, but that’s true of most compsci theses now. (Can anyone retain their math knowledge if they’re not actively teaching or publishing?) ...

Forming. Storming. Norming. Performing. Every writer who writes about teams references this one (and only this one) article, and those four stages. It’s foundational, and it rhymes. Development Sequence in Small Groups, by Bruce W. Tuckman In 1965 Bruce Tuckman wrote a literature review and synthesis of how small groups come together, and how well they do their job. He looked at three types of groups: therapeutic groups, task groups (e.g. teams for a job), and groups who only exist in a lab setting. In all three types of groups, he identified 4 rough stages, and he brilliantly made them rhyme: forming, storming, norming, and performing. ...

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. ...

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. ...

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. ...

I’m not in management, but damned if I don’t love a good management paper. Today it’s Frederick Herzberg’s “One More Time: How Do You Motivate Employees,” where I learn to not kick an employee. There are two pieces of vocab I learned reading this article. The first is motivators versus hygiene. This is the difference between doing good things and not doing bad things. Herzberg talks of hygiene the way I talk of table stakes, it’s the bare minimum required to have an employee, like not kicking them. To quote executive coach Chris Rock, “you don’t get credit for doing something you’re supposed to do.” This paper talks about advantages and disadvantages of literally kicking an employee. ...

A 1984 paper that models the time it takes to complete a project, and shows what happens when you are up against bad deadlines. The answer will not surprise you! I love seeing software development modeled as an equation, and this paper gives a great one. Time = ( work_to_software + work_towards_planning ) / ( productivity_per_person * people ) This list comes with a half dozen caveats, all on how these numbers are not independent. ...