Fail Faster, Build Faster
I’m mostly referring to the concept of both setting up your development environment and your code so that as soon as something goes wrong, at the very least your program throws a warning to the console, and ideally (in development, probably not release) goes down in flames and throws verbose errors doing it.
Failing loudly and suddenly isn’t ideal, but the sooner after the problem you have a failure the easier it is to figure out what the problem is. In my latest projects, most of the truly maddening debugging experiences can be tracked down to something that fails silently and doesn’t even log an error.
The second most common problem in debugging is when I manage to ignore bad input, pass along bad output, then have a failure several steps later, with the original problem having been obscured somehow. I was running into that today, and once I figured out the issue I added an assertion to the code that now will make it tell me exactly where the problem is in the input file I’m passing in and it should make fixing any reoccurrences of this issue into a 30 second fix that only requires the input files rather than having to step through debug statements.
The other good thing that having truly aggressive errors setup does is it helps me avoid unintended actions in my code. I use NS_ENUM for almost any case that I can get away with it, because on the off chance I have to change the order, add an item, or remove an item that means that even if I forgot one of the places where I’m referencing the enumerator, I’ll get a warning. This tends to make it an easier fix than looking at your table view, realizing that the section headers don’t align with the sections, then figuring out if you’re screwing up the code for the headers or the cell drawing.
I have the feeling that me starting to get used to this idea is going to lead to me starting to play with testing and possibly even starting to write something resembling decent unit tests for my code. Time will tell on that one I suppose.