Rule #1 of Software Development

Rule #1 of Software Development

Robbert Haarman

2013-01-06

Posted by inglorion
at 2013-02-01 04:58:43

My rule #1 of software development: If you aren't sure if you are crazy or the computer is crazy, it's you.

Common instances of this are where you have two variants of your code that should do the same thing, but don't (commonly expressed as "But I didn't change anything!"). Or where the computer is not picking up changes you are making to your source code ("It's not running the log statements that I added. Even adding syntax errors to the file won't make it realize the code has changed!"). Or the program just plain not doing what the code clearly says it should do.

I've been developing software for about 22 years. As a hobby, and as paid work. That's a lot of programming. And I just found the first case where the rule was wrong. I really wasn't crazy. In my Git repository, I had a branch with two commits that I wanted to merge into one. Being kind of sleepy after having worked on the commits for a long time, I decided to be extra cautious and to rewrite history on a new branch, so I could always go back to the original if I messed up. So I created a copy of branch with git checkout -b new-branch, and used git rebase --interactive 'HEAD^^' to merge my two commits into a single one.

The resulting code failed to build. What? It worked fine on the original branch! Ok, switch back to the original branch. Build the code. Works fine. Switch to the new branch. Build the code. It fails. What? Run git diff to see if there are any differences between the branches. It says there aren't any. All files are checked in, the working directory is clean. I have two branches, with completely identical code, and one builds successfully, whereas the other fails to build. Am I crazy, or is the computer?

Turns out there was a race condition in the build. It would sometimes succeed and sometimes fail. It wasn't introduced by me. But it was there in the code. While working on the old branch, I had simply been lucky enough to never hit the timing that leads to a broken build. Or maybe it was something in the order of the files on the disk. At any rate, the race condition is fixed now, and my two branches with identical code now yield identical results. All is good with the world again.

As for rule my #1 of software development, I am not prepared to discard it just yet. It took 22 years for me to find the first instance where I really wasn't doing something wrong. And, arguably, the problem was still in the code I was submitting to the computer, not in the computer itself. So neither the computer, nor me, was crazy. Maybe I should revise it to "If you are not sure if you are crazy or the computer is crazy, it's not the computer."

Posted by inglorion
at 2014-04-03 23:48:48

The most common manifestation of this rule is when you edit and save a file, but your changes just don't seem to make a difference. Usually, this means you're editing the wrong file. Sometimes, it means the build system is broken or misconfigured, and not rebuilding targets that depend on the file you changed. However, I've seen cases where files were being written with incorrect timestamps due to a faulty system clock, which arguably qualifies as the computer being crazy.