I’ve been working on an interesting chapter of my upcoming book about programmer interviews. The chapter is titled “The usual suspects” and in it I’m writing about some of the difficult bugs programmers will all face, sooner or later. I’ve got some real horror stories, like the time I worked with a team trying to understand why data was going missing from a very sensitive database containing the personal details of families and children.
That bug took about three weeks to fix, partly because the team had very limited access to the database and wasn’t able to reproduce the problem on any other machine. Thankfully the issues were fixed before any real harm was done. One of the many problems uncovered was a nasty race condition which would occasionally save the wrong foreign key in a family record. If you’re familiar with SQL Server, it was because @@IDENTITY was used instead of SCOPE_IDENTITY().
I thought it would be a good idea for this chapter to include some ideas for tackling difficult bugs like this. I don’t think there is a universally applicable algorithm for bug-fixing, just like there is no universal algorithm for writing good code, but in a general sense many bugs can be resolved by
- thinking hard about the problem,
- coming up with a hypothesis,
- testing the hypothesis
- studying results, repeating the process
Unfortunately this is quite hard work.
If only there was a magic bullet like the one your non-technical boss secretly believes you’re sitting on.