I have collected a list of thought-provoking writings from the world of software development. This post includes summaries and links to the original sources. I will add relevant writings to the list as I encounter them.
The list is sorted in chronological order from oldest to newest:
- The Story of Mel, a Real Programmer
- The Case of the 500-Mile Email
- Why Should I Care What Color the Bikeshed Is?
- Crashes only on Wednesdays
- If Carpenters Were Hired Like Programmers
- The CADT Model
- Everything is Broken
- The Demise of the Mildly Dynamic Website
The Story of Mel, a Real Programmer
A story by Ed Nather in 1983 as a response to the statement: Real Programmers write in FORTRAN. This is from a time when computers used drum-memory, which lead to some ingenious hacking by capable developers like Mel.
This is one of hackerdom's great heroic epics, free verse or no. In a few spare images it captures more about the esthetics and psychology of hacking than all the scholarly volumes on the subject put together. Quote from the link below.
The Case of the 500-Mile Email
A story by Trey Harris about an incident in a campus email system in the 1990's. Users reported an issue that apparently wouldn't allow them to send mail more than approximately 500 miles. Before contacting support, they went as far as collecting enough data to produce a map showing the radius within which they could send email to: There are a number of destinations within that radius that we can't reach, either, or reach sporadically, but we can never email farther than this radius. Quote from the link below.
Why Should I Care What Color the Bikeshed Is?
The legendary email by Poul-Henning Kamp in 1999 as a reaction to a very long argument about whether sleep(1) should take fractional second arguments. The main argument is made by reiterating Parkinson's law of triviality.
The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change. Quote from FreeBSD FAQ.
Crashes only on Wednesdays
A story by Gyrovague about a bug in a piece of medical equipment in 1997. A server would randomly crash, but only on Wednesdays, without any hints in the logs.
I’ve learned that no matter how seemingly random and unpredictable the behavior of the bug, there’s always a logical explanation for it that you can find if you dig deep enough; that “unrelated” errors rarely are; and that it’s almost certainly your own damn fault. Quote from link below.
If Carpenters Were Hired Like Programmers
A joke by an unknown author from the early 2000's about the hiring process for software developers told via an analogy to carpenters. Here, wood and tools are analogs of programming languages and frameworks.
It perfectly illustrates what I think developers (especially consultants) have to go through all the time when they're interviewing for the next gig. Quote from the link below.
The CADT Model
A short rant on the fact that many open source projects often get rewritten from scratch rather than improving the already existing version. The author named this "development paradigm" Cascade of Attention-Deficit Teenagers (CADT).
Everything is Broken
A blog post by Quinn Norton in 2014 detailing how broken computing and computers are. It focuses on aspects of security and privacy.
Software is so bad because it’s so complex, and because it’s trying to talk to other programs on the same computer, or over connections to other computers. ... Computers have gotten incredibly complex, while people have remained the same gray mud with pretensions of godhood. Quote from the link below.
The Demise of the Mildly Dynamic Website
A blog post on the history of static and dynamic websites and the "mildly dynamic" middle ground of which PHP played an important role. Also interesting notes on the dependence on third party services through JavaScript and relating AWS Lambda to the good old CGI.