AK

I am skimming through Eric Raymond’s book, The Art of Unix Programming. Discussions on the intersections of technology and philosophy always interest me, and one of the chapters that caught my eye was “Philosophy Matters”. Surprisingly, many of the lessons apply to life, in general.

You have a method that does not simplify well with the composed method pattern. Local variables are so intertwined that you cannot extract methods. How do you refactor a method where many lines of code share many arguments and temporary variables, that are hard to isolate from each other?

The problem with a sloppy program is that it does too much work, often at various levels of abstractions. It will connect to the database, fetch data, create objects and perform validation in the same method. The code is too long, it is hard to read, and it doesn’t communicate with the reader. It is hard to maintain, hard to test, and can’t handle future changes. What to do?

Every successful software product is the result of the collaboration between developers and the QA team. However, it’s the developers who get the lion’s share of the praise, and the testers are mostly ignored. Devs blame the QA for finding faults in their code, and management blames them for delaying the release. I think this is unfortunate and unfair.

The hard part of debugging software is finding a bug to fix. Actually fixing the bug is easy. However, as with many things in life, the fact that it’s easy doesn’t make it simple. Here are a few guidelines I learned while reading Code Complete on fixing bugs while staying sane.