There is a time to admire the persuasive power of an influential idea, and there is a time to fear its hold over us. If the idea is so widely shared that we no longer even notice it, it’s time to worry. If the objections to the idea are not answered anymore because they are no longer even raised, we do not have the idea, it has us. We are not in control.
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.
Walk into any library, and the first thing you notice is absolute silence. People behave differently when in a library. They respect others’ privacy and the need for solitude. They don’t have loud conversations. If they need to talk, they go outside or talk quietly. Rarely do people go over to someone’s desk to disturb them. Why are all these behaviors, which are considered rude in a library, are treated as a norm in a modern workplace?
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.