Blog Archives

To err is human, to catch an error shows expertise

Experts are OK at avoiding mistakes, but they’re even better at recognizing and fixing mistakes. If you ask an elementary student something like “How can we know that the answer to this problem cannot be 8769?” they might only be

Tagged with:
Posted in Software development

Example of unit testing R code with testthat

Here’s a little example of using Hadley Wickham’s testthat package for unit testing R code. You can read more about testthat here.

Tagged with: ,
Posted in Software development

Dogfooding

Dogfooding refers companies using their own software. According to Wikipedia, In 1988, Microsoft manager Paul Maritz sent Brian Valentine, test manager for Microsoft LAN Manager, an email titled “Eating our own Dogfood”, challenging him to increase internal usage of the

Tagged with: ,
Posted in Software development

Defensible software

It’s not enough for software to be correct. It has to be defensible. I’m not thinking of defending against malicious hackers. I’m thinking about defending against sincere critics. I can’t count how many times someone was absolutely convinced that software

Tagged with: ,
Posted in Software development

Hunt down bad error messages

My printer is unable to clean 51. It won’t work, and all it says is “Unable to Clean 51.” Here’s my suggestion for finding such useless error messages in a code review: Write a script to extract all string literals

Tagged with:
Posted in Software development

How things break

Venkatesh Rao wrote a blog post today Stress Failures versus Decay Failures. It reminded me of three other resources I recommend on how things break. The first is about how things literally break. For example, why the steel in the

Tagged with: ,
Posted in Science, Uncategorized

Bugs, features, and risk

All software has bugs. Someone has estimated that production code has about one bug per 100 lines. Of course there’s some variation in this number. Some software is a lot worse, and some is a little better. But bugs-per-line-of-code is

Tagged with: , ,
Posted in Software development

Software exoskeletons

There’s a major divide between the way scientists and programmers view the software they write. Scientists see their software as a kind of exoskeleton, an extension of themselves. Think Dr. Octopus. The software may do heavy lifting, but the scientists

Tagged with: , ,
Posted in Science, Software development

Pilots and pair programming

From Outliers by Malcolm Gladwell: In commercial airlines, captains and first officers split the flying duties equally. But historically, crashes have been far more likely to happen when the captain is in the “flying seat.” At first this seems to

Tagged with: ,
Posted in Software development

How to test a random number generator

Last year I wrote a chapter for O’Reilly’s book Beautiful Testing. The publisher gave each of us permission to post our chapters electronically, and so here is Chapter 10: How to test a random number generator.

Tagged with: , , , ,
Posted in Software development, Statistics

Buggy code is biased code

As bad as corporate software may be, academic software is usually worse. I’ve worked in industry and in academia and have seen first-hand how much lower the quality bar is in academia. And I’m not the only one who has

Tagged with: ,
Posted in Software development

Acknowledging problems versus solving problems

People want their problems acknowledged more than they want them solved, at least at first. That’s one of the points from Thomas Limoncelli’s book Time Management for System Administrators. Suppose two system administrators get an email about similar problems. The

Tagged with: ,
Posted in Uncategorized

How many errors are left to find?

There’s a simple statistic called the Lincoln Index that lets you estimate the total number of errors based on the number of errors found. I’ll explain what the Lincoln Index is, why it works, give some code for playing with

Tagged with: , ,
Posted in Python, Software development

Dynamic typing and anti-lock brakes

When we make one part of our lives safer, we tend to take more chances somewhere else. Psychologists call this tendency risk homeostasis. One of the studies often cited to support the theory of risk homeostasis involved German cab drivers.

Tagged with: , ,
Posted in Python, Software development

Rewarding complexity

Clay Shirky wrote an insightful article recently entitled The Collapse of Complex Business Models. The last line of the article contains the observation … when the ecosystem stops rewarding complexity, it is the people who figure out how to work

Tagged with: ,
Posted in Business